Prompt engineering for ecommerce is a different sport than prompt engineering for a general assistant. You're not optimizing for impressive answers — you're optimizing for safe, accurate, on-brand answers at scale, where one weird response can cost a sale or earn a refund request.
The shape of a great system prompt
Production system prompts share a common structure. Six sections, every time:
- Role. Who the agent is and who they're talking to.
- Goal. What success looks like (closed cart, satisfied answer, handoff).
- Context. The retrieved facts the model is allowed to cite.
- Voice. Tone presets and brand-specific language rules.
- Tools. Which structured tools the model may invoke (and which it must not).
- Refusal. What the model says when it doesn't have the facts.
If your prompt is a wall of "be helpful and polite", you're at step one. Production prompts are checklist documents, not vibes.
Voice + tone scaffolding
Voice is two layers: the preset (Professional / Warm / Playful / Minimal) and the brand specifics (banned phrases, signature openers, allowed slang). Most stores get the preset right and ignore the brand layer — which is where the agent sounds most generic.
Brand-specific examples that pay off:
- "Never say 'no worries' — say 'absolutely, happy to help' instead."
- "For sizing questions, always offer to look up the brand-specific size chart before recommending a default."
- "Use 'fit' not 'silhouette' (we sell streetwear, not couture)."
Grounding the model in your data
Every shopper turn should run through retrieval before the prompt is finalized. The prompt then injects the top 5-10 retrieved chunks as a labeled context block:
<context source="product:sku-1234">…</context>
The system prompt instructs the model: "Only cite information found inside <context> tags. If a fact is not present, say you don't know rather than guessing." This is the single highest-leverage anti-hallucination move available.
Refusal patterns
The model needs explicit instructions for what to do when it doesn't have the facts. Three patterns to script:
- Soft refusal: "I don't have the spec for that — let me check with the team and follow up by email."
- Hard refusal: Banned claim categories. Always: "I can't speak to medical effects of any product — please consult a clinician."
- Handoff: Confidence-gated. "Want me to connect you with a human stylist? They can answer this in detail."
The hard-refusal list is the most underused safety lever in ecommerce AI. Configure it before you tune voice.
Tool-call discipline
Structured tool calls — search_products, check_inventory, add_to_cart, get_order_status — are where AI ecommerce gets useful. They're also where vanilla prompts go off the rails (model invents a SKU, hallucinates stock, "adds" something that doesn't exist).
Patterns that work:
- Always require the tool to return a structured JSON result, not a free-text summary.
- Make the model cite the SKU or order ID it acted on in its reply, so a human auditor can verify.
- Strictly forbid the model from "explaining" the tool's logic to the shopper — it should report results, not narrate.
Eval suites you should run
Before any prompt change goes live, run it through a fixed eval suite of 50-200 shopper interactions you've collected from real sessions. Score on three axes:
- Accuracy — did it cite real product facts, or invent?
- Tone — did it sound like your brand?
- Resolution — did it close the loop, or kick the shopper down a dead-end?
Zubby ships an eval harness in the dashboard so you can replay your conversation log against any prompt variant before promoting it to production. If you're building this from scratch, even a Google Sheet of 50 prompts + expected behaviors is enough to catch most regressions.