Prompt engineering for ecommerce

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

These six sections are a useful starting point. Adapt them to the task rather than treating the structure as a universal rule:

1. Role. Who the agent is and who they're talking to.
2. Goal. What success looks like (closed cart, satisfied answer, handoff).
3. Context. The retrieved facts the model is allowed to cite.
4. Voice. Tone presets and brand-specific language rules.
5. Tools. Which structured tools the model may invoke (and which it must not).
6. 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. Use clear sections that a reviewer can check against actual behavior.

Voice + tone scaffolding

Voice is two layers: the preset (for example Professional or Friendly) 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

For questions that depend on store facts, retrieve relevant sources before drafting an answer. Select and test the number of passages for your catalog and context limit; an example source block is:

<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 can reduce unsupported answers, but instructions alone do not enforce truth or authorization.

Refusal patterns

The model needs explicit instructions for what to do when it doesn't have the facts. Three patterns to script:

1. Soft refusal: "I don't have the spec for that - let me check with the team and follow up by email."
2. Hard refusal: Banned claim categories. Always: "I can't speak to medical effects of any product - please consult a clinician."
3. 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.
• Keep product and action identifiers in protected logs for review. Show shoppers only the product or order reference they need, after identity and ownership checks.
• Strictly forbid the model from "explaining" the tool's logic to the shopper - it should report results, not narrate.

Keep enforcement outside the prompt: validate tool arguments, scope every read to the store and verified shopper, check permissions, and require confirmation before supported order changes. A message asking the model to ignore its rules must not bypass those checks.

Illustrative failure and fix. A draft says returns are allowed for 60 days, but the approved policy says 30. Correct or remove the stale source, wait for indexing, and rerun that question plus a conflicting-policy test. Record the source and observed answer; do not call it fixed only because the wording of the prompt changed.

Eval suites you should run

Before a prompt change goes live, run a stable set of representative questions. Use synthetic cases or consented, de-identified session data. Include ordinary questions, missing facts, conflicting policies and prompt-injection attempts. Score at least these areas:

• 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?

In Zubby, re-ask those questions in your storefront widget after each change to knowledge, rules, or brand voice. A spreadsheet of questions, expected behavior and observed answers can make regressions visible. Its coverage depends on the cases chosen; no fixed sample guarantees that most failures will be caught.