SOP-EMAIL-01: Email Architecture¶

Version: 1.1 Status: Production Ready
Created: January 2026
Owner: Protocol Raw Operations
Related: SOP-LC-01, SOP-CS-00, Email Design System v1.1

1. Overview¶

Purpose¶

This SOP defines the email address structure for Protocol Raw. It establishes clear ownership boundaries, routing logic, and sender configuration for all customer communications.

Design Principles¶

No noreply@ â€” We don't signal "don't talk to us." Copy discourages unnecessary replies; the address doesn't.
Separation of intent â€” Pre-sale inquiries route differently from customer support obligations.
Scale-ready ownership â€” Clear boundaries for future team handoffs (Marketing owns hello@, Ops owns support@).
Premium brand alignment â€” Every touchpoint reinforces calm, competent, accessible positioning.

2. Email Addresses¶

Customer-Facing¶

Address	Purpose	Owner	Notes
`hello@protocolraw.co.uk`	Pre-sale inquiries, website contact form, lifecycle emails	Marketing	General brand touchpoint
`support@protocolraw.co.uk`	All post-purchase customer communication	Operations	Primary customer identity

Internal Only¶

Address	Purpose	Owner	Notes
`ops@protocolraw.co.uk`	Internal alerts, monitoring notifications	Operations	Never customer-visible

Optional Alias¶

Address	Routes To	Purpose
`orders@protocolraw.co.uk`	`support@`	Catches customers who instinctively try this address

3. Routing Logic¶

Inbound Flow¶

Inbound email
    â”‚
    â”œâ”€â”€ hello@protocolraw.co.uk
    â”‚       â”‚
    â”‚       â””â”€â”€ Gmail â†’ Make.com â†’ Support ticket (tag: presale)
    â”‚
    â””â”€â”€ support@protocolraw.co.uk
            â”‚
            â””â”€â”€ Gmail â†’ Make.com â†’ Support ticket (tag: customer)

Tagging Rules¶

Inbound Address	Ticket Tag	Priority
`hello@`	`presale`	Normal
`support@`	`customer`	High
Reply to transactional email	`customer` + auto-attach order context	High

4. Customer.io Sender Configuration¶

By Email Category¶

Category	From Address	Reply-To	Examples
Transactional	`Protocol Raw <support@protocolraw.co.uk>`	`support@protocolraw.co.uk`	Order confirmation, dispatch, billing
Lifecycle	`Protocol Raw <hello@protocolraw.co.uk>`	`hello@protocolraw.co.uk`	Welcome sequence, check-ins, win-back
Persona/Support	`{Persona} <support@protocolraw.co.uk>`	`support@protocolraw.co.uk`	Sophie/Tom/Lucy replies

Persona Sender Format¶

Sophie <support@protocolraw.co.uk>
Tom <support@protocolraw.co.uk>
Lucy <support@protocolraw.co.uk>

Persona assignment is deterministic per customer (hash of customer ID). See SOP-LC-01 for implementation.

5. Discouraging Unnecessary Replies¶

Method¶

Copy does the work, not the address. Transactional emails include a single line in the footer:

Questions about your order? Email support@protocolraw.co.uk

Why This Works¶

Signals accessibility (we're reachable)
Redirects to the right channel (support@, not reply)
Maintains brand voice (calm, not defensive)
Catches replies anyway (Reply-To points to support@)

6. Implementation Checklist¶

Google Workspace Setup¶

[ ] Create support@protocolraw.co.uk mailbox (or alias to existing)
[ ] Create ops@protocolraw.co.uk alias (routes to founder inbox initially)
[ ] Create orders@protocolraw.co.uk alias â†’ support@
[ ] Verify SPF/DKIM/DMARC for all addresses

Customer.io Configuration¶

[ ] Update transactional email sender to Protocol Raw <support@protocolraw.co.uk>
[ ] Update lifecycle email sender to Protocol Raw <hello@protocolraw.co.uk>
[ ] Update persona emails to {Persona} <support@protocolraw.co.uk>
[ ] Set Reply-To headers per category (see Section 4)

Make.com Updates¶

[ ] Add support@ as monitored inbox (alongside hello@)
[ ] Update ticket creation to tag by inbound address
[ ] Test reply-to-transactional routing

Email Templates¶

[ ] Add footer line to all transactional emails: "Questions about your order? Email support@protocolraw.co.uk"

6a. Waitlist Segment & Launch Campaign¶

Waitlist Segment¶

Pre-launch signups are synced to Customer.io via the waitlist-signup Edge Function. Each signup creates a Customer.io profile with:

Attribute	Value	Purpose
`waitlist`	`true`	Segment membership flag
`waitlist_source`	`calculator` / `homepage` / `journal`	Acquisition touchpoint
`dog_name`	string (if captured)	Personalisation
`box_size`	string (if captured)	Plan context
`daily_grams`	number (if captured)	Plan context
`weekly_price`	number (if captured)	Plan context

Segment definition: All profiles where waitlist = true.

Event: waitlist_signup — fired on each signup, carries source and plan data.

Launch Campaign: `launch_announcement`¶

When Protocol Raw goes live, a broadcast campaign targets the waitlist segment with two variants:

Variant	Condition	Content
A: Full plan	`dog_name` exists	Personalised: "Hi! [Dog name]'s plan is ready. [Box size], [daily grams]g/day, £[price]/week. Start now →"
B: Generic	`dog_name` is null	General: "Protocol Raw is live. Calculate your dog's plan →"

Trigger: Manual broadcast to waitlist segment on launch day. From: Protocol Raw <hello@protocolraw.co.uk>

7. Future Considerations¶

When Ops Lead Joins (Month 7+)¶

support@ becomes their primary inbox
hello@ remains with Marketing/Growth
ops@ expands to team distribution

European Expansion¶

Consider regional addresses if needed: - support@protocolraw.de - support@protocolraw.fr

Or maintain single support@protocolraw.co.uk with language detection routing.

Version History¶

Version	Date	Changes
1.0	2026-01-25	Initial specification
1.1	2026-03-12	Added waitlist segment and launch campaign specification (Section 6a)