A prompt that worked beautifully on the example you wrote it for has passed exactly one test, and you designed that test to pass. Prompt testing is the boring step between “this looks great” and “the whole team uses it on Monday”: you run the prompt against a small set of realistic inputs, including the awkward ones, score what comes back, and keep a record so the next edit can be checked against the same set. An hour or two of this saves the much longer afternoon when someone discovers the prompt has been promising clients things nobody agreed to.
This guide covers evaluation only. If you still need to write the prompt itself, start with the beginner’s guide to prompt engineering for small businesses and the do and don’t rules for instruction prompts, then come back with something to break.
What you are actually checking
You are checking observable output against a standard you wrote down before you looked. That second part matters more than it sounds. If you decide what “good” means after reading the answer, every answer will look fine, because you will grade it on whatever it happened to do well. Anthropic’s guide to defining success criteria and building evaluations makes the same point for developers: criteria should be specific and measurable, and tests should mirror the real distribution of work, edge cases included.
You are not checking how the model “thought”. Asking it to explain its reasoning gives you more text to read, and that text is just more output to check. Judge what it produced: the facts it stated, what it left out, whether it followed the rules, and how much a person had to fix before sending it.
The illustrative prompt we will test
To keep this concrete, the examples below use an illustrative business, Saltmarsh Joinery, a fictional two-person workshop making bespoke furniture. The prompt drafts first replies to website enquiries. It receives the enquiry plus a short fact sheet (lead times, price ranges, timber options, what the workshop does not do) and produces an email draft that a person reviews before sending. Every case, score and log entry below is sample data written for this article, not a record of real runs.
Pick a prompt of your own that will be used repeatedly by more than one person. A one-off prompt for your own brainstorm does not need this treatment. A prompt that will sit in the team prompt library and get used forty times a month does.
Build five test cases before you change anything
Five cases is a starting set, not a scientific sample. Each should test a different way the prompt can go wrong, using realistic input your team will actually see. Pull them from real enquiries where you can (with names and contact details removed), and write the expected behaviour in plain language before running anything.
| # | Type | Input (illustrative) | Expected behaviour |
|---|---|---|---|
| 1 | Normal | Oak dining table for eight, budget around £3,000, needed by spring. | Confirms oak is offered, gives the fact-sheet price range and lead time, proposes a call. |
| 2 | Missing information | “How much for a bookshelf?” | No price guess. Asks for size, timber and finish, and shares the range for a typical piece. |
| 3 | Conflicting requirements | Solid walnut wardrobe, under £400, delivered next week. | Names the conflict politely and offers realistic options. Promises nothing outside the fact sheet. |
| 4 | Ambiguous request | “Can you do something like the one on your Instagram but bigger?” | Asks which piece and what “bigger” means. Does not pick a product and quote it. |
| 5 | Sensitive or unsupported claim | “Is your timber certified, and will the counter be fire-rated for my café?” | States only what the fact sheet says. Flags fire rating as something a person must confirm. |
Case 5 is the one most teams skip, and it is the one that causes real trouble. Models are agreeable by default. Ask a polite question that assumes a certification exists and you may well get a polite answer confirming it. Anthropic’s page on reducing hallucinations recommends restricting answers to supplied material and letting the model say it does not know, which is exactly what this case checks.
OpenAI’s evaluation best practices describe the same mix for larger systems: typical cases, edge cases and adversarial cases. You do not need their tooling to borrow the idea.
A scoring rubric someone else could apply
Score each output from 0 to 2 on five criteria. Keep the scale small. A ten-point scale invites long debates about whether something is a 6 or a 7, and nobody on a small team has time for that.
| Criterion | 2 | 1 | 0 |
|---|---|---|---|
| Correctness | Every fact matches the fact sheet | Vague but not wrong | States something false or unsupported |
| Completeness | Answers the question and asks for what is missing | Misses one needed element | Ignores the main request |
| Tone | Sounds like the business | Generic but acceptable | Wrong register, pushy or stiff |
| Instruction adherence | Format, length and rules followed | One minor rule missed | Breaks a hard rule |
| Review effort | Send after a quick read | Light edits | Faster to rewrite |
Add one override: a 0 on correctness fails the case, whatever the total. A charming email that invents a fire rating is still a fail. If tone is your main worry, score it against written voice rules, or the voice work in AI prompts for brand voice and identity, not whoever is in the mood to judge.
Have two people score the same outputs once. If they disagree by more than a point on several criteria, the rubric wording is too loose. Tighten the wording until they agree.
Run it more than once, and keep the inputs still
The same prompt and the same input can produce different outputs. OpenAI’s API documentation states that responses are non-deterministic by default, and Anthropic’s Messages API reference notes that even at a temperature of 0 results are not fully deterministic. So one run per case tells you what can happen, not what usually happens.
A practical rhythm for a small team: run each case three times and record the lowest score as well as the typical one. If case 5 passes twice and invents a certification once, the prompt fails case 5. For a prompt used forty times a month, a one-in-three failure means more than a dozen bad drafts reaching a reviewer.
When you compare two versions of a prompt, change one thing at a time and keep everything else fixed: the same five inputs, the same fact sheet, the same tool and model, the same person scoring. If you edit the prompt and swap the test inputs in the same round, you will not know which change moved the score. Save the exact input text; “roughly the same enquiry” is a different test.
Model changes are prompt changes you did not make
Chat tools change their default models on their own schedule. ChatGPT moved to a new default model in October 2026, which we covered in the Claude vs ChatGPT for business comparison. Your prompt text stayed identical, but the system answering it did not. Treat a model change exactly like a prompt edit: rerun the full set and compare against the last recorded scores. This is regression checking, and for a small team it means one rule. Nothing that passed last time is allowed to fail quietly this time.
If the prompt runs through the API inside an automation, record the exact model name used in each test round. Inside a chat app you often cannot pin a version, so record the date and the model shown in the interface, and rerun when it changes.
The version log
The log feels like admin, and it is the only thing that tells you, three months later, why the prompt says what it says. One row per tested version is enough.
| Version | Date | Change | Model / tool | Results (5 cases, 3 runs) | Decision |
|---|---|---|---|---|---|
| v1.0 | 14 Oct 2026 | First draft | Chat app, default model | 3 pass; case 3 and 5 fail | Revise |
| v1.1 | 16 Oct 2026 | Fact-sheet-only rule; conflict handling | Same | 5 pass; case 4 tone scores 1 | Approve for team |
| v1.1 | 28 Oct 2026 | No prompt change; model updated | Chat app, new default | 5 pass | Keep |
Illustrative log for the fictional Saltmarsh Joinery. Dates and results are sample data.
Add an owner name next to the log. A prompt with no owner gets edited by whoever is annoyed with it that week, and the log stops matching reality within a month.
One example revision
In the illustrative v1.0 run, two cases failed. Case 3 produced a cheerful reply suggesting walnut “could be possible within your budget if we keep the design simple”, which the fact sheet does not support. Case 5 said “all our timber is responsibly sourced”, a claim nobody had given the model. Both are the same underlying problem: the prompt told the model to be helpful and never told it where helpfulness stops.
The v1.0 instruction read:
Write a friendly first reply to this furniture enquiry. Answer their questions and encourage them to book a call.The v1.1 revision added two rules and kept everything else the same:
Write a friendly first reply to this furniture enquiry. Answer their questions and encourage them to book a call.
Only state prices, lead times, materials, certifications or standards that appear in the FACT SHEET. If the customer asks about something the fact sheet does not cover, say that Saltmarsh will confirm it personally, and do not guess.
If the request contains requirements that cannot all be met under the fact sheet (budget, material, timing), name the conflict plainly and offer up to two realistic options.On the rerun, all five cases passed in every run. Case 4 still scored 1 on tone because the clarifying question sounded like a form, and that went into the log as a known issue rather than triggering another edit. Not every imperfection deserves a new version. Fixing tone in case 4 could easily break something in case 1, and then you are back to running the set again, which is the point of having the set.
When a prompt is ready for the team
Our rule of thumb: every case passes on every run, no 0 on correctness anywhere, and average review effort at 1 or better. Then write the approved version, its date, its owner and its test set location into wherever the team keeps prompts. When someone reports a bad output in real use, turn that input into case 6. The test set should grow from real failures, which is also what OpenAI’s guidance recommends when it suggests growing the eval set over time.
You will not reach a prompt that never misbehaves. You will reach one whose failures you know about, can describe to a colleague, and can check again after the next model update. That is a perfectly respectable standard for a business tool.
Direktorium keeps publishing practical guides like this for small teams building AI into everyday work. If you would rather have someone design and test your team’s prompt set for you, BBDirector can help.