How-to guideFree templateAdded 9 Oct 2026

Agree how you’ll know it works before you build

Write what working looks like for one workflow, with safe examples, fail conditions and an owner, before anyone builds or buys a tool.

Use it when The team is ready to pick an app, bot or build, but nobody has yet agreed how you will know the workflow is working in real day-to-day use.

Download template

It is a simple text file. Open it in any text editor, or paste it into ChatGPT, Claude or Gemini and ask for help filling it in.

How to use it

Name the workflow, who uses it and what triggers it. Stay with real work; do not name a product yet.
Write what "done" looks like, safe sample inputs, expected behaviour, fail and stop conditions, and what evidence to keep. Leave blanks where you do not know.
Name an owner and a review date. Use the stop rules before anyone builds, buys or turns anything on.

What you will need before you start

One workflow the team wants to change or support, described in plain words
Someone who does that work today, and someone who can decide what "working" means
Agreement that no build, bot, app or hire will start until this sheet is filled

The template

Fill in the blanks for your business. This is what you get when you download or copy it.

Sheet header

Business or team:

Sheet owner:

Date:

Workflow name (one workflow only, in plain words):

Who uses it (role or person):

What starts it (the trigger):

What "done" looks like

Write one or two sentences that describe a finished run of this workflow in real work. Say what the person using it can see or do when it has worked. Do not name a product.

Safe sample inputs

List a few inputs the workflow should handle safely. Use made-up or anonymised examples. Do not put real customer names, phone numbers or money amounts here unless the owner agrees.

Sample input 1:
Sample input 2:
Sample input 3:
Inputs that must wait for a human (money, promises, complaints, medical or legal wording):

Expected behaviour

For each sample input, write what should happen in plain steps. Say who acts, what they see and what they pass on.

For sample input 1:
For sample input 2:
For sample input 3:

Fail and stop conditions

Write when the workflow must stop and hand to a person. Be specific.

Stop if:
Hand to a named person if:
Do not send, book, charge or promise anything if:

Evidence to keep

What record should remain after a run, so someone can see what happened later?

What to keep:
Where it will live:
Who can see it:

Owner and review

Named owner for this sheet:

Who else must agree before any build starts:

Review date (when you will check the sheet against real work again):

Stop rules

Do not start building, buying, hiring or turning on a tool until this sheet has a workflow name, who uses it, a trigger, what "done" looks like, safe sample inputs, expected behaviour, fail and stop conditions, evidence to keep, a named owner and a review date.
Do not invent pass rates, volumes, time saved or customer results. Write what people said, or leave it blank.
Money, medical advice, legal wording, refunds and promises to customers stay with a named human. They are not automatic outputs.
If two people disagree on what "working" means, record both views and pick one with a reason, or set a date to decide before any build.

See an example

A made-up example, so you can see what a filled-in version looks like.

This is an illustrative scenario, not a client case study or a measured result. Do not reuse its details as facts about your work.

A sample three-person physiotherapy clinic in Bengaluru wants appointment reminders. The owner, the receptionist and one physiotherapist run the clinic together. They have been looking at reminder apps and WhatsApp tools, but nobody has yet written down what "working" means for reminders before a build starts.

Sample inputs

Demonstration inputs only. No patient counts, reminder rates, no-show rates or costs are used. From a short talk with the owner, the receptionist and the physiotherapist: patients book by phone and WhatsApp; the receptionist writes appointments in a paper diary and a shared spreadsheet; the physiotherapist wants patients reminded the day before; the owner does not want reminder wording that sounds like medical advice; nobody has agreed what happens when a patient replies that they need to change the time.

Example output

Sheet header

[Fact within this demonstration] Workflow name: day-before appointment reminder for booked physiotherapy visits. Who uses it: the receptionist. Trigger: an appointment already written in the diary for the next day. Sheet owner: [Name the clinic owner].

What "done" looks like

[Inference] The receptionist can see that each next-day appointment either got a reminder or was marked as needing a human follow-up, without guessing from chat history. How often patients reply or attend has not been measured in this demonstration.

Safe sample inputs

[Fact within this demonstration] Sample 1: a routine follow-up visit already booked for tomorrow, with a phone number on the booking. Sample 2: a first visit tomorrow where the patient asked for WhatsApp only. Sample 3: a booking where the time was changed yesterday and the diary and spreadsheet may not match. Must wait for a human: any reply that asks what treatment to do, whether to stop exercises, or anything about fees or refunds.

Expected behaviour

Sample 1: send a short reminder with the date, time and clinic name; note that it was sent. Sample 2: send the same reminder on WhatsApp if that is the agreed channel; note the channel used. Sample 3: do not send until the receptionist has checked the diary and spreadsheet and confirmed the time. [Inference] The reminder should confirm attendance details only. It should not answer clinical questions.

Fail and stop conditions

Stop if the diary and spreadsheet disagree on the time. Hand to [Name the receptionist] if the patient replies with a change request, a clinical question or a fee question. Do not send, rebook, charge or give advice from the reminder itself.

Evidence to keep

Keep: which booking was reminded, which channel was used, whether a reply needed a human, and who handled it. Where it will live: [A column on the shared spreadsheet, or a short daily note the receptionist already keeps]. Who can see it: the owner and the receptionist.

Owner and review

Named owner: [Name the clinic owner]. Who else must agree: [Name the receptionist and the physiotherapist]. Review date: [Two weeks after the sheet is agreed, before any app is bought].

Stop rules applied

[Recommendation] Agree this sheet before shortlisting any reminder app or WhatsApp tool. Keep clinical replies, fees and rebooking with the named people. This recommendation is not the clinic’s decision.

How to tell it is done well

The sheet names one workflow, who uses it, the trigger, what "done" looks like, safe sample inputs, expected behaviour, fail and stop conditions, evidence to keep, a named owner and a review date; blanks stay visible where facts are missing; no pass rates or results were invented; nothing was built or bought before the sheet was filled.

Where a person should decide

The sheet records how you will know the workflow works; it does not prove that a tool is right, safe or worth paying for, and it does not check medical, data protection or consumer rules. A filled sheet is not approval to send reminders, give clinical advice, change fees or turn on automation. Keep consequential actions with the named human owner.

Edit your own copy on this site

About this version

New in Kosh at version 1.1. Provider-neutral Markdown instructions; no installation or platform compatibility is implied. Runtime behaviour has not been verified across AI providers. Reuse terms have not yet been published. Background reading: Write the Test Before the Build. Building to a written test is part of Kramaniti’s Systems Engineering work.

How we write Kosh templates