The question that decides whether a team gets value from AI is not which model to use. It is which job to start with. Pick well and the first workflow pays for itself inside a month and creates demand for the second. Pick badly and you spend six weeks proving that the technology does not work, when what actually failed was the selection.
This is a selection method, not a strategy deck. It gives you four filters, a scoring matrix, a set of red flags, and a one-week audit you can run with the people who already do the work.
Part 01 · The trap
Why “automate everything” stalls teams
The most common failure is not a bad model. It is a candidate list with no filter applied to it.
Why breadth-first AI adoption stalls
Teams that start by listing every task AI could touch end up with thirty candidates, no owner, and no finished workflow. Breadth produces enthusiasm and then a stall, because nothing on the list is small enough to finish and nobody is accountable for any single item.
One useful email a week
Get one workflow teardown a week.
A practical look at how a real repeated job becomes a reliable AI workflow — inputs, review points, and the failure modes to avoid.
By subscribing, you agree to receive Grokkit’s weekly workflow teardown. Unsubscribe anytime.
Depth-first works better. One job, built properly, ends with a thing people use on Monday. That artifact does more to convince a sceptical team than any number of demos, and it gives you a template for the second job.
The four filters for a first AI workflow
Apply four filters before anything else. A candidate that fails any one of them is not your first workflow — it might be your fourth.
These filters are deliberately about the job, not the technology. They are the same filters that would tell you whether a job is worth writing an SOP for, which is not a coincidence.
- It repeats — weekly or more often, by more than one person
- The output is reviewable — a human can tell good from bad in under ten minutes
- A method already exists — somebody does it well and can explain how
- Inconsistency costs something — rework, a lost renewal, a missed risk, an unhappy client
Jobs that look automatable but are not ready
Some jobs pass the surface test and fail in practice. Anything where the correct answer depends on undocumented relationship context, unwritten pricing discretion, or a judgment nobody can articulate will produce confident, wrong output that reviewers cannot efficiently correct.
The tell is that two experienced people produce materially different outputs from the same inputs and both are defensible. That is not a workflow candidate yet. It is a candidate for a conversation about what the standard actually is.
Frequency versus pain: weekly beats heroic one-offs
Teams instinctively nominate the worst job — the quarterly board pack, the annual renewal audit, the horrible migration. These are memorable precisely because they are rare, which makes them terrible first candidates: you get one or two chances a year to learn anything.
A weekly job gives you roughly forty runs a year. You will find the edge cases in three weeks instead of three years, and the workflow will be genuinely good by the time the painful quarterly job comes around — at which point you will know how to build for it.
Time spent prompting versus time spent repairing output
Ask people already using AI for this job where their time goes. If they spend ten minutes prompting and forty minutes repairing the output, the job is a strong candidate: the repair time is the cost a specified workflow removes.
If they spend forty minutes prompting and the output is then fine, the value is in packaging the prompt — real, but smaller. If they spend forty minutes prompting and still throw the output away, the job is probably in the “not ready” bucket above.
Part 02 · Signals
Where the best candidates hide
Four patterns reliably produce good first workflows, plus the matrix that ranks them.
Single-owner bottleneck jobs
Find the job that only one person can do properly. Every team has two or three: the person who writes the account brief, the one who can read the support queue and tell you what is actually breaking, the one who assembles the weekly number.
These are high-value candidates because the cost of the bottleneck is already visible — work waits when that person is on leave. Capturing their method is also the most defensible reason to build: you are not replacing them, you are stopping the business from being one holiday away from a gap.
Handoff-heavy jobs between functions
Work that crosses a boundary — sales to delivery, support to product, research to decision — loses fidelity at the handoff. The receiving team gets something in the wrong shape and spends an hour reconstructing context that existed on the other side.
A workflow that produces a fixed output shape fixes the handoff, not just the drafting. That makes the benefit obvious to two teams at once, which helps enormously with adoption.
Jobs with a clear template nobody follows
If there is a template in the shared drive that half the team ignores, you have found a job where the standard is already agreed and only the execution is inconsistent. That is the cheapest possible first workflow, because the definition of done is largely written.
Interrogate the template first. Templates get ignored for reasons — usually because they ask for fields nobody can fill, or because they were designed for a different kind of client. The workflow should encode the version that experienced people actually use. A marketing planning cycle is a common instance of this pattern, and a client engagement that scoped exactly that way is written up in from a messy knowledge base to a review-ready plan.
A scoring matrix: impact, readiness, risk, data access
Score each surviving candidate one to five on four axes and rank by the total, with any score of one on risk or data access acting as a veto rather than a deduction.
The matrix is not precise and does not need to be. Its purpose is to make the trade-off visible so that the choice is a decision the team made rather than the loudest person’s preference.
- Impact — hours, rework, or revenue affected if the output is consistently good
- Readiness — is there an articulable method and a definition of done?
- Risk — what happens if a bad output gets through review?
- Data access — can the workflow actually reach the sources it needs, legally and technically?
Start with assisted output, not unsupervised action
The first workflow should produce a draft that a named human approves before anything leaves the building. Assisted output makes failure cheap: a bad draft costs a reviewer five minutes, while a bad autonomous action costs a client relationship.
Autonomy is earned by evidence, not granted at design time. Once you have thirty logged runs and a reviewer who reports they are changing almost nothing, you have an argument for widening the boundary — the mechanics are in widening a workflow’s boundary on evidence.
Part 03 · Discovery
Getting the job right before you build
Most selection errors are really discovery errors. This is how to avoid them.
Customer-facing versus internal-first workflows
Internal-first is the safer starting point. An internal weekly summary, a research brief, or a handoff document can be wrong in a way the team absorbs and learns from. A client-facing deliverable cannot.
The exception is when the client-facing job is heavily reviewed anyway. A proposal that always passes a partner’s desk already has a gate, so the workflow slots in behind an existing control rather than needing a new one. Of the internal candidates, a recurring research brief is often the strongest, because the output contract is unusually easy to specify — see a recurring research brief.
How to interview the person who already does it well
Do not ask how the process works. Ask them to do it in front of you with a real example from last week, and narrate. You are collecting the decisions, not the steps: what made them check that source, why they flagged that line, what would have made them escalate.
Two sessions with the same person, using a clean case and a messy one, will give you more usable material than any amount of documentation review. The full method is in extracting a method from your best people.
Capturing the real job, not the documented SOP
The documented SOP is usually a description of the process as it was designed, not as it is run. The gap between them is where all the useful knowledge lives — the shortcuts that are fine, the steps that were dropped because they never mattered, the check that was added after an incident nobody wrote up.
Build from the real job and then decide, deliberately, which parts of the official process to reinstate. A workflow that encodes a fiction gets abandoned in week two.
Definition of done as the go/no-go for selection
Write the definition of done before you commit. If you cannot describe, in one paragraph, what a finished output contains and what makes it acceptable, the job is not ready to be built — and that is a genuinely useful outcome of the audit.
A good definition of done names the sections, the evidence standard, and the disqualifiers. “A one-page brief with situation, risks, and recommended action, every claim attributed to a named source, no invented dates” is a specification. “A useful summary” is not.
Pilot size: one job, one team, one reviewer
Constrain the first build hard: one job, one team of two to five people, one named reviewer, one success metric. Anything wider makes it impossible to tell what worked. Founder-led teams are already at that size, which changes the calculation rather than removing it — see the small-team playbook.
The narrow pilot is also what makes the rollout tractable later, because you finish with a workflow that has been used rather than a workflow that has been announced. The full sequence is in rolling out AI workflows across a team.
Part 04 · Commit
Deciding, and what to leave alone
Success criteria, red flags, and a worksheet you can run this week.
Success criteria for the first 30 days
Agree the measure before you build, and make it something a reviewer can observe rather than something you have to survey for. Time to first review-ready draft, percentage of required sections complete on the first pass, and the count of factual corrections per run are all cheap to record.
Take a baseline first. Run ten real jobs the current way and record the same three numbers. Without a baseline, any improvement claim afterwards is unfalsifiable — the reasoning is spelled out in the business case for custom AI workflows.
What to postpone: high-risk, high-variance, legally binding work
Postpone anything that creates a legal obligation, anything where a wrong answer is expensive and hard to detect, and anything with genuinely high variance in what a correct output looks like. Not permanently — just not first.
Regulated advice, contract terms, pricing commitments, hiring decisions, and anything touching health or financial outcomes belong in a later phase with a heavier control design and a legal sign-off, as covered in security, privacy, and source control for team AI skills and in work that should stay with an accountable human.
Red flags in discovery calls
Some answers should make you pause and re-scope rather than proceed. They are not disqualifying on their own, but two or more in the same job usually means the discovery is not finished.
The most reliable red flag is the absence of an example. If nobody can produce three real past outputs from the last month, the job either does not repeat or is not documented well enough to build against.
- “It depends” with no follow-up explanation of what it depends on
- No one can produce three recent real examples of the finished output
- Every stakeholder describes a different definition of done
- The only available inputs are in someone’s head or a locked system
- The sponsor wants it fully autonomous on day one
A one-week process audit worksheet
Run this in five days without stopping normal work. Monday: list candidates and apply the four filters. Tuesday: score the survivors on the matrix. Wednesday: two shadowing sessions on the top candidate, one clean case and one messy. Thursday: draft the definition of done and collect ten real past outputs. Friday: write the success criteria and take the baseline.
You finish the week with a chosen job, a written standard, a test set, and a number to beat. That is the entire input a build needs, and collecting it is the part teams most often skip. If the chosen job turns out to be a common one, check the skill library and the bundles before commissioning anything.
How Grokkit scopes one important repeated job
Our engagements start at exactly this point, because the scoping is the part that determines whether the build is worth doing. We run the shadowing sessions, write the definition of done with the person who already does the job well, and build the test set from your real history rather than clean examples.
If the job turns out to be a common one, a ready-made skill from the library is usually the faster answer. If it carries your own rules, sources, and approval logic, the four stages are described on the custom workflows page, and the worked examples show what a finished output looks like before you commit to anything.