Automation requests usually arrive in one of two broken shapes: too vague ("AI for our sales ops") or too prescriptive ("build a GPT that does X with a dropdown for Y"). The vague ones can't be scoped; the prescriptive ones scope the wrong thing, because they specify a solution before anyone's agreed on the problem.
The fix is a one-page request that describes the workflow, not the software. Anyone who runs the workflow can write it in thirty minutes.
01The one-page template
- ▸The trigger. What event starts this workflow? An email arrives, a call ends, a form is submitted, a date passes. Automation attaches to triggers — a workflow that starts "whenever someone remembers" needs a trigger designed first.
- ▸The walk-through. One real, recent execution, step by step, with the actual systems named. Not the idealized process — the real one, including the part where you check a spreadsheet that only Dana updates.
- ▸The inputs and outputs. What information does each step consume, and where does it live? What does the workflow produce, and where does it land? Name the systems: "the CRM" is scopeable, "our data" is not.
- ▸The judgment points. Which steps require someone to decide something? These become review gates or stay human. Everything between them is automation surface.
- ▸The exceptions. What are the weird cases, and how often do they occur? A workflow that's 90% routine with known exceptions is a great candidate. One that's 50% exceptions is a process problem, not an automation problem.
- ▸The finish line. One sentence: "This is done when a user can ___." This sentence becomes the acceptance criterion — the thing everyone points at when deciding whether the build shipped.
02The two questions that do the work
If the one-pager feels heavy, start with the two questions that carry most of the scoping value:
"Walk me through the last time you did this." — Past tense, specific instance. It routes around how people think the process works and surfaces how it actually ran, exceptions and workarounds included.
"What would make you stop trusting the automation?" — This question extracts the real acceptance criteria. The answers ("if it emailed the wrong client," "if it missed a rush order") define the guardrails and review gates better than any requirements workshop.
03A filled-in example
Here is the template filled in for the most common first request we see — sales call follow-up. Trigger: a recorded sales call ends and the transcript lands in the call platform. Walk-through: the rep re-listens or skims the transcript, writes CRM notes from memory, drafts a follow-up email, updates the deal stage, and pings their manager if the deal moved — usually that evening, sometimes never. Inputs: the transcript (call platform), the account record (CRM), the last three emails (inbox). Outputs: a CRM activity note, a follow-up draft, a stage change, an optional manager summary — landing in CRM, inbox, and Slack respectively.
Judgment points: whether the deal actually moved stage, and whether the follow-up makes a commitment (pricing, timeline) that needs the rep's sign-off — so drafts route through the rep, and stage changes above a threshold queue for confirmation. Exceptions: calls with multiple deals discussed, calls where the prospect asked for legal or security documents — both flagged for manual handling, both roughly one call in ten. Finish line: done when a rep ends a call and finds usable CRM notes and a follow-up draft waiting within ten minutes.
Notice what the one-pager did: it quietly decided the review pattern (draft mode), the riskiest automation surface (commitments), and the v1 exclusions (multi-deal calls) — before anyone talked about models or tools. That is the document doing the scoping.
04What a good request unlocks
A workflow described this way can be scoped in credits, days, or dollars within a working session — because the unknowns are named instead of buried. The build team can propose which steps automate now, which need a human gate, and which exceptions stay manual. And when the scope comes back, you can evaluate it against the finish-line sentence instead of a feeling.
The one-pager also filters honestly: some workflows, written down, reveal themselves as not worth automating — too rare, too judgment-heavy, too broken. That's the template working. An afternoon of writing beats a month of building the wrong thing.
OPERATOR NOTE — If nobody on the team can write the walk-through, the workflow doesn't have an owner. Fix that before requesting anything.
Put this thinking to work.
A 30-minute strategy call with an operator — we'll map your first deployment path, not send a deck.