Training on the way out is when a build is finished
The engineering demo went well. The agents handled the sample tickets. Leadership signed off. Six weeks later, ops is back to the old path for half the work, the reviewer console has three unexplained queues, and the "training session" is a one-hour slide deck scheduled after everyone is already behind on their real jobs.
That is not adoption failure. That is a delivery model that treats training as a courtesy — something you bolt on after the build — instead of the condition for calling the build done.
A finished build is one your team runs without the vendor in the room: named workflows in daily use, written runbooks, operators who know where exceptions go. Training is not awareness. It is the handoff — and it belongs in the SOW before you sign, not on the calendar after go-live.
#Shelfware is the default outcome
The most expensive AI is the kind nobody uses. The most expensive internal system is the one that only the person who built it understands.
Shelfware happens when capability ships without an adoption arc. Engineering optimizes for go-live date. Procurement optimizes for feature checklist. Nobody owns the question: who runs this on a random Wednesday when the champion is on vacation?
The pattern repeats across engagements we inherit:
- A workflow system exists. Ops uses the old spreadsheet for anything "weird" because nobody showed them what weird looks like in the new tool.
- Agents run in production. Only two early adopters know how to interpret the reviewer queue; everyone else pings engineering.
- Leadership bought AI tools company-wide. Usage dashboards show activity in marketing and silence everywhere else.
In each case, the technology worked. The operating cadence did not change. Training was a calendar invite, not a deliverable tied to exit.
Compare that to a multi-location operator — operations-heavy, non-technical workforce, AI visible everywhere except inside their own company. A Getting Started session for the whole org. Then department workshops shaped around real workflows: site operations, customer communication, finance, leadership reporting. Each workshop ended with one workflow the team ran the next morning. Departments left with named workflows in regular use — three to five each in the teams we worked with — not "awareness," but jobs they actually own.
The difference is not charisma in the room. It is whether training was scoped as part of the build or deferred until after the team was already underwater.
#Adoption is a deliverable, not a slide deck
A slide deck explains what was built. A deliverable changes what people do on Monday.
Treat adoption with the same specificity you treat features:
Named workflows per team. Not "ops is trained on the system." Customer service runs ticket triage with these exception rules. Finance runs month-end reconciliation through these steps. Each workflow has an owner and a runbook.
Written runbooks that match the UI. Screenshots go stale. Runbooks describe decisions: when to approve, when to escalate, what to do when field X is blank. They live where the team already looks for process docs.
Practice on real work in the session. Department workshops use live tickets, live accounts, live close tasks — not sanitized examples from the demo. The output of the session is a workflow shipped, not a certificate.
A baseline before exit. Leadership should be able to answer "are we using this?" with a list of named workflows and owners — not a gut feeling or a login count from IT.
If your SOW says "knowledge transfer" or "one training session" without naming workflows, runbooks, and owners, you are buying shelfware insurance, not adoption.
| Deliverable | Slide deck | Real adoption |
|---|---|---|
| Output | Awareness | Named workflows per team |
| Practice | Sanitized demo | Live tickets, accounts, close tasks |
| Documentation | README in repo | Runbooks in operator channels |
| Success measure | Attendance | Daily use without engineering escalation |
| Timing | After go-live crunch | Before final invoice |
This is why we bundle system, agents, and training in one engagement. A system without training is overhead the team works around. Agents without a team that knows the reviewer console are unaudited risk sitting in a queue nobody checks.
#Build for the exit from week one
"Build for the exit" is not a farewell dinner. It is an architecture and delivery choice from the first scope conversation.
Direct access to the builders. Training led by account managers who were not in the codebase is how runbooks drift from reality. The people who ship the workflow should be in the room when ops asks why a button exists.
Operators in scope, not just executives. An hour with the team doing the work in week one beats six weeks of stakeholder interviews. The same team belongs in department workshops — they know which variations of the job actually happen.
Training scheduled before the last invoice, not after. The final phase of our sequence is train the team, then exit. Department-level sessions, runbooks, handoff. Retainer if you want one. Clean exit if you do not. We are not a permanent line item — which only works if the team can run and extend the system without us.
Reviewer console literacy. If agents route exceptions to humans, training covers the console like any other production tool: what each queue means, SLA expectations, how to debug a stuck job. See the reviewer console is where humans belong for why that surface is non-negotiable in operational AI.
Honest boundaries on v1. When the team knows edge cases land in weeks five through eight, they do not abandon the system the first time something unexpected appears. Training sets expectations: here is what v1 handles today, here is where exceptions go, here is what ships next.
Exit-ready means your lead operator can onboard a new hire using the runbook, file a sensible bug report, and answer "what happens when the model is wrong?" without opening Slack to the vendor.
#What bad training looks like
You have seen these. They are expensive because they burn the goodwill the build earned.
The generic AI literacy keynote. Interesting for forty-five minutes. Changes nothing about how onboarding runs on Tuesday. Useful for companies buying awareness. Wrong deliverable when you shipped a production workflow.
Training after go-live crunch. Scheduled when the team is clearing backlog from the migration nobody scoped. Attendance is optional in practice. Half the room is on laptops doing the old process.
Documentation that only engineers read. A README in the repo does not help finance find the reconciliation step. Runbooks belong in operator language, in operator channels.
Champions with no backup. One power user holds the whole adoption. They leave; the system decays. Workshops should spread ownership — at least two people per workflow who can teach the third.
No metric for adoption. If success is "we trained 40 people," you learned attendance. Success is "these three workflows run daily without escalation to engineering." Tie training outcomes to the same operating metric that scoped the build.
#The decision before you sign the SOW
Ask these questions before training becomes a footnote:
- What named workflows will each department run daily within two weeks of the last workshop? Vague answers mean vague adoption.
- Who writes the runbooks, and where do they live? If the vendor "will provide documentation," specify format, audience, and update process when the UI changes.
- Is training in the critical path or the punch list? If it is scheduled after final payment, it is a punch list item. Move it before exit.
- How will leadership verify usage without asking IT for login counts? Named workflows and owners beat dashboard theater.
A build that ships without adoption is a pilot with a bigger price tag. When operational AI stops being a pilot, production means owners and exceptions — training produces the owners.
If you are buying AI tools without a build, the same standard applies: department workshops on real work, workflows shipped per team, follow-up so workshop energy does not fade in month two. Capability without adoption is just budget.
Before you sign the next SOW, move training out of the punch list. Name the workflows each department will run daily, who writes the runbooks, and when the last workshop happens relative to final payment. The build is not finished until your team runs it without you chasing them back to the old spreadsheet.