Batch instructions are the single prompt you write once — and apply to every row in your dataset. Get them right and the output is clean, consistent, and import-ready. Get them wrong and you'll spend hours fixing what should have worked automatically.
This guide covers what good batch instructions look like, the most common mistakes, and how to iterate quickly when the output isn't quite what you expected.
What batch instructions actually do
When you run a batch job, PromptMax sends each row of your CSV to the AI model as a separate request. Your batch instructions are the system prompt — the context and rules the model applies to every row, before it even sees the row data.
Think of it as briefing a very capable assistant: you tell them what the job is, what the output should look like, what rules to follow, and what to avoid. Then they apply that brief to every item in the pile without you having to repeat yourself.
The data in each row fills in the specifics. The batch instructions set the framework.
The anatomy of good batch instructions
Strong batch instructions have four components:
- Role definition — who the model is acting as
- Task description — what it needs to do for each row
- Output format — exactly what the response should look like
- Rules — constraints, tone guidance, what to avoid
None of these need to be long. A well-written set of batch instructions is usually 100–200 words. The goal is precision, not length.
Be specific about output format
This is the most important thing to get right. If you don't specify an exact output format, the model will make one up — and it'll be inconsistent across rows.
Write a product description for this item.
Write a product description for this item.
Output exactly this format — no extra text:
DESCRIPTION: [product description]
The "no extra text" instruction matters. Without it, the model will often add helpful preamble ("Sure! Here's a description for your product:") or sign-off text that you'll have to strip from the output. Telling it to output only the specified format eliminates this.
Reference your column names directly
Your batch instructions can — and should — reference the column headers from your CSV. The model sees both the instructions and the row data, so if your CSV has a column called key_usp, you can write "include the key_usp in the first sentence" and the model will pull in the value from that column for each row.
Include the product's main benefit in the description.
Lead with the key_benefit from the row data. If key_benefit is empty, derive the main benefit from the product_name and category.
The second version is more precise and handles the edge case where a column is empty — which will happen in real datasets.
Include an example in the instructions
One concrete example is often worth more than two paragraphs of description. If you want a specific format or tone, show it:
Example instruction with sample output:
Write a title tag for this web page. Output exactly this format:
TITLE: [title tag]
Example output for a category page selling women's trainers:
TITLE: Women's Trainers — 500+ Styles | Free UK Delivery | BrandName
Follow the same structure: keyword first, USP in middle, brand name at end after pipe. Max 60 characters total.
Seeing one example of good output makes the instruction unambiguous. The model won't have to interpret "keyword first, then USP" — it can see exactly what you mean.
Hard limits need explicit instruction
For character limits, word counts, and other hard constraints, state them as hard limits — not guidelines:
Keep the title tag under 60 characters.
Title tag must be 50–60 characters. This is a hard limit — count carefully before outputting.
"Keep it under" is treated as a preference. "This is a hard limit — count carefully" is treated as a constraint. The second version produces far fewer violations.
Handle edge cases explicitly
Real datasets have gaps. Column values will be blank, unusually short, or off-format. If you don't tell the model what to do in those cases, it'll make something up — and it'll be inconsistent.
For every important input column, add an edge case rule:
- "If key_attributes is empty, use the product_name and category to infer the main selling point."
- "If the response_text is under 10 words and cannot be classified, set PRIMARY_THEME to OTHER."
- "If keyword_theme contains a brand name, do not use it in the headline — use the generic category instead."
Test on 20 rows before scaling
This is the most important practical step. Before running 2,000 rows, run 20. Pick a representative sample — include some rows with sparse data, some with edge-case values, and some from different categories or page types.
Check the output against these questions:
- Is the format exactly right on every row?
- Are character or word count limits being respected?
- Does the tone match what you specified?
- Are column values being used correctly?
- Are edge cases handled as you intended?
If anything is off, fix the batch instructions and run the sample again. It's far easier to iterate at 20 rows than to review and re-run 2,000.
Common mistakes
Vague role definition. "You are an AI assistant" tells the model nothing useful. "You are a Google Ads copywriter" or "You are an SEO analyst" primes it for the right domain knowledge and vocabulary.
Forgetting the format instruction. The most common source of inconsistent output. If you don't specify an exact format, you'll get a different format on every row.
No edge case handling. "If X is empty, do Y" instructions prevent the model from hallucinating values when data is missing.
Too many rules. Instructions longer than 300 words start to produce diminishing returns — and sometimes conflicting outputs when rules interact unexpectedly. Keep your rules list focused on what actually matters for your output quality.
Skipping the test batch. The single most expensive mistake. 10 minutes on 20 rows will catch 90% of output quality issues before they affect your full dataset.