How Do You Document a Workflow So AI Can Do It?

To document a workflow so AI can do it, write the work down the way a brand-new hire would need it on day one: what starts the task, what information it needs and where that information lives, every step in order, each decision and the rule behind it, what counts as done, and what usually goes wrong. Build the document by watching the work happen, not from memory.

This is part two of the Digital Employee Playbook. Part one explained why AI works best as a digital employee with one defined job. This part is the job description's raw material.

Why does AI automation start with documentation?

Because AI can only follow work that has been written down. In most businesses, the real process lives in the heads of two or three people who have done it for years. They know which referring office always forgets the insurance card, which payer portal times out after lunch, and which patients need a call instead of a text. None of that is in a manual.

An AI system has none of that background. Every exception nobody wrote down becomes a case the system handles wrong, or a case that silently stops. That is why every AI Workflows engagement at Cream Digital starts with an operations audit that maps how the work moves before anything is built.

What should a workflow document include?

Nine parts. Together they describe the task completely enough that someone, or something, with no background could do it.

1. Trigger: the event that starts the task. A fax arrives, a form is submitted, a date is reached.
2. Inputs: every piece of information the task needs, and the system or document it comes from.
3. Steps: each action in order, one verb per step. "Check eligibility in the payer portal," not "handle insurance."
4. Systems: every tool the task touches: the EHR or practice management system, CRM, phone, e-fax, email, calendar, payer portals, spreadsheets.
5. Decisions: every point where the next step depends on something, and what it depends on.
6. Exceptions: what goes wrong, how often, and what the person does about it today.
7. Output: what exists when the task is finished: a scheduled appointment, an updated record, a sent letter.
8. Definition of done: how anyone can tell the task is complete without asking.
9. Owner: who is responsible for the task, and who gets the cases nobody else can finish.

Add two numbers to the top of the document: how many times the task happens per week, and how many minutes each one takes. Those two numbers decide whether the workflow is worth automating at all.

How do you capture how the work is really done?

Watch it, then check it against real cases. Descriptions from memory skip the steps people no longer notice they do.

• Sit with the person doing the task for a few hours, or record their screen with their permission, and write down every click and every system they switch to.
• Ask "what do you do when..." after every step. When the insurance card is missing? When the patient does not answer? When the fax is unreadable?
• Collect 20 real recent cases, including the messy ones. Walk through each one against the document and see where it breaks.
• Look for the side systems: the sticky notes, the personal spreadsheet, the "call Jenny" step. Those are the undocumented rules.
• Time each step. The slowest step is often a wait, such as hold time with a payer, not work.

What does a documented workflow look like?

Here is the workflow most specialty practices run for a new referral, documented at the level an AI system needs. It is the running example for the rest of this series.

Trigger: a referral arrives by e-fax or through the referral portal. Volume and time: count the referrals per week and the minutes each takes from arrival to scheduled, before changing anything.

Exceptions (from the 20 real cases): missing insurance card, illegible clinical notes, a patient who does not answer after three attempts, a referral marked urgent, a duplicate referral for a patient already scheduled.

Definition of done: the patient has an appointment on the calendar, the record is complete in the EHR, and the referring office has been notified. Or the referral has been closed with a documented reason.

Owner: the referral coordinator; urgent and clinical questions go to the nurse on duty.

Notice what this table does not say yet: what "complete" means in step 2, which plans need authorization in step 4, or how many contact attempts count as "not reached" in step 6. Those are the decisions, and they get their own document in part three.

How detailed should workflow documentation be?

Detailed enough that a capable temp could do the task in a day without asking anyone a question. Two tests help:

• The vague verb test. Any step that says "handle," "review," "process," or "deal with" is hiding several steps. Break it down until each step is one action in one system.
• The "it depends" test. Every time the person says "it depends," mark it as a decision. Do not try to resolve it while documenting. Just capture what it depends on.

What do you do with the document once it is written?

Use it four ways. It is the specification for the automation build. It is the training manual for new staff, who usually benefit as much as the AI does. It is the checklist for quality reviews. And its volume and time numbers are the baseline you measure the automation against.

If documenting your workflows sounds like the hard part, it usually is. It is also the part that decides whether the automation works. A free AI audit is where Cream Digital does this mapping with your team.