The AI workflow works. Why is nobody using it?

Work Musings · GTM AI

I will never know a sales rep's perfect way to organize their day. Honestly, I don't always know mine.

But it's tempting to build a workflow around your version of a good morning. Here are the accounts to focus on. Here's the research to read. Here's who you should follow up with. You put it in front of the team and wait for everyone to find it as useful as you do.

I've seen versions of this struggle to get adopted. Not just day planners, but standardized research pulling together Salesforce and web information, and skills that explain why a lead was routed to someone.

The workflows I've seen get adopted have had a clearer job: enroll accounts into agentic prospecting, prepare contacts for outreach, build sales collateral, or turn account data into a customer presentation.

That experience has made me more opinionated about where a central team should spend its time. We can give people helpful ways to organize their work. We probably shouldn't build our roadmap around everyone adopting our personal preferences.

I want to start somewhere more concrete: what does this help someone finish, and where will they actually use it?

The lead-routing example makes the placement problem especially clear.

A rep wants to know why an account or lead landed with them. We can build a skill that explains the routing. But if using it means copying information out of Salesforce, opening Claude, finding the skill, and bringing the answer back, we've attached an errand to a question.

I don't expect reps to make that trip often enough to build around it.

The approach I'd favor is preparing the explanation at routing time and putting it on the Salesforce record. A tool such as Clay could help assemble context, but the workflow needs the actual routing decision and an integration allowed to update the record. A prompt can't supply either. The rep gets the answer where the question comes up.

The explanation needs to reflect the actual routing rules and evidence. "This looks like a great opportunity for you" is enthusiasm, not an explanation. Something like "Assigned to you because this account falls in your territory and matches this segment" is useful when those are the real reasons. If the reason is missing, say so rather than inventing a plausible one.

This is still an information workflow. An explanation can be enough if it removes uncertainty at the moment someone needs it. Before building another destination, I'd check whether the result can arrive in the place people already use.

A research brief can be accurate, nicely formatted, and still leave someone with most of the work.

Someone still has to decide what matters, find the missing information, build the slides and check the numbers. Eventually, somewhere in there, they have a customer meeting.

The examples that stand out to me are closer to the deliverable itself: digital sales rooms, pitch decks, and customer success managers' quarterly business reviews, or QBRs. Pulling the relevant data from Snowflake and Salesforce and delivering it inside a Canva presentation is a very different proposition from handing someone another document to interpret.

These workflows need shared data, integrations, and agreement on what "ready" means. That's useful work for a central team because people shouldn't each have to rebuild those foundations.

Here's an illustrative QBR workflow, rather than a description of our exact implementation. Start with the agreed presentation template. Bring in the account context and the relevant usage data. Include the date range and links back to the evidence. Flag the missing information where it belongs in the deck. Leave a draft the CSM can review and adapt for the conversation.

The person still owns the customer story. But they aren't starting with a blank presentation and six tabs of homework.

People who can build their own workflows in an AI workspace have room to be particular. They can ask for a shorter plan, different priorities, or an entirely different way of working.

I think that's healthy. My personal setup doesn't need to become company policy because I happen to like it. A morning routine is a surprisingly personal thing to put on a roadmap.

For a central AI team, I'd separate the shared work from the personal choices.

Shared work: access to the right data, reliable integrations, consistent account definitions, useful presentation templates, and the processes behind a prospecting-ready account. Work that many people need and shouldn't each have to rebuild.

Personal choices: how someone organizes their morning, which reminders they want, how much detail they like, and how they prefer to review their tasks. Offer starting points, then let people adapt them.

This isn't a rigid split. If a personal workflow turns out to solve the same problem for a lot of people, it may earn shared support. But I'd want that evidence before investing in a universal version.

If you aren't on a central AI team, this is your invitation to color outside the lines. Use the shared capabilities and make them fit your day. Keep the same permissions and data boundaries; change the experience around them.

And if you are on the central team, give someone a clear way to tell you when the shared part is broken. Personal flexibility doesn't help much if everyone is independently fixing the same account-matching problem.

Here's the brief I'd use before putting a workflow on the roadmap:

For the QBR example, that could become:

For that to work, the workflow needs account-data access and a way to prepare the deck in the agreed template. The CSM still decides what to share with the customer.

Then get crisp about three things:

I'd measure the time to a usable result, including review and repair, and look at whether people come back for the next real task. Opening a skill tells you less than using what it produced.

Before deciding the team needs another training session, watch someone try the workflow on work they actually owe.

Where do they leave the flow? What do they copy? Which parts do they rewrite? What information do they add that the system could already have gathered? Does the result land somewhere useful, or do they have to move it again?

Training can help when someone doesn't understand a useful capability. It can't make an unwanted deliverable important, and it shouldn't have to compensate for five unnecessary steps.

Take one workflow people aren't using and ask someone to show you the work they need to finish. Fill out the brief with them, change the biggest obstacle, and watch the next real task. Check whether the result gets used and whether review, repair and moving it around take less effort. That tells you more than another round of training attendance.

Robert