How to Turn a Team SOP Into a Reusable AI Workflow (Discover → Build → Test → Deploy)

The job repeats on a rhythm you can name. More than one person runs it or reads the output. The team can point at a past example and agree it was good. And someone can state, in one sentence, what the finished thing must contain.

A fifth signal is the most reliable: people are already fixing the same things in AI output by hand. Those repairs are the procedure you are about to write down. When several jobs clear the bar at once, rank them rather than starting all of them — the scoring matrix is in ranking candidates with a scoring matrix.

Skip jobs where the team genuinely disagrees about what good looks like, where the inputs do not exist in any retrievable form, or where a wrong output is both likely and expensive to discover late.

Also skip anything that is really a deterministic rule. If the logic is “when status equals X, create Y,” that is an automation, not a workflow, and a language model in the path only adds variance.

Every workflow starts with something concrete: a call ends, a ticket arrives, Thursday happens, a release branch is cut. Name it precisely, because the trigger decides whether a person runs the skill or an agent does.

Vague triggers — “when we need one” — are a sign that the job has hidden entry conditions worth surfacing now rather than discovering in production.

List every source the job actually consumes, then mark each one as required or optional, and reliable or unreliable. That second axis matters more than teams expect — half-maintained CRM fields cause more bad output than model limitations do.

Where a source is unreliable, the workflow needs an explicit rule: prefer the transcript over the CRM field, or flag the conflict rather than picking silently.

Ask your best practitioner to talk through three recent runs and stop them every time they make a choice. Those choices are the decision points, and the interesting ones are always exceptions: the angry customer, the missing test result, the deal that does not fit the template.

Exceptions are where generic templates fail, so they deserve more of the design budget than the happy path does.

Name who reads the output and what they are checking for. Then decide which steps they must approve before anything leaves the building — anything customer-facing, financial, or reputational should default to explicit approval.

Approval points are a design input, not an afterthought. They determine what the output has to make easy to verify.

The definition of done should be a list of statements that are true or false about a finished output, not adjectives. “Every claim names its source” is checkable. “Professional tone” is not, unless you specify what violates it.

This is the single highest-value artifact from discovery. It becomes the acceptance checks, the test criteria, and the reviewer’s scan list — three uses from one paragraph.

Be specific about what is in scope and, just as importantly, what is out. A workflow allowed to use “company documents” will eventually cite something outdated; a workflow allowed to use three named locations will not.

The same applies to tools. State what it may call and what it may never call, especially anything that sends, posts, or writes. Naming three locations rather than “company documents” also forces a decision about where each kind of material belongs, which is the subject of where each kind of material should live.

The gap between your best practitioner and your average one is the thing worth encoding. Interview for the judgment: what makes them soften language, escalate early, distrust a field, or ask one more question.

This is also the part that is hardest to recover later. Do it while the person is available and interested.

A skill is a single unit: the procedure, the reference material it depends on, any templates it fills, and any scripts it can run. Keeping them together is what makes the thing installable rather than a set of instructions plus a scavenger hunt.

Keep the procedure compact and push detail into references. Long instructions dilute; referenced material stays available without competing for attention. The file-level conventions — routing, activation boundaries, output schema, checks — are in the SKILL.md file conventions.

Write the procedure for the typical case, then add explicit branches for the two or three messy shapes you know occur: the truncated transcript, the missing CRM record, the contradictory update.

Each branch should say what to do, not just what to notice. “Flag and continue” and “stop and escalate” are different instructions and the difference matters at three in the afternoon on a Friday.

Convert every “be careful about X” into a rule with an observable violation. Never state a date that does not appear in an input. Never draft an external commitment. Escalate when the account owner cannot be determined.

Written this way, each guardrail is also a test case, which is why this step makes stage three nearly free. More categories are in guardrails, escalation rules, and approval points.

Pull cases from actual history: five typical, three messy, two genuinely hard. Use real inputs with names changed if needed, because synthetic inputs are always tidier than reality in exactly the ways that hide problems.

The suite is an asset. It outlives the first version of the skill and is what makes future changes safe. How to test an AI workflow covers the construction in depth.

Score each run against the definition of done, not against a general impression. Structure present, claims attributed, unknowns declared, no invented specifics, correct next step.

A run that reads beautifully and fails an attribution check is a failed run. Holding that line early is what makes the workflow trustworthy later.

Catalogue how this specific job goes wrong: omission, invention, wrong source, wrong owner, wrong next step. Then decide what the workflow should do when it detects each — usually flag or stop, rarely proceed.

Teams that skip this end up with a workflow that has one behaviour for every situation, which is to produce something confident.

The process is portable; the plumbing is not. Expect to adapt file handling, tool connections, and install mechanics per platform while the method, sources, checks, and output spec stay identical.

The practical architecture for this is in the practical cross-tool architecture.

One page: how to install it, how to run it, what to paste in, what to check before approving, and who to tell when it misbehaves. Screenshots beat prose for the install steps.

If the guide is longer than a page, the workflow is probably doing too much and should be split. The guide is only half of deployment; the four-week sequence that gets a team actually using it is in the four-week rollout sequence.

Processes change — a new escalation threshold, a new required section, a new source system. Each change gets a version bump, a changelog line, and a re-run of the test suite.

The changelog is where the reasoning lives. A rule without its reason gets deleted by the next maintainer who finds it inconvenient.

At minimum: the skill itself, the test cases and their results, the install guide for each target tool, the guardrail list, and a named owner on your side who can maintain it.

If an engagement hands over a prompt and a demo video, you have bought a demonstration rather than a workflow. The four stages above are what a Grokkit engagement produces, and the questions to put to any vendor before signing are in the buyer’s guide.

Three numbers are enough. How much did the reviewer change before sending? Did every output arrive in the same shape? How long did review take compared with the manual baseline?

Capture the baseline before launch. Without it you will be arguing about impressions in a month. Which numbers survive scrutiny in front of an economic buyer — and which get a business case rejected — is covered in what to leave out of an ROI case.

Before your first engagement call, fill in one page: the trigger, the inputs and their reliability, the decisions and exceptions, the reviewers and approval points, the definition of done, and three real past examples.

Teams that arrive with this page cut discovery roughly in half. If you want a second opinion on whether a job is ready, describe it to us — and the worked examples show what the finished output looks like.