Email & transactional content QA

Business value

• Catches the templates where merge variables didn't fill in — the 'Hi {first_name}, your order is being processed' send that ships at 3am.
• Prevents the generic-reassurance failure mode in support replies, where an agent-drafted response says everything except what the customer actually asked.
• Quality-gates the high-volume lifecycle emails (welcome sequences, win-back) without a human reading every send.

Agent job to be done

Be a support QA reviewer with strong taste. Every email should state the exact event, the exact next step, and the exact support path. Vague reassurance is worse than no email.

format: otherintended_use: publishdomain: email / transactional content QA

When to call VeracityAPI

Before campaign send, automation activation, or transactional template deployment. Re-run after any template variable change.

What text to submit

Subject line, preview text, body, CTA, transactional variable names plus a representative rendering of those variables (use one real-looking sample customer's data — do not submit production PII).

Decision policy

• allow: low risk, no high-severity evidence, all merge variables resolve in the sample render.
• revise: medium risk, vague next steps, generic reassurance, or unsupported claims about timeline / outcome.
• human_review: refund, billing, account access, safety warning, compliance, or legal-adjacent emails. The blast radius is too high for autopublish.
• Local rule: every transactional email must answer three questions in order — what happened, what happens next, where to get help.

Automation recipe

• Email agent drafts the template using placeholder variables.
• Render with a representative customer record (synthetic data, not production).
• Score the rendered output. Unrendered variables trip 'placeholder_leak' evidence categories immediately.
• If revise, patch the vague spans and rescore.
• Only templates that pass enter the active lifecycle pool.

Evidence spans agents should inspect

• 'generic_reassurance' — 'we're working on it' / 'we'll get back to you soon' without specifics
• 'unclear_next_step' — email doesn't tell the customer what to do next
• 'placeholder_leak' — unrendered merge variables like {first_name} in the sample render
• 'unsupported_timeline' — 'within 24 hours' or 'shortly' without an SLA

Policy pseudocode

if (result.recommended_action === "allow") continueWorkflow();
if (result.recommended_action === "revise") rewriteWith(result.evidence, result.recommended_fixes);
if (result.recommended_action === "human_review") queueForHumanReview(result);
if (result.recommended_action === "reject") discardOrRebuild();

KPIs to track

• support replies generated per 1,000 lifecycle emails sent
• template revise rate before launch
• newsroom engagement (open, click, reply where relevant)
• refund/escalation rate following transactional sends
• median time to approve a new lifecycle template

What can go wrong

• Short transactional emails sometimes score low-confidence. Pair with a required-fields lint (every email must include the order ID, the support URL, etc.).
• Don't submit production tokens, real names, or PII to the API. Render with synthetic placeholders.
• Compliance and legal emails still need legal review regardless of the gate.

Cost and latency notes

Analyze only is $0.005 per 1,000 characters; Analyze + revise with auto_revise=true is $0.010 per 1,000 characters. Both round up to the nearest 1,000 characters. Short captions/emails usually cost $0.005; longer pages or chapters scale linearly by length. Current v0.1 latency is LLM-bound, so batch/concurrent orchestration is recommended for high-volume pipelines.