In a demo, a prompt only needs to work once. In production, it has to work for thousands of different users, every day, without surprising anyone. That changes how you write prompts. The aim is not clever phrasing but a clear specification that a model can follow consistently, plus tests that tell you when it stops doing so.
Write the prompt like a spec
A reliable prompt usually has the same parts, in a clear order:
- Role and goal: who the model is acting as and what the task is. "You help our support team classify incoming WhatsApp messages."
- Context: the facts it needs, such as your business hours, product list or policy text.
- Rules: what to do and what never to do, in short numbered points.
- Output format: exactly what the answer must look like.
- Examples: two or three realistic inputs with the correct outputs.
Be specific about the output
If code reads the answer, ask for structured output. Request JSON with named fields, state the allowed values and use your provider's structured-output or tool-calling feature where available so the format is enforced. Then validate the result with a schema in your code and handle failures by retrying or falling back. Never assume the model returned what you asked for.
Show, do not only tell
Examples teach format and tone faster than long explanations. Include at least one example for the awkward cases: an empty message, a message in Hindi or Hinglish, two requests in one message and an input that does not fit any category. Keep examples varied so the model does not copy one of them too literally.
Handle "I do not know"
Models try to be helpful, and that includes making things up. Give them a safe exit: "If the answer is not in the context, reply with NOT_FOUND." Then route NOT_FOUND to a person. Ask for the source passage alongside the answer so you can check it, and keep the temperature low for tasks that need consistency.
Separate instructions from data
Put user text inside clear delimiters, such as tags, and tell the model that anything inside them is data, not instructions. This helps against prompt injection, though it does not remove the risk. Keep real permission checks in your code and never rely on the prompt to protect sensitive actions.
Keep prompts in version control
- Store prompts as files, not as strings buried in code, and review changes like any other change.
- Give each prompt a version and log which version produced each answer.
- Keep the model name pinned. A model update can change behavior even if your prompt did not change.
Test with a real set of cases
Collect 30 to 100 real inputs, with the output you consider correct for each. Run every prompt change against that set and compare scores before and after. Include the ugly cases from production as they appear. Without this, each edit fixes one problem and quietly creates another. Our guide on what to test and what to skip applies the same thinking to the interface side.
Control cost and speed
- Send only the context the task needs. Long prompts cost more and respond slower.
- Use a smaller, cheaper model for simple jobs such as classification, and a larger one for hard reasoning.
- Cache repeated prefixes and repeated answers where your provider supports it.
Common mistakes
- Stacking more and more rules until they contradict each other.
- Writing "do not" lists without saying what to do instead.
- Skipping evaluation because the demo looked fine.
- Putting private data in prompts without checking where it is stored.
A worked example from messaging
Take a message such as "bhai 20 pcs blue wala bhej do kal tak". A good prompt for our WhatsApp to Excel automation style of workflow states the target fields (customer, product, color, quantity, date), shows two examples including a Hinglish one and defines what to output when a field is missing. The result is a clean row in a sheet, or a question back to the customer. In business software such as Lena Dena, a similar prompt can turn a spoken or typed note into a draft invoice line for review, with local-language support so staff can write in the language they think in.
A reusable prompt template
Start from a skeleton and fill it in for each task: a one-line role, the task in one sentence, the facts the model may use, a numbered list of rules, the exact output schema, and two or three examples. Keep a changelog beside it that records what changed and why. When a result looks wrong, read the full prompt as the model sees it, including the retrieved context, before you blame the model. Most bad outputs trace back to missing, conflicting or outdated instructions.
If you are adding AI to a product and want it reliable from the first release, look at our services or talk to our team.