Prompt engineering for business: how do you write prompts? that work the hundredth time, not just the first
A prompt typed into a chat and a prompt that has to work for the hundredth time inside a process are two different objects. The first one you fix as you go. The second one has to survive data its author never saw. Below: the five parts of a production prompt, the output format, the test set and how to version it.
- 5 partswhat a production prompt is made of: role, task, input data, output format and a rule for missing data
- 10 to 20hard test cases we assume per prompt in our implementations before it goes anywhere near production
- EUR 0.005 to 0.07the cost of one query to the model, paid to the provider directly; a longer prompt costs more every single run
- 30 and 90 dayswhen we check after go-live whether the prompt still returns the same result on new data
Short answer
How do you write prompts for AI that hold up in a company?
First decide whether you are writing a one-off prompt or a prompt for a process. A one-off can be a single sentence, because you are looking at the result. A prompt that runs unattended needs five parts: role, task, input data, output format and a rule for missing data. Without that last one the model guesses.
Describe the output format as precisely as you would describe it to a developer: which fields, in what order, what may be left empty. An answer nobody can process without a person cancels the point of the automation. Then test the prompt on 10 to 20 hard cases, not on one pretty one.
Finally the prompt lands in one place, with a version number and a named owner. Changing one sentence changes the result of every run. That is the difference between one person's trick and a skill the team owns.
What is the difference between a one-off prompt and a prompt in a process?
We all learn prompting in a chat window: you write, you look, you fix. That works as long as a person reads the output. In a process the fixing loop disappears and what is left is a machine that follows the instruction literally, on records nobody looked at.
That shift in responsibility matters more than any writing technique. A prompt inside a process is a piece of the system, like a rule in your CRM or a step in n8n. Where a language model earns its place at all, we covered in the guide on LLMs in business.
| Dimension | One-off prompt | Prompt inside a process |
|---|---|---|
| Who reads the output | a person, straight away | the next automated step, unattended |
| Input data | one input, pasted by hand | hundreds of records, some of them incomplete |
| What happens on an error | you rephrase and ask again | the error travels further into the process |
| Output format | anything readable will do | fixed, or the next step stops |
| Cost of a mistake | a minute of your time | every record that went through before somebody noticed |
| Who owns the wording | the author, in that one conversation | the team, because the prompt lives in the process |
Not every prompt has to be production grade. The rules below apply to the ones that run without a person in the loop.
What goes into a good prompt?
Five parts, always in the same order. When everyone on the team writes them the same way, somebody else's prompt can be read in half a minute and fixed without calling the author.
Part five, the rule for missing data, is the one most often skipped and the one that hurts most. Ask a model for a VAT number from a document that does not contain one and it will hand you something shaped like a VAT number. Why that happens is in the guide on how to avoid AI hallucinations.
- Role: who the model is, in one sentence („You are an accountant reviewing supplier invoices”)
- Task: one action, stated as a verb („List every line with a VAT rate other than the standard 23 percent”)
- Input data: separated from the instruction by a marker, so the model knows where it starts
- Output format: exact fields, their order, the type of each value and what must NOT appear
- Rule for missing data: („Write NO_DATA, do not infer it from the rest of the document”)
How do you force an output format the next step can read?
Design the format backwards: look at what the next step does and demand exactly what it needs. Writing to a spreadsheet? Fields named like the columns. Routing a ticket to a person? One word from a closed list, not a sentence.
Two technical points on top. Turn the model's randomness down to zero wherever repeatability matters. Keep the fixed rules in the system instruction and the variable data in the query itself. Then the data cannot overwrite the rules.
| What the next step does | Format you demand | What happens on missing data |
|---|---|---|
| Writes to a spreadsheet or database | JSON with a closed list of fields | empty field plus a NO_DATA status |
| Routes a ticket to a person | one word from the list given in the prompt | the word UNRECOGNISED and the ticket goes to a human |
| Sends a message to a customer | subject and body as two separate fields | empty body and a task queued for approval |
| Scores a sales enquiry | a number from 1 to 5 plus one sentence of reasoning | 0 and the reason it cannot be scored |
| Writes to the CRM | fields named exactly as in the CRM, nothing extra | field left out, never guessed |
A closed list of values beats an open field, because the answer can then be checked by machine. Anything outside the list goes to a person.
What do you test a prompt on before production?
Authors test their prompt on the case they invented, which is the case they had in their head while writing the instruction. Production data does not look like that. Build the test set out of real records and go looking for the ugly ones.
In our implementations we assume 10 to 20 cases per prompt and run the whole set after every change. It takes a few minutes and it catches regressions that are invisible on a single record.
- A record with an empty field the author never considered
- A document in two languages, or a scan instead of text
- Data from before a naming change, for example old CRM statuses
- Extreme values: an invoice for 12 cents and an invoice for several hundred thousand
- Text that itself looks like an instruction („ignore the previous instructions”)
- A case where the correct answer is „I do not know”
How do you get from a first draft to a production prompt?
The path is shorter than people expect, and every step you skip comes back a week later. Ours looks like the rest of our method: process first, tools second.
Draft on one case
Write the prompt out of the five parts and try it on one convenient record. The question here is whether the task is doable at all, not whether the prompt is finished.
The set of hard cases
Pull 10 to 20 records out of the system: empty fields, extreme values, data from before the migration. Write the correct answer next to each one. It takes about an hour and there is no way to speed it up.
Output format and the missing-data rule
Add the fields, the closed list of values and the rule for missing information. Run the whole set and count how many answers can be processed without a person.
Pilot with a person alongside
Run the prompt on real data, with somebody checking every output before it is saved, for a week. Every correction goes back into the test set.
Production and measurement
Drop the manual approval, keep the routing of exceptions to a person. After 30 and 90 days run the same set again: data changes faster than prompts do.
How do you version prompts and who owns them?
A prompt inside a process is system configuration, so the same rules apply: one place, a change history, an owner. The author's private chat is not that place, because once they are on holiday nobody knows where the output comes from.
Who should write the prompts is an organisational question. It usually works best with the person who knows the process, and the technique can be handed over in a day. That is what AI training for business is for: the team leaves with prompts of its own.
- One storage location: a repository, Notion or Confluence, never a private conversation
- A version number and a date on every change, exactly as with a change in code
- One sentence saying what changed and why, so it can be rolled back without an investigation
- The test set result before and after the change, in the same entry
- An owner by first and last name, not „the operations team”
Which data must never go into a prompt?
The prompt and its data leave the company and go to the model provider. That is ordinary processing on your behalf, so the question is not „will the model remember this”, it is „do we have a lawful basis and a processor agreement”. Article 28 of the GDPR is the part to read.
The rule for the team is simpler than any policy document: only the fragment needed for the task goes into the prompt. Not the whole export, not the whole database, not the whole mailbox.
- Personal data with no lawful basis and no processor agreement in place
- Passwords, API keys and access tokens, including the „temporary” ones pasted into a ticket
- Documents under NDA, partner price lists and commercial terms of your counterparties
- HR records, salaries and medical documentation
- Full database exports instead of the single record actually being processed
Common mistakes
Five mistakes that break prompts inside processes
A prompt written for one pretty case
The first record with an empty field turns the output over, and nobody sees it, because the answer still looks correct.
No rule for missing data
The model guesses instead of admitting it does not know. The guessed value enters the system and looks exactly like a real one.
Output format described in prose instead of fields
The next step gets a list one day and a paragraph the next. Somebody patches the automation and the process ends up costing more than the manual work did.
The prompt lives in the author's private chat
Once they are on holiday nobody knows which version is running in production or why the output changed on Wednesday.
Changing the prompt without running the test set
A fix for one case breaks three others. It surfaces a week later, on data that already went to a customer.
Checklist
Checklist before a prompt goes to production
If any line is a no, the prompt stays in the pilot.
- The prompt has five parts: role, task, input data, output format and a rule for missing data
- The output format is described in fields and a closed list of values, not in a sentence
- A set of 10 to 20 hard cases has been run in full
- There is a rule for who receives an exception and how quickly
- The prompt sits in one place, with a version number, a date and a named owner
- What data may be pasted is agreed and written down next to the prompt
- The 30-day and 90-day review dates are already in the calendar
Sources
Sources
- Anthropic developer documentation: system instructions, output format and model parameters
- OpenAI platform documentation: structured outputs, system instructions and sampling randomness
- Regulation 2016/679 (GDPR): lawful bases for processing and processor obligations under Article 28
- n8n documentation: how a language model step sits inside an automated process
Write them on your own processes
Prompts come out of the process, not out of a list of tricks
On a free 30-minute consultation we take one of your processes and check whether it needs a model at all or just an ordinary rule. You write directly to Paweł. The process workshop costs EUR 3,500 net per week, runs for 1 to 7 weeks, and ends with a process map, your first prompts and a test set.
Book a free consultationFrequently asked questions
What is prompt engineering in a business context?
It is the skill of writing instructions for a language model so that they return the same processable result on data the author never saw. In practice it comes down to five parts in the prompt, a forced output format and a test on hard cases. It is a team skill, because the prompt outlives its author.
How many test cases are enough to check a prompt?
In our implementations we assume 10 to 20 records per prompt: empty fields, extreme values and data from before a system migration. You run the whole set after every change, not only before the first launch. Every correction that comes out of the pilot adds a new case to the set.
How do you make the model return the same format every time?
Describe the fields as precisely as you would describe them to a developer, give a closed list of allowed values and say what must not appear in the answer. Turn the model's randomness down to zero wherever repeatability matters. Reject anything outside the list automatically instead of reading it.
Where should prompts be stored and how do you version them?
In one place the team can reach: a repository, Notion or Confluence. Every change gets a version number, a date, one sentence on the reason and the test set result before and after. A named owner, because otherwise two months later nobody knows what is running in production.
Does changing one sentence really change the result across a whole process?
Yes, and that is the main reason for versioning. The prompt behaves identically on every run, so a fix aimed at one case changes the behaviour of all the others. That is why the full test set goes through after a change, not only the record that caused the problem.
Which data must not be pasted into a model?
Personal data with no lawful basis and no processor agreement, passwords and API keys, documents under NDA, HR and medical records, and full database exports. The practical rule: only the fragment needed for the task goes into the prompt, never the whole file it happens to sit in.
How much does it cost to run a prompt inside a process?
The query itself costs EUR 0.005 to 0.07 and you pay the model provider directly, so a longer prompt costs more on every run. The implementation is quoted after the workshop, which costs EUR 3,500 net per week. What decides the economics is the number of runs, not the price of one query.