Prompt Engineering for Business Automation Workflows

Why Automation Prompts Are Different from Chat Prompts

When you type a prompt into ChatGPT, you get a conversational response. You can read it, judge whether it is useful, and ask a follow-up if the answer is off. None of that works inside an automation workflow. The prompt runs unattended, the output feeds directly into the next module, and nobody reviews it until something breaks downstream.

This changes everything about how you write prompts. A chat prompt can be vague because you are there to course-correct. An automation prompt must be precise because the system has no ability to ask clarifying questions. A chat prompt benefits from long, detailed responses. An automation prompt needs the shortest possible output in a format the next module can parse: a single word, a JSON object, a number between 1 and 10.

The shift from the shift from one-off prompting to building structured AI workflow systems is where most teams struggle. They copy their ChatGPT prompts into an n8n HTTP module or Make scenario and wonder why the outputs are inconsistent, too verbose, or wrapped in markdown formatting that breaks the JSON parser downstream.

Automation prompts need four properties that chat prompts do not. First, deterministic output format: the response must follow an exact structure every time. Second, brevity: every unnecessary token costs money when you are processing thousands of items per month. Third, graceful failure: when the input is garbage, the prompt should produce a fallback value rather than a long explanation of why it cannot help. Fourth, consistency: the same type of input should produce the same type of output across 10,000 executions, not just 10.

The rest of this post covers five prompt patterns that meet these requirements, with tested templates you can drop into your workflows today.

Classification Prompts That Produce Consistent Outputs

• Classification is the most common automation prompt type: sorting emails, categorising support tickets, labelling leads, or routing documents.
• A reliable classification prompt constrains the model to a fixed set of categories and rejects everything else.
• The difference between 85% and 98% accuracy on classification tasks comes down to prompt structure, not model size.

The template below works for any classification task where you need the LLM to assign one label from a predefined list. This example classifies support tickets, but the pattern applies to email sorting, lead categorisation, document routing, and content tagging.

{
  "model": "gpt-4.1-mini",
  "temperature": 0,
  "max_tokens": 20,
  "messages": [
    {
      "role": "system",
      "content": "You are a classifier. Respond with exactly one word from this list: billing, technical, sales, other. No explanation. No punctuation. Lowercase only. If uncertain, respond with other."
    },
    {
      "role": "user",
      "content": "Classify this support ticket:\n\n{{ticket_text}}"
    }
  ]
}

Three design choices make this prompt reliable. Setting temperature to 0 eliminates randomness, so identical inputs produce identical outputs. Setting max_tokens to 20 prevents the model from generating explanations even if the prompt fails to suppress them. The fallback instruction (“if uncertain, respond with other”) gives the model an escape route that your workflow can handle, rather than producing an unexpected category that breaks your router logic.

This is the same pattern used when building AI workflows in Make using HTTP modules and router logic. The classification output feeds directly into a Router module with one path per category.

For multi-label classification (where an item could belong to more than one category), change the instruction to: “Respond with one or more words from this list, separated by commas. Order from most relevant to least relevant.” Then parse the comma-separated output in your workflow.

Test accuracy by running 100 manually labelled samples through the prompt and comparing the AI output to your human labels. For support ticket classification, GPT-4.1 Mini consistently scores 92% to 96% accuracy with this template. Claude Haiku performs similarly. Full-size models like GPT-4o offer marginal accuracy improvements at 10 to 15 times the cost per call, which rarely justifies the expense for classification.

Extraction Prompts for Pulling Structured Data from Unstructured Text

Extraction prompts pull specific fields from messy, unstructured text: names from emails, amounts from invoices, dates from contracts, or product details from customer messages. The challenge is that the source text is never formatted consistently. One customer writes “my order number is 12345” and another writes “ref: ORD-12345-UK attached.”

The most reliable approach is to instruct the model to return a JSON object with predefined keys, and to use null for any field it cannot find. This gives your workflow a consistent structure to parse regardless of what the model extracts or fails to extract.

{
  "model": "gpt-4.1-mini",
  "temperature": 0,
  "max_tokens": 200,
  "messages": [
    {
      "role": "system",
      "content": "Extract the following fields from the text. Return a JSON object with these exact keys: customer_name, order_number, issue_type, urgency. Use null for any field not found. Do not include any text outside the JSON object. Do not wrap in markdown code fences."
    },
    {
      "role": "user",
      "content": "{{raw_email_text}}"
    }
  ]
}

The instruction “do not wrap in markdown code fences” solves one of the most common automation failures. By default, many LLMs wrap JSON output in triple backtick code blocks. This is helpful in a chat window but breaks JSON parsers in n8n and Make. Adding this single line to your system prompt eliminates hours of debugging.

For extraction tasks involving longer documents (contracts, reports, multi-page PDFs), add few-shot examples to the system prompt. A few-shot example shows the model one or two input-output pairs before it processes the real data:

Example input: "Hi, this is John from Acme Ltd. Our invoice INV-2024-089 for £3,450 seems incorrect."
Example output: {"customer_name": "John", "company": "Acme Ltd", "invoice_number": "INV-2024-089", "amount": "3450", "currency": "GBP"}

Few-shot examples increase accuracy on complex extraction tasks by 10% to 20% compared to zero-shot prompts, based on our testing across client projects. The trade-off is higher token costs because the examples are included in every API call. For high-volume workflows processing 1,000+ items daily, keep examples to a maximum of two to control costs.

Summarisation and Scoring Prompts for Workflow Decisions

• Summarisation prompts condense long text into a fixed format for downstream processing, not for human reading.
• Scoring prompts assign a numeric value to unstructured data, enabling automated routing based on thresholds.
• Both prompt types need strict output constraints to work inside automation logic.

Summarisation for automation is not the same as summarisation for a person. When a human reads a summary, they tolerate variation in length, structure, and emphasis. When a workflow consumes a summary, it needs a predictable format: a fixed number of bullet points, a single sentence, or a structured field.

This template produces a three-line summary of a meeting transcript for insertion into a CRM record:

Summarise this meeting transcript in exactly three lines.
Line 1: Key decision made (one sentence).
Line 2: Action items assigned (names and tasks, comma-separated).
Line 3: Next meeting date if mentioned, or "none scheduled".
Do not include any other text. Do not number the lines.

For scoring prompts, the pattern is similar but outputs a number. A lead scoring workflow in n8n that uses a scoring prompt to qualify inbound enquiries follows this structure:

Score this lead from 1 to 10 based on the following criteria:
- Company size matches our ICP (1-50 employees): +3 points
- Enquiry mentions a specific workflow or process: +3 points
- Located in the UK: +2 points
- Has a timeline mentioned (within 3 months): +2 points
Respond with only the total score as a single integer. No explanation.

The key design principle: make the scoring rubric explicit in the prompt rather than asking the model to judge quality abstractly. “Score this lead from 1 to 10” without criteria produces wildly inconsistent results. “Score this lead from 1 to 10 using these four weighted criteria” produces outputs that cluster tightly around the correct value.

For both summarisation and scoring, set temperature to 0 or 0.1. Higher temperature values introduce variation that you do not want in workflow outputs. If the same meeting transcript produces a score of 7 on Monday and 5 on Tuesday with identical inputs, your routing logic becomes unreliable.

How to Test and Iterate Prompts at Scale

You cannot test automation prompts by running them three times and checking the output. A prompt that works on 10 test cases can fail on the 11th because of an input format the model has not seen. Production-grade prompt testing requires a structured approach.

Build a test set of 50 to 100 real inputs with known correct outputs. For classification, this means 50 to 100 support tickets that a human has already labelled. For extraction, this means 50 to 100 emails where the correct field values have been manually recorded. For scoring, this means 50 to 100 leads where a sales team member has assigned the correct score.

Run your prompt against the full test set and measure three metrics. Accuracy: what percentage of outputs match the expected result. Consistency: does the same input produce the same output on repeated runs. Failure rate: what percentage of outputs are malformed (broken JSON, unexpected values, empty responses).

Target benchmarks for production prompts: 93% or higher accuracy for classification, 90% or higher for extraction (measured per field), and a failure rate below 2%. If your prompt falls below these thresholds, iterate on the prompt before scaling up. Common fixes include adding explicit format instructions, lowering temperature, adding few-shot examples, or tightening the system prompt constraints.

For teams running workflow automation builds where prompt reliability is tested before go-live, this testing phase is built into the delivery process. For teams building their own workflows, allocate at least 2 to 3 hours per prompt for testing and iteration before connecting it to live data.

A practical iteration loop: run the test set, identify the 5 to 10 inputs that produce wrong outputs, analyse what those inputs have in common (unusual formatting, ambiguous language, missing fields), adjust the prompt to handle those patterns, and re-run the full test set. Two to three iterations usually get a prompt from 80% to 95% accuracy.

Model Selection and Cost per Prompt Type

Not every prompt needs the same model. Classification prompts that output a single word work well on the smallest, cheapest models. Complex extraction from legal documents may require a larger model with stronger reasoning. Matching the right model to each prompt type is the single largest cost lever in AI automation.

The cost difference between models is significant at scale. Processing 10,000 support ticket classifications per month costs roughly $0.20 with GPT-4.1 Nano versus $1.40 with Claude Haiku versus $25.00 with GPT-4o. For a task where the cheapest model achieves 94% accuracy and the most expensive achieves 96%, the 2% improvement rarely justifies a 100x cost increase.

For a deeper analysis of choosing the right AI model for different types of development work, including benchmarks beyond automation tasks, we published a full comparison. The short version for prompt engineering: start with the cheapest model, test accuracy on your data, and only upgrade if the results are measurably below your threshold.

One pattern that works well for cost optimisation: use a comparison of Make, Zapier, and n8n for running prompt-heavy AI workflows to pick the right platform, then route easy inputs to cheap models and hard inputs to expensive ones. A classifier on the first LLM call assesses input complexity. Simple inputs go to GPT-4.1 Nano. Ambiguous inputs escalate to GPT-4.1 Mini. This cascading pattern can reduce total API costs by 40% to 60% compared to routing everything through a single model.