By the end of this lesson you will be able to
- Recognise when a task is ready to be standardised
- Write down a process in a form your team will actually follow
- Keep it working as models and inputs change underneath you
The most common shape of failed AI adoption: one person gets a genuinely great result, shows everyone, everyone is impressed, and nothing changes. Six months later the tool is still paid for and still barely used.
Why it stalls
Because the good result lived in one person's head, in one conversation, on one afternoon. Nobody else can reproduce it, and after a week neither can they. What was demonstrated was a capability, not a process.
A demonstration
- One person, one time
- The prompt is gone
- Quality depends on who is driving
- Nobody knows when to use it
- Impresses, then evaporates
A process
- Anyone on the team, repeatably
- The prompt is written down and findable
- Output quality is roughly consistent
- A clear trigger for when it applies
- Shows up in how work gets done
When a task is worth standardising
Not everything should become a process. Standardising has a real cost — writing it down, teaching it, maintaining it — and most tasks do not clear that bar.
Standardise when all three are true:
- It happens at least weekly. Below that, the process gets forgotten between uses and re-learned each time anyway.
- More than one person does it, or will. A process for an audience of one is just a saved prompt, which is fine and much cheaper.
- You have done it well manually at least five times. You cannot write down a process you have not yet figured out.
What to write down
A usable process is about half a page. Longer than that and nobody reads it.
The trigger
When does this apply? "Every time a quote is accepted." "Every Friday afternoon." Without a trigger, a process is just a document nobody opens.
The prompt, verbatim
Copy-pasteable, with the variable parts marked clearly. Not a description of what to ask — the actual text. This is the part people skip and the part that matters most.
The inputs
What must be pasted in alongside it. "The signed quote and the customer's last two emails." Most bad output comes from missing inputs, not bad prompts.
The check
Specifically what to verify before it goes out. "Confirm the total matches the quote." Named checks get done; "review for accuracy" does not.
The escape hatch
When to stop and do it manually. Weird cases, angry customers, anything legal. Naming these up front prevents someone forcing a bad fit through the process.
QUOTE FOLLOW-UP
Trigger: 3 business days after a quote is sent with no reply.
Inputs: the quote PDF, the original enquiry email.
Prompt:
We sent the attached quote 3 days ago with no response.
Draft a short, friendly follow-up from [NAME].
Format: email, 3 sentences, no bullet points.
Constraints: do not discount, do not apologise for following
up, do reference one specific detail from their enquiry.
Check before sending:
- The specific detail referenced is actually from their email
- The quote total is not restated (we don't repeat numbers)
- Name and company spelled correctly
Do it manually instead if:
- The customer has already complained about anything
- The quote is over $10,000Keeping it working
A process is not finished when it is written. The models change, your business changes, and a process that worked in March can quietly stop working in September without anything visibly breaking.
- Give every process an owner by name. Unowned processes rot.
- Keep three example inputs with their known-good outputs. Re-run them monthly — this is the cheapest possible drift detection.
- Re-check properly after any model update or prompt edit, as if it were new.
- Review whether it is still worth doing every quarter. Some processes should be deleted, and deleting them is a win.
Where should we keep these?
Wherever your team already looks — the same place as your other procedures. A brilliant process in a tool nobody opens is worth less than a mediocre one in the shared drive people actually use.
Should we use custom GPTs or saved prompts?
Whatever your team will actually reach for. A packaged assistant is nicer when it fits; a pinned document with copy-pasteable prompts works everywhere and never depends on one vendor. Start with the document.
How do we get people to actually use it?
Make it faster than not using it, and have the person who is already doing it well teach it rather than mandating it from above. Adoption follows visible time saved, not policy.
Key takeaways
- A demonstration is not a process. The gap between them is where most AI value is lost.
- Standardise only what is weekly, shared, and already done well manually five times.
- Write the trigger, the verbatim prompt, the inputs, the specific check, and the escape hatch.
- Name an owner and keep three known-good examples to catch silent drift.