← Back to all posts AI + Customer Success

The Five Questions I Ask Before I'll Help Anyone Build an AI Workflow

I've written a fair amount about how AI exposes a weak Customer Success motion rather than fixing one. But the question I keep getting back is the practical one: so what do I actually do Monday morning?

Here's my honest answer. Based on what I've seen, the teams that get something real out of AI can answer five questions before they build anything. The teams that stall can't answer two of them.

These are the five I ask. You can run them on your own team in about twenty minutes on your own - you don't need me for this part.

1. Pick the process that consumes the most time. How consistently is it actually done?

Not the process on the org chart. The real one. Renewal prep, QBR prep, account research before a call, the weekly risk review, whatever your CSMs grumble about on your 1-1s or team calls.

Now peel back the onion one or two layers and ask how that process gets done when you're not watching. If three CSMs do it three different ways, you don't have one process. You have three, and none of them are written down.

Point AI at six different versions of renewal prep and you'll get six different versions faster, formatted beautifully, delivered with total confidence. Remember, formatting is not the same thing as good judgment.

A bad answer sounds like: "Everyone kind of has their own approach."

What it costs you: Eight weeks of build time, adoption dies in month two, and the team concludes AI doesn't work for them. The tool was never the problem here.

2. Can the workflow actually reach your customer context?

I've made the point before that the real CS motion lives in Slack threads, call notes, and CSM memory. What I haven't said is what that means when you sit down to design something.

Three things have to be true. The workflow has to be able to reach the context. The context has to be current enough to act on. And it has to look roughly the same from one account to the next. Miss any one of the three and you get a confident summary of nothing.

Test it on a single account this week. Just go ahead and pick one and see how much of what actually matters is reachable without asking the CSM. The gap between what's in the system and what's in someone's head is your real data readiness score.

A bad answer sounds like: "It's in Salesforce," said quickly, without checking.

What it costs you: You build for the data you wish you had, then discover in testing that half of the reasoning depends on a field nobody fills in.

3. What is your team already doing with AI today?

Ask this with no consequences attached, because the real answer is almost always "more than leadership thinks."

I'll guarantee that at least one person on your team is pasting call notes into a personal ChatGPT account, and somebody else built a prompt for QBR prep and quietly shared it with a couple other teammates. Interestingly enough, that shadow AI usage is the most useful signal you'll get. Your team already told you which task hurts most, and they voted with their own time.

It's also a governance problem sitting in plain sight, which is the next question.

A bad answer sounds like: "Nobody's really using it."

What it costs you: You miss the highest-value use case in your org because it never made it onto a roadmap, while customer data goes somewhere nobody approved.

4. If AI drafts something headed to a customer or into the CRM, who reads it first?

This is the question that is rarely asked, and it's the one that separates a demo from something you can run in production.

Human review must absolutely be part of the design. It can't be left to just a disclaimer you add to the bottom of a slide.

Get real specific here. Who approves it before it goes out? What happens when the model gets an account wrong (because you know it will) and probably on an account that matters? What customer data is allowed anywhere near it, and who decided that? Is there a clear path to go from "the AI suggested this" to "a person decided this"?

The teams that answer these fast are usually the ones who've been through a security review before. The teams that wave it off are the ones who will hit a wall two weeks before launch when your Legal or IT team finally sees it.

A bad answer sounds like: "We'll figure that out when we get there."

What it costs you: One bad summary in front of one customer and the program is finished. Not paused. Finished. You'll spend more political capital recovering from that than designing the review step would ever have cost.

5. Who is accountable for owning it after it's built?

This is where most of these efforts quietly fall into the abyss, and it's the question people skip because the answer is uncomfortable.

A workflow isn't a deliverable you receive and file away in a shoebox. Somebody has to watch it, tune the prompts when the model drifts, update it when your process changes, and answer the new CSM who asks "why is it now doing that weird thing"? Somebody has to be there to herd those cats.

If the answer is "it's me, on top of everything else I'm doing," that isn't an owner. That's a volunteer with a full calendar. Most CS leaders I know are already absorbing whatever nobody else in the org wants to handle. Adding an unfunded AI program to that pile isn't a plan, it's a recipe for failure.

A bad answer sounds like: "We'll sort that out once we see if it works."

What it costs you: It works for six weeks, then it drifts, then people stop trusting the output, then they stop opening it. Nobody announces the death. It just stops showing up in the work.

What to do with your answers

If you can answer four of the five clearly, you're in decent shape and your real risk is picking the wrong first workflow. Most teams reach for the flashiest one - Churn Prediction - when the real money is sitting in the boring one, which is the four hours a CSM burns pulling together context before every renewal discussion.

If you can't answer two of these questions, that's not bad news. That's just the actual work, and it comes before the tooling. Nobody's operating model is ready on the first pass, including my own.

Either way, the sequence is the same. Map how the work really happens. Score the candidates on value, feasibility, data readiness, risk, and whether anyone will adopt it. Design one workflow all the way through, including the review step and the owner. Test it somewhere safe. Then decide whether it earns a second one.

If you want help running that

One of my workflows, the AI Customer Risk Triage Brief, is in Rod Cherkas's CS AI Playbook Vault. You can also run it free on my site. That brief is one workflow built for a single problem. The CS AI Workflow Design Sprint is how we figure out which workflow is yours.

It's a simple process: two to three weeks, $7,500, fixed fee. We map your current process together, score three to five candidates, and I design one of them end to end: the trigger, the prompts, the review checkpoints, the owner, and a 30/60/90 plan your team can run without me. It gets built and tested inside your own environment, and I never need your customer data moved into anything of mine.

If you'd rather start alone, I built a free five-question version of what's above and only takes a minute, but it gives you a straight read on whether AI would survive contact with your operation. CS AI Readiness Assessment

If you'd rather just talk it through, take twenty minutes. Bring the process that's eating your team alive and we'll work out whether AI belongs anywhere near it.