Building and Testing Your Workflows

A plan is only as good as the working methods behind it. In this lesson you will turn each retained task into a documented workflow: its goal, its input, its prompt, its expected output, its verification and its limits. Then you will test it, compare before and after, and evaluate the quality with a simple grid, so that your plan rests on evidence and not on enthusiasm.

In the previous lesson you chose three to five tasks. Each of those tasks becomes a workflow sheet. This is the heart of the project: when someone else can pick up your sheet and get the same quality of result, you have a real working method, and not just a handy trick.

The workflow sheet

A workflow sheet is a one-page description of how a task is done with AI. It has seven parts. Every part answers a question that you or a colleague will ask later.

Part	Question it answers
Objective	What is this workflow for, and for whom?
Input	What do I need to provide, in what form, and what data must never be included?
Prompt	What exact text do I use, with which placeholders?
Expected output	What should the result look like (format, length, tone)?
Verification	What do I check, how, and who validates?
Limits	When does this not work or should not be used?
Owner and version	Who maintains it, and when was it last reviewed?

A ready-to-use template

WORKFLOW SHEET
Name: [short name]                      Version: [1.0]   Date: [ ]   Owner: [ ]
Objective: [what it does, for whom, in what situation]
Tool: [approved tool]    Data level: [green / orange / red]
Input needed: [what to provide]
Never include: [data that must stay out]

Prompt:
[full prompt with [placeholders]]

Expected output: [format, length, tone, structure]
Verification (before use):
1. [e.g. compare each figure and date with the source]
2. [e.g. check there is no promise or claim not in my notes]
3. [who validates, if anyone besides me]
Limits and known failures: [where it does not work, cases to handle by hand]
Before/after measurement: [indicator, baseline, result]
Notes for improvement: [ ]

Documenting 3 to 5 workflows

Here is a complete example from Marc's plan, so that you see what "done" looks like. Marc retained three tasks, and this is the sheet for the second one.

WORKFLOW SHEET
Name: Site report from notes          Version: 1.1   Owner: Marc
Objective: Turn my end-of-day notes into a short report I can send to the customer or keep in my records.
Tool: approved business account       Data level: orange (no customer identity)
Input needed: 5 to 10 lines of notes: work done, findings, work remaining, next visit.
Never include: customer name, address, phone, photos of people or documents.

Prompt:
Turn the notes below into a short site report with: work completed, observations, recommendations, remaining work, next appointment. Use only what is in the notes. If something is ambiguous or missing, list it under "To clarify". Plain language, under 150 words, no technical conclusions or compliance statements.
Notes:
[notes]

Expected output: five short sections plus a "To clarify" list.
Verification: 1. Every statement appears in my notes. 2. No cause, compliance or safety conclusion that I did not state. 3. Add customer details by hand at the end.
Limits: Not for incidents with safety consequences, which I write myself. Weak on long jobs with many steps: split by day.
Before/after: average minutes per report by hand versus with the prompt, including checking (measured on 10 reports; results recorded in the log).
Notes for improvement: add "write in the same style as my previous reports" with one example.

Marc fills in the before/after line with his own measurements. Yours will be different, and no figure from this course should be treated as a target.

Testing a workflow

Do not trust a workflow after a single success. Test it with a deliberate method.

1. Build a small test set

Gather five to ten real or realistic inputs (anonymized): typical ones, difficult ones, incomplete ones and one where the right answer is "this cannot be done". Variety matters more than quantity.

2. Run and record

Run the prompt on each input. Record the output, how long it took, how much you had to correct and what went wrong. Keep these records in your adoption file.

3. Evaluate with a quality grid

Judge outputs with the same criteria every time. A simple grid rates each criterion from 1 (poor) to 3 (good):

Criterion	Question
Accuracy	Are facts, figures and names correct and faithful to the input?
Completeness	Is anything important missing or omitted?
Fit	Does it respect the audience, tone, format and length requested?
Safety	No invented claims, no confidential data, no unwanted commitments?
Effort	How much correction did it need (1 = a lot, 3 = very little)?

Define a threshold in advance, for example: "accuracy and safety must be 3 on every test; the total must be at least 12 out of 15". For a critical criterion such as safety, one failure should lead to a revision of the prompt, whatever the total.

4. Improve and re-test

Each failure suggests a fix: add a constraint, an example, a "do not" rule, a placeholder for missing data. Change one thing at a time, increase the version number and run the test set again. Stop when the results are stable, not when you are tired.

A ready-to-use prompt: find the weak points of your own prompt

Here is a prompt I use in a workflow:
[paste the prompt]

And here are three outputs, with what was wrong in each:
1. [output summary and problem]
2. [output summary and problem]
3. [output summary and problem]

Analyze why the prompt may have produced these problems. Propose a revised version with explicit constraints, and list 5 test inputs (including 2 difficult and 1 where the correct response is "not enough information") that I should use to check the new version.
Do not change the goal of the prompt. Explain each change you make.

The before and after protocol

Return to the measurement sheet from chapter 5. For each workflow:

1. Before: measure the task without AI (time, quality score, satisfaction) on at least five occurrences. If you did this earlier, reuse it.
2. After: measure the same indicators with the workflow, counting preparation, checking and correction.
3. Compare using the same grid and the same criteria, preferably with a colleague scoring quality without knowing which version came from AI.
4. Decide according to your pre-defined rule: keep, adjust or stop.

Be ready for mixed results. A workflow that saves time but lowers quality needs a better prompt or a stronger check; a workflow that does neither should be dropped. Dropping a workflow is a perfectly good result: it saves you from investing in something that does not pay off.

Bad use versus good use

Bad practice	Good practice
Declaring a workflow "validated" after three good examples.	Testing on a varied set with difficult and incomplete cases, scored with a grid.
Changing five things in the prompt at once.	Changing one element at a time and re-testing, with version numbers.
Leaving the prompt in your head or in a chat history.	Documenting it on a sheet that someone else could follow.

Your turn: three documented, tested workflows

Exercise. For each of your retained tasks (three at least), complete a workflow sheet. For at least two of them, build a test set of five inputs, run the prompt, score each output with the quality grid and record the time spent. Revise the prompt once, increase the version and re-test. Write your decision for each workflow: keep, adjust or stop, and the reason.

See a solution

Nadia documents three workflows: "job ad from a brief", "welcome email for a new employee" and "training outline for a 45-minute session". For the job ad, her test set contains five different briefs, including one with a long list of requirements and one with almost no information. Scores: accuracy 3, 3, 3, 2, 3; safety 3 on four tests, and 2 on one test where the draft promised "flexible hours", which was not in her brief. By her rule, a safety score below 3 requires a revision.

She adds "Do not mention benefits, working hours or salary unless provided" to the prompt, moves to version 1.1 and re-runs the five briefs: safety is 3 everywhere. Her decision: keep the job ad workflow, adjust the training outline (two outlines had inaccuracies she had to correct) and stop the welcome email workflow, because writing the email herself takes as long as checking the draft. Dropping it was a legitimate result of the evaluation.