Buy two things: role specific training design, and a facilitator for your first few sessions. Run everything else in-house. That is the whole recommendation, and the reason is mechanical rather than philosophical: the parts of AI adoption that actually make it stick are named owners, weekly practice on real work, and pass fail checks on a live workflow, and none of those three survive being handed to a vendor. A program can teach your bookkeeper what a good prompt looks like. A program cannot be the person whose name is next to the quoting workflow on Monday morning when it produces a bad quote.
The Two Things Worth Buying
Buy training design because writing role specific curriculum is a skill your team does not have and will not develop in one attempt. There is a real difference between "here is how ChatGPT works" and "here is how our estimator turns a site photo and a scope note into a draft quote, and here are the four ways that draft goes wrong." The first is available free on YouTube. The second requires someone who has watched fifteen other estimators do this badly, knows that the model hallucinates line items when the scope note is under forty words, and builds the exercise so that your estimator hits that failure on purpose, in a room, with someone standing there to explain it. That accumulated pattern library is what you are paying for. It is worth paying for because you cannot fake it and you will not accumulate it in time.
Buy a facilitator for the first sessions, and buy them for a specific reason: the first session has a failure mode that has nothing to do with AI. Someone in the room is quietly certain this is a prelude to cutting their job. Somebody else has already been using Claude for six months and is about to explain that to everyone. Your operations lead thinks the whole thing is a distraction from the backlog. An outsider absorbs all of that in a way an internal person cannot, because an internal person has to keep working with these people on Tuesday. Buy two or three sessions. Buy the handoff. Then stop buying.
That is the buy list. It is short on purpose.
The Three Things That Cannot Be Bought
**Named owners.** Not a committee, not a "center of excellence," not a Slack channel with forty people in it. One name, per workflow, written down where everyone can see it. The owner of the quoting workflow decides when the prompt changes, decides what an acceptable output looks like, and answers when it breaks. A vendor cannot hold this because ownership is a claim on someone's calendar and someone's reputation inside your company, and vendors have neither. The test for whether you have a real owner: ask three people on the team who owns the intake workflow. If you get three answers, or one answer that is a department name, you do not have an owner. You have a diagram.
**Weekly practice on real work.** Not sandbox exercises. Not a training environment with synthetic customer records. The actual invoices, the actual customer emails, the actual half legible scope notes your field tech types on a phone in a parking lot. Practice on real work is the only thing that surfaces the failures that matter, because the failures that matter live in the specific ugliness of your data. Sandbox data is clean. Your data is not clean. A program that runs for six weeks and leaves cannot install a weekly cadence, because a weekly cadence is not a thing you install. It is a thing you do, or fail to do, forty seven more times after the program ends.
**Pass fail checks on a live workflow.** This is where most SMB AI efforts quietly die, and it is the least glamorous of the three. Before you let a workflow run on real customer work, you write down what "working" means in terms someone can check in under two minutes. For the quoting workflow: every line item in the draft appears in the scope note or the price book, no invented ones. For the intake workflow: the customer's phone number in the summary matches the phone number in the email, character for character. For the email drafting workflow: the draft never states a delivery date. Those are checks. You can run them. Somebody fails them on a Tuesday and you find out on Tuesday instead of finding out from a customer in March.
Write between three and five of these per workflow. More than five and nobody runs them. Fewer than three and you are not checking, you are hoping.
Why the Split Falls Exactly There
The line between buy and run is not about cost. It is about whether the thing is a *capability* or a *commitment*.
Capabilities transfer. A curriculum designer hands you a curriculum and it keeps working after they leave, in the same way a plumber hands you a pipe. The knowledge is embedded in the artifact. This is why training design is buyable: the design outlives the designer's engagement.
Commitments do not transfer. When a vendor "owns" your workflow during a twelve week program, what they actually own is a twelve week performance of ownership. On week thirteen the ownership evaporates and everyone discovers that the workflow was running on the consultant's diligence, not on any structure inside your company. The workflow degrades. The prompts drift as the model updates. The one person who understood the check script left in November. Six months later somebody in a meeting says "we tried AI, it didn't really work for us," and they are right, and the reason has nothing to do with AI.
You can spot this failure in advance. Ask any enablement vendor a single question: what specifically is different inside my company on the day after you leave? If the answer is a document, a dashboard, or a set of recommendations, you are buying a commitment they cannot keep. If the answer is "your operations lead can run the Thursday session without me, and here is the check list she will use," you are buying a capability.
What This Looks Like Over Eight Weeks
Weeks one and two: you pick one workflow. Not three. One. It should be a workflow that runs at least weekly, produces an output somebody reviews, and currently annoys someone. Annoyance is a good signal because it means the person doing it will tolerate change. You name the owner in week one, out loud, in a meeting, and the owner says yes out loud.
Weeks two and three: the facilitator runs sessions on the real workflow with the real data. The training designer's curriculum is the spine. Your owner sits in every session and is introduced as the owner, not as a participant. This matters more than it sounds. The team needs to see the transfer happen.
Week three: you write the pass fail checks together, in the room, with the facilitator present but not driving. Three to five checks. Somebody types them into a shared doc. Everybody can name them from memory by the end of the session or they are too complicated.
Week four: the facilitator leaves. This is the point of the whole engagement and it should be scheduled from day one, in the contract, as a date.
Weeks five through eight: your owner runs a thirty minute session every week. Same day, same time. The agenda is fixed: what did the workflow produce this week, which checks failed, what changed in the prompt, who is stuck. When a check fails twice in a row, the owner changes the workflow or retires the check. Both are legitimate. Pretending the check is still passing is not.
By week eight you either have a workflow the team uses without being asked, or you have clear evidence that this workflow was the wrong first choice. Both outcomes are worth eight weeks. The failure mode you have avoided is the one where you spent six months and cannot say which it was.
The Second Workflow Is the Real Test
The first workflow works because everyone is watching. The second one tells you whether you built anything.
Run the second workflow with no outside help at all. Your first owner trains the second owner. The curriculum you bought gets adapted, badly at first, by someone inside your company. The pass fail checks get written by people who have now seen checks fail and know what a useful check feels like. If this works, you have an enablement capability, and it cost you two purchased things and a lot of Thursdays.
If the second workflow stalls, the diagnosis is almost always the same, and it is almost never the technology. Either the owner was assigned rather than volunteered, or the weekly session got moved twice and then stopped existing, or the checks were written to be passed rather than to be informative. Look at those three in that order. The model is fine. The model is not the variable.
What to Say No To
Say no to enablement programs priced by headcount trained. Headcount trained is not the outcome. Workflows in production, checked weekly, with a name attached, is the outcome, and a program that measures itself by seats in a room has told you what it optimizes.
Say no to a program that will not name its exit date. The exit is the deliverable.
Say no to a "maturity model" with five levels. You have one workflow and eleven employees. You do not need a maturity model, you need to know whether Tuesday's quote had invented line items in it.
Say no to buying the ownership. Even when the vendor is good, especially when the vendor is good, because a good vendor makes the workflow run beautifully for the length of the engagement and thereby hides the exact information you were trying to buy: whether your team can run it.
Buy the design. Buy the facilitator for a few sessions. Then do the unglamorous part yourself, every week, with a name on it. That is the whole program, and the reason it works is that it is the only version where the thing that has to survive the vendor's departure was never the vendor's to begin with.
Related
- ai-champions-for-smb-teams - smb-ai-strategy-one-workflow - how-smbs-choose-ai-partner