vault-sync: 2026-10-02 07:10 (jimmy)
This commit is contained in:
@@ -0,0 +1,196 @@
|
||||
# SOP — Phoenix name-change remediation: email follow-up
|
||||
|
||||
**Slug:** `phoenix-salon`
|
||||
**Version:** 1.0 · **Effective:** 2026-09-20
|
||||
**Owner:** CoS (Grok Bot) · **Gatekeeper:** Anthony
|
||||
**Sits with:** [remediation-review-loop.md](./remediation-review-loop.md) · [surface-checklist.md](./surface-checklist.md)
|
||||
**Mail desk:** VeriMail via `ashbotphoenix@agentmail.to` · CC `tonyjbala@gmail.com` on reply threads
|
||||
|
||||
Hand this to anyone running listing outreach. Do not improvise silence windows or nudge counts outside this doc unless Gatekeeper overrides in chat.
|
||||
|
||||
---
|
||||
|
||||
## 0. Preconditions (every send)
|
||||
|
||||
1. Item is on `surface-checklist.md` (or added there in the same batch).
|
||||
2. **Job Card** posted in Grok Bot chat → Anthony says **go**.
|
||||
3. Send only via VeriMail Method A (hermes `.venv` python).
|
||||
4. On-disk artifacts required before claiming SENT: `send-receipt.md` + `.eml` (or equivalent).
|
||||
5. Log the send in **§2 Send log** *and* a row in the review loop batch table.
|
||||
6. No cold send without a real public contact (mailto / published support address). Cloudflare / no-contact → mark **WONT-DO**, do not invent recipients.
|
||||
|
||||
---
|
||||
|
||||
## 1. How to pick the correct recipient
|
||||
|
||||
### 1.1 Audience tier first
|
||||
|
||||
| Tier | Who | Typical email target | Do **not** email |
|
||||
|------|-----|----------------------|------------------|
|
||||
| **1 — Customers** | People who find/book Phoenix | Rarely “customer email.” Prefer *fix the surface* (IG, site, GBP). Email only if a **directory customers use** lists a public correction address | Random reviewers; personal customer inboxes |
|
||||
| **2 — Vendors / partners** | Directories, aggregators, review platforms | Published listing-support / profiles / data-quality address on that site (or ticket system if email isn’t offered) | Scraped personal staff emails; form-only sites with no mailto (use ticket or WONT-DO) |
|
||||
| **3 — Back-office** | Us / Ashley ops | Internal notes, Job Cards, CC Anthony — not cold vendor mail | Using vendor inboxes for internal process chat |
|
||||
|
||||
### 1.2 Recipient decision tree
|
||||
|
||||
1. Open the remediation item (URL + what’s wrong vs canonical NAP).
|
||||
2. Assign tier **1 / 2 / 3** using the triage table in the review loop.
|
||||
3. Find contact in this order — stop at the first valid one:
|
||||
a. Official “update listing / report inaccuracy / profiles@ / support@” published on the **same domain**
|
||||
b. Platform ticket/help form (if no email — file ticket, log as **TICKET** not EMAIL)
|
||||
c. None → **WONT-DO** + reason (e.g. CF 403, JS-only form, no contact)
|
||||
4. Prefer one canonical address per platform (e.g. Birdeye → `profiles@birdeye.com`). Do not spray multiple guesses.
|
||||
5. From identity: always `ashbotphoenix@agentmail.to` (Phoenix listing desk).
|
||||
6. If the item is **human-owned** (IG bio, YP confirm Ashley already mailed) → no VeriMail cold send; mark OPEN for Ashley/Anthony.
|
||||
|
||||
### 1.3 Subject line pattern
|
||||
|
||||
`Phoenix Salon + Spa (Cameron Park) — [action]: [old name/listing] → canonical NAP`
|
||||
|
||||
Example: `Authorized listing partner for Phoenix Salon + Spa — remove/update outdated La Mae listing`
|
||||
|
||||
---
|
||||
|
||||
## 2. Send notation / log
|
||||
|
||||
Every outbound remediation email gets one row. Living file: same folder, table below (append; don’t delete history).
|
||||
|
||||
Also keep the job folder evidence: `.../gate3-pilot|mail/<date>-*/evidence/send-receipt.md`
|
||||
|
||||
### Send log
|
||||
|
||||
| Sent (PT) | Rem. item / surface | Tier | To | Subject | Job / evidence path | Silence clock starts |
|
||||
|-----------|---------------------|------|----|---------|---------------------|----------------------|
|
||||
| 2026-09-19 14:28 | Birdeye — La Mae / Flying C | 2 | profiles@birdeye.com | Authorized listing partner… outdated La Mae listing | gate3-pilot/2026-09-19-birdeye-send/evidence/ | 2026-09-19 |
|
||||
| | | | | | | |
|
||||
|
||||
**Minimum fields:** datetime PT · surface · tier · recipient · subject · evidence path · clock start date.
|
||||
|
||||
---
|
||||
|
||||
## 3. Silence window before a nudge
|
||||
|
||||
### 3.1 Defaults
|
||||
|
||||
| Tier | Default silence before **Nudge 1** | Notes |
|
||||
|------|--------------------------------------|-------|
|
||||
| **1 — Customer-facing directories** | **5 business days** | Faster if the bad listing is actively confusing bookers (Gatekeeper may shorten) |
|
||||
| **2 — Vendors / aggregators** | **7 calendar days** | Default for Birdeye-class profile mail |
|
||||
| **3 — Back-office** | N/A for vendor nudge | Use internal chase, not this SOP |
|
||||
|
||||
Weekends/holidays: business-day windows skip Sat–Sun; calendar-day windows count them.
|
||||
|
||||
### 3.2 Per-item overrides
|
||||
|
||||
Record override on the send-log row or checklist notes, e.g.:
|
||||
|
||||
- `silence_override: 10d` (slow enterprise support)
|
||||
- `silence_override: 3bd` (hot customer damage)
|
||||
- `no_nudge: true` (ticket-only platform; wait on their SLA)
|
||||
|
||||
**Birdeye (current):** use default **7 calendar days** from 2026-09-19 → first nudge eligible **2026-09-26** unless Gatekeeper says otherwise. Always run a VeriMail **inbox scan** the same day before nudging.
|
||||
|
||||
---
|
||||
|
||||
## 4. Nudge sequence
|
||||
|
||||
### 4.1 Caps
|
||||
|
||||
| Step | When | Max |
|
||||
|------|------|-----|
|
||||
| Original send | Day 0 | 1 |
|
||||
| **Nudge 1** | After silence window (+ override) | 1 |
|
||||
| **Nudge 2** (final) | **5 business days** after Nudge 1 with still no useful reply | 1 |
|
||||
| Then | Escalate or close per §5 | — |
|
||||
|
||||
**Hard cap:** 1 original + **2 nudges** = 3 outbound touches. No fourth email without a new Gatekeeper decision.
|
||||
|
||||
### 4.2 How nudge differs from original
|
||||
|
||||
| | Original | Nudge 1 | Nudge 2 (final) |
|
||||
|-|----------|---------|-----------------|
|
||||
| Tone | Full request + canonical NAP + authority | Short bump; assume they have the thread | Final bump; state close/escalate path |
|
||||
| Body | Full detail, links, old vs new | 4–6 sentences; quote date of original; restate one ask | 3–5 sentences; “closing our file on date X unless you need more info” |
|
||||
| Attachments | As needed | None unless they asked | None |
|
||||
| Subject | Full pattern (§1.3) | `Re: [original subject]` or `Follow-up: [original subject]` | `Final follow-up: [original subject]` |
|
||||
|
||||
**Nudge 1 skeleton**
|
||||
|
||||
> Following up on our message of [date] from ashbotphoenix@agentmail.to… regarding [surface / old listing].
|
||||
> Please confirm you can [remove | update] to: Phoenix Salon + Spa, 3460 Robin Ln Suite 4, Cameron Park CA 95682, (530) 350-9197, phoenixcameronpark.com.
|
||||
> Happy to provide anything else you need. — Phoenix listing desk (CC Anthony)
|
||||
|
||||
**Nudge 2 skeleton**
|
||||
|
||||
> Final follow-up on [date] request ([Message-ID or subject]). If we don’t hear back by [date + 5bd], we will mark this item closed on our side / escalate via [ticket|alternate channel]. Canonical NAP remains: [one line]. Thank you.
|
||||
|
||||
### 4.3 Before every nudge
|
||||
|
||||
1. VeriMail inbox Job Card → confirm **no reply** (artifact).
|
||||
2. Job Card for the nudge → Anthony **go**.
|
||||
3. Same thread/subject discipline; same From; CC rules if it’s a reply.
|
||||
4. Log as a new send-log row with `type: nudge-1` or `nudge-2`.
|
||||
|
||||
---
|
||||
|
||||
## 5. Stop conditions (resolved vs abandoned)
|
||||
|
||||
Mark the surface on `surface-checklist.md` and add a one-liner to the review loop.
|
||||
|
||||
### 5.1 RESOLVED (done)
|
||||
|
||||
Any one of:
|
||||
|
||||
- Live listing shows **canonical NAP** (evidence HTML/screenshot dated).
|
||||
- Vendor email/ticket confirms fixed or removed.
|
||||
- Duplicate/merged into the correct Phoenix listing and old name gone.
|
||||
|
||||
→ Status **GREEN**. Review loop: Worked? `yes`.
|
||||
|
||||
### 5.2 WAITING (still open, clock running)
|
||||
|
||||
- Original or nudge sent; inside silence window.
|
||||
- Or vendor acknowledged (“we’ll update in 2 weeks”) — set `silence_override` to their date.
|
||||
|
||||
→ Status **SENT** / **WAITING**. Do not nudge early.
|
||||
|
||||
### 5.3 ABANDONED / WONT-DO (close without fix)
|
||||
|
||||
Any one of:
|
||||
|
||||
- Nudge 2 sent + **5 business days** more silence → close as **ABANDONED-NO-REPLY** (document date).
|
||||
- No valid recipient / CF / no contact → **WONT-DO** at discovery (no nudges).
|
||||
- Gatekeeper says stop.
|
||||
- Risk/legal: stop and escalate to Anthony only.
|
||||
|
||||
→ Status **WONT-DO** or **ABANDONED**. Review loop: Worked? `no` + Cut note (“email dead-end on this platform”).
|
||||
|
||||
### 5.4 ESCALATE (instead of more email)
|
||||
|
||||
After Nudge 1 or 2, if the platform has a better channel:
|
||||
|
||||
- File a support ticket (log ticket ID).
|
||||
- Ashley Primary Owner login path.
|
||||
- Pause and re-triage as customer-surface fix (e.g. GBP) rather than aggregator mail.
|
||||
|
||||
Escalation still needs Gatekeeper **go** if it spends Ashley’s time or money.
|
||||
|
||||
---
|
||||
|
||||
## 6. Quick checklist (copy per item)
|
||||
|
||||
- [ ] Tier assigned (1/2/3)
|
||||
- [ ] Recipient from decision tree (or WONT-DO)
|
||||
- [ ] Job Card + go
|
||||
- [ ] Sent + receipt + send-log row
|
||||
- [ ] Silence window / override recorded
|
||||
- [ ] Inbox scan before each nudge
|
||||
- [ ] ≤2 nudges
|
||||
- [ ] Stop: RESOLVED / ABANDONED / WONT-DO / escalated
|
||||
- [ ] Review loop row updated
|
||||
|
||||
---
|
||||
|
||||
*v1.0 CoS 2026-09-20. Change silence defaults only with Gatekeeper approval; bump version when you do.*
|
||||
|
||||
|
||||
Reference in New Issue
Block a user