Skip to content

TemplateWrite it down

The Workflow Brief: write the workflow down before anyone automates it.

Before anyone automates a workflow, someone has to say how it runs today. The brief does that on one page: what starts it and what finishes it, who owns it, the steps and systems, the exceptions, the rules, and today's numbers with how sure you are of each.

The builder

Fill it in on the left. The brief writes itself on the right.

Fill in what you know and leave the rest. A half-finished brief still shows where the gaps are. Ask the people who do the work; they know the exceptions.

Your entries stay in this browser. Nothing you type is sent to us.

01The workflow in one line.

What starts it and what finishes it. If you cannot say both, the scope is not settled yet.

02Who owns it, and who does it.

One owner judges the result and can change the process. The people who do the work know where it really breaks.

03How often it happens.

Volume decides how fast a fix pays back. Note the busy days and anything that arrives after hours.

04The steps today.

Each step and the system it happens in, in order. Retyping between two systems usually shows up here.

05The systems it touches.

A system can only work on what it can read. Name who can grant read access to each one.

06Real examples you can pull.

A month of real orders, invoices, calls or emails shows the work as it is, odd cases included.

07The exceptions.

The cases that do not fit, and who handles them. Most of the time goes here.

08The rules and approvals.

Limits, tolerances and who signs. These stay with your team whatever gets automated.

09Today's numbers.

Time per item, errors and delay, each marked measured, estimated or a guess. This is the baseline any result is judged against.

10What would prove it worked.

The one number that would tell you, in three months, that the fix paid.

11What stays with a person.

The decisions nobody should hand to a system, written down before anyone builds.

Workflow brief · 0 of 11 sections

Name the workflow

The workflow in one line
Not filled in yet
Who owns it, and who does it
Not filled in yet
How often it happens
Not filled in yet
The steps today
Not filled in yet
The systems it touches
Not filled in yet
Real examples you can pull
Not filled in yet
The exceptions
Not filled in yet
The rules and approvals
Not filled in yet
Today's numbers
Not filled in yet
What would prove it worked
Not filled in yet
What stays with a person
Not filled in yet

Keep it

Booking a call? Paste this into the notes on the booking form: “Our workflow.”

Why the brief comes before any build.

Most automation projects stall on questions nobody wrote down. Who decides when an invoice is off by a few dollars? Which inbox do the orders really arrive in? What happens to the call that comes in at 9 at night? The brief puts those answers on one page while the people who know them are in the room.

It also fixes the baseline. Mark each of today’s numbers as measured, estimated or a guess. A guess is fine to start with, as long as it is labelled. It tells you which number to measure first, and it keeps anyone, us included, from claiming a result against a figure nobody checked. The paper on measuring AI in dollars explains why that matters after launch.

Where the numbers come from.

Use the work itself. For calls and web inquiries, the lead response audit gives you the median and the slowest reply. For vendor invoices, two weeks of the invoice exception log gives you the exceptions and the hours they take. Not sure which workflow to brief? Start with the Workflow Shortlist.

What we do with it on the call.

Bring the brief to a 30-minute intro call, or paste its one line into the notes when you book. We read it with you, ask about the exceptions, and tell you straight whether a play from the StrikeArc PowerPlays Library fits. If nothing in our library fits, we say so.

Keep going.

The Workflow Brief

Workflow: ________________________________ Owner: ______________________ Date: ____________

01 The workflow in one lineWhat starts it and what finishes it. If you cannot say both, the scope is not settled yet.
02 Who owns it, and who does itOne owner judges the result and can change the process. The people who do the work know where it really breaks.
03 How often it happensVolume decides how fast a fix pays back. Note the busy days and anything that arrives after hours.
04 The steps todayEach step and the system it happens in, in order. Retyping between two systems usually shows up here.
  1. 1.
  2. 2.
  3. 3.
  4. 4.
  5. 5.
  6. 6.
  7. 7.
  8. 8.
05 The systems it touchesA system can only work on what it can read. Name who can grant read access to each one.
06 Real examples you can pullA month of real orders, invoices, calls or emails shows the work as it is, odd cases included.
07 The exceptionsThe cases that do not fit, and who handles them. Most of the time goes here.
08 The rules and approvalsLimits, tolerances and who signs. These stay with your team whatever gets automated.
09 Today's numbersTime per item, errors and delay, each marked measured, estimated or a guess. This is the baseline any result is judged against.Time per item: ______ Errors: ______ Delay: ______ For each: measured, estimated or a guess
10 What would prove it workedThe one number that would tell you, in three months, that the fix paid.
11 What stays with a personThe decisions nobody should hand to a system, written down before anyone builds.

How to get started

Bring the brief to a 30-minute call.

Book an intro call

We will read it with you and tell you straight whether a play fits.