Make training a ship gate, not a slide after launch.

UI shipped is not operators ready

The release notes say done. The screens look finished. Support opens on Monday and the first awkward case has no practiced path. Someone screenshares folklore. The product worked in the demo tenant; the humans who must run it did not get a ship gate.

Training is often treated as a slide after launch. That habit ships unfinished work. Operators are part of the product surface—especially when the system mixes desk work, field capture, exceptions, and handoffs between tools that each look fine alone.

This note gives you the TWIMCO Operator Training Path Spec: role cards, scenario checklist, pass evidence, and a cannot-go-live-until rule. It is distinct from a field-capture brief (observation before screens), a software-handover scorecard (next team capability), and a visible-state spec (shared record design). The Spec makes training inspectable before the flag flips.

On WorkStep, mobile and field workflows only succeed when the people doing the work can complete real scenarios—not only click through a happy path. Ongoing verification partnerships like Sutton|Place treat who may act as an operating fact. Build the same honesty into training. Scoped product work often lives under web applications or mobile application delivery when the surface is in the field.

A forthcoming studio tool is planned to assemble these fields into a shareable path. Until then, fill the Spec by hand for one role and one release. Prefer one honest path over a corporate LMS course nobody finishes.

If your release includes agents that propose actions for humans to accept, training is not optional theater—it is how you keep autonomy bounded. The Spec still applies: scenarios must include reading a proposal, refusing it, and escalating when evidence is thin.

Fields of the Operator Training Path Spec

Role card (one per role that touches the release). Role name; systems they open; actions they may take; actions that require escalation; who coaches them; timezone and coverage window for go-live week. If two roles share a queue, write how work is claimed so training does not assume a phantom owner.

Scenario checklist. Three to seven scenarios drawn from real work—not marketing tours. Include at least one exception path, one recovery or retry, and one “where do I look when status is unclear” scenario. Each scenario names: trigger, expected operator moves, system of record to open, and wrong moves to avoid. Write the scenario in the operator’s words when you can.

Pass evidence. What proves the scenario is complete: recorded walkthrough timestamp, coach sign-off, shadow shift completed, or first live case under supervision with a note in the shared record. Quiz scores are optional and never sufficient alone. “They attended the webinar” is not pass evidence.

Cannot-go-live-until. Explicit gate: which roles must have pass evidence for which scenarios before the flag flips or the freeze thaws. Name the person who may waive a scenario and under what written condition. Silence is not a waiver. A waiver without a date and reason is folklore.

Optional: Regression training for behavior changes after go-live—same field shape, shorter list. Behavior changes without a communication brief and a training delta are how operators invent workarounds.

The unreproducible asset is your filled Spec for a real role set and release—the scenarios and pass evidence competitors cannot invent from a generic “write a training plan” prompt.

How to build the path without theater

Start from stuck cases and handoffs, not from the UI sitemap. Watch one ordinary day if you can. The scenarios that matter are the ones people already handle by judgment—and the ones that currently live only in Slack.

Pair product and operations when writing scenarios. Product knows the intended state machine; operations knows which screens people actually trust. Disagreement is useful—write it into the Spec as a scenario to resolve before go-live. If product says “the status is clear” and ops says “we always ping finance,” you have a visible-state problem and a training problem; the Spec should force both into the open.

Timebox coaching. A path that assumes unlimited shadow time will slip. Prefer fewer scenarios with real pass evidence over a long checklist nobody finishes. Schedule coaching on the calendar before the release candidate freezes—not as a hope after.

For field or mobile roles, include device and connectivity failure as a scenario—not as a footnote. Desk-only training for field work is theater. Include how to resume when the device comes back and how to avoid duplicate writes.

Keep language plain. If a scenario needs three acronyms to explain, rewrite the scenario or the UI label before you train on confusion. Training should not be how you teach people to decode a bad status model.

Tie the Spec to release, support, and change

Attach the filled Spec to the release ticket beside QA. Treat missing pass evidence like a failing test for the roles in scope. Engineering can ship code; the operating product is not shipped until the gate passes or a named waiver is written.

Support and success need the same scenarios. If support’s first reply is “can you send a screenshot?” for a case that has a named scenario, the Spec did not reach the people who answer the queue. Put scenario names in the support playbook so vocabulary matches.

After the first week, update scenarios with what actually confused operators. Stale Specs become folklore. Folklore is how teams retrain the same gap every quarter.

When agents or automation share the queue with humans, training must include how to read agent proposals and when to refuse them—same Spec fields, different scenarios. Do not invent measurement of “AI accuracy”; require evidence the operator can open before they act.

Coordinate with change-communication briefs when behavior changes mid-flight. Training without a brief leaves operators surprised; a brief without training leaves them informed but unpracticed.

Failure modes the Spec refuses

Webinar-as-done. Attendance without scenario evidence. The pass-evidence field blocks this.

Happy-path-only training. Exceptions deferred to “tribal knowledge.” Required exception scenarios block this.

Unowned waiver. Leadership says “ship anyway” without naming who accepted the risk. The cannot-go-live-until field demands a name and condition.

Role fog. “Everyone will figure it out.” Role cards force systems, actions, and escalation into the open.

These are delivery-shaped composites, not client telemetry. Use them to structure the ship conversation; do not invent completion rates to persuade a steering committee.

Put this into practice

1. Pick one upcoming release and the two roles most exposed to exceptions.
2. Fill role cards and three scenarios each, including one recovery path and one unclear-status path.
3. Define pass evidence and a cannot-go-live-until rule with a named waiver owner.
4. Run one dry scenario before the release candidate freezes; store evidence where the release ticket can link it.
5. Use WorkStep and Sutton|Place as delivery references for field and verification-shaped work; scope builds under web applications when the gap is the product surface itself.

Ship when the Spec’s required cells are filled—not when the UI looks done.