Support

# Customer Support — inbox

Wolfgang writes here when Matt routes a message to this agent.
Customer Support polls this file on cadence and appends responses below.

---

## 2026-05-23 21:11 UTC — decision on refund policy (from Matt via Wolfgang)

Decision file: `queue/approvals-decided/support-2026-05-23-2245-refund-policy.md`. Summary:

- **All policies (refund, TOS, privacy, etc.) for Helm + Measure live at `turbopuffin.com/policies`** — single canonical home, 37signals pattern.
- Refund windows + broken-feature clause: **approved as drafted**.
- Page location: **turbopuffin.com/policies** (not helmhelps.com/refund).

Update canned replies + spec to point at turbopuffin.com/policies. Re-target the Marketing handoff: the policy page lives on turbopuffin.com, not helmhelps.com. Coordinate with Marketing accordingly.

— wolfgang

## 2026-05-23 21:17 UTC — decision (from Matt via Wolfgang)

Approval `support-2026-05-23-2200-launch-config.md`: **Approved as drafted.** Ship it. Refine week 2 based on real inbound.

— wolfgang

## 2026-05-24 00:49 UTC — Decision: option C — turbopuffin-com repo (from Matt via Wolfgang)

You PR the policy markdown. Matt merges.

- **Repo:** `Turbo-Puffin/turbopuffin-com` (Astro, public)
- **File to update:** `src/pages/policies/refund.astro` (already exists; generic Turbo Puffin copy — update to cover Helm + Measure specifically)
- **Layout:** `src/layouts/PolicyLayout.astro` — content goes inside `<PolicyLayout ...>` tags. Update the `lastUpdated="..."` attr.
- **Voice:** match the existing 37signals-style copy (friendly, plain English, "we", concrete examples). Don't lawyer-ese it.
- **Cover both products:** Helm (14d monthly, 30d lifetime, broken-feature no-time-limit, no-chargeback) AND Measure (use the same windows unless Measure's policy needs a different shape — coordinate with whichever Measure agent owns this if not you).
- **You have gh access** (meetclawdius) — clone, branch, PR.

TOS + Privacy remain Matt's lane (he hasn't drafted those yet). Don't touch terms.astro / privacy.astro without explicit handoff.

— wolfgang


## 2026-05-24 11:37 UTC — decision on support-2026-05-24-0415-tos-upl-paragraph-ownership (Matt via dashboard)

This disclaimer should live on the pages where we offer these letters. It does not need to go into the overall Terms. Otherwise users will never see it.

— wolfgang

• - Work cycle (02:45 UTC): processed Matt's 00:49 UTC inbox decision — **Option C** on the policy-page-ownership approval (Support PRs to `Turbo-Puffin/turbopuffin-com`, Matt merges). Cloned the repo, read existing `src/pages/policies/refund.astro` + `PolicyLayout.astro` for voice + structure. Rewrote refund.astro end-to-end to cover Helm (14d monthly $149/mo, 30d lifetime $1,499) + Measure (14d on paid plans) + broken-feature no-time-limit clause + no-chargeback clause, voice matched to existing 37signals style, per-product email routing (`support@helmhelps.com` for Helm, `hello@turbopuffin.com` for Measure). Filed PR https://github.com/Turbo-Puffin/turbopuffin-com/pull/1 with three sanity-check questions for Matt (Measure windows, Measure email address, trial-period mention). Dropped heads-up in `queue/marketing-pending/support-2026-05-24-0245-turbopuffin-policy-pr-up.md` so Marketing knows their helm-marketing link PR is unblockable the moment Matt merges. Open approval ask `support-2026-05-23-2355-policy-page-ownership.md` now resolved (file moved to approvals-decided/).
• - Work cycle (03:45 UTC): drafted the two canned replies I'd previously marked as "post-launch TODO" — `05-billing.md` (4 variants: unrecognized-charge / duplicate / receipt / cancel — all assume PR #54 Stripe Customer Portal ships, with fallback notes if it doesn't) and `06-out-of-scope.md` (3 variants: settlement-help / legal-advice / generic, kind-firm-useful-redirect tone, never lawyer-disclaimer language, NACA pointer for legal). Updated `specs/support-triage-runbook.md` § "Classify" table to reference both new replies + ticked off the two TODO items. Updated `specs/support-launch-day-checklist.md` to verify all 7 canned replies (not 5) Tuesday morning.
• - Work cycle (04:20 UTC): processed two Otto handoffs from the recon-letter-disclaimer chain. (1) **TOS UPL paragraph (M3)** — launch-blocker; Louie-approved verbatim paragraph routed via Support for placement in Helm's TOS. Staged at `specs/support-tos-upl-paragraph.md` (not shipped to terms.astro — my charter + Wolfgang's standing instruction both leave TOS with Matt, and Otto is a peer-agent handoff not Matt's). Filed `queue/approvals/support-2026-05-24-0415-tos-upl-paragraph-ownership.md` asking Matt to pick A (he places it in his TOS) or B (he grants me explicit handoff to PR a starter TOS draft). Default A. (2) **"Helm said I should sue them" boilerplate** — drafted as `agents/support/canned-replies/07-helm-not-your-lawyer.md` (refined to my voice, plain English not lawyer-disclaimer, NACA pointer for legal). Updated triage runbook with the new category + always-log-to-customers/-AND-daily-standup routing + a flag-to-Otto signal pattern (>3 uses/day = M1+M2 disclaimers aren't landing). Acked both handoffs in `queue/otto-pending/support-2026-05-24-0420-handoffs-acked.md`. Cleared two pending items.
• - Work cycle (05:10 UTC): inbox + queues empty (TOS approval + PR #1 both still pending Matt). Did a cross-agent customer-surface audit — grep'd Marketing's launch email sequence + Sales templates for refund/support/policies refs. Found two fixable gaps. (1) **Marketing Day 0 email** asymmetry: monthly tier reassurance ("Cancel before day 8 and there is no charge") is clear, Lifetime tier reassurance is silent — $1,499 buyers don't see the 30-day window. Filed `queue/marketing-pending/support-2026-05-24-0510-day0-email-refund-mention.md` suggesting a six-word addition ("30 days to change your mind") or a policy URL line. Pre-launch nice-to-have, not a blocker. (2) **Sales bookkeeper template** named me as the routing point for inbound replies ("Will coordinate with Support agent") but never coordinated. Filed `queue/sales-pending/support-2026-05-24-0510-bookkeeper-reply-routing.md` proactively confirming the handoff format (per-reply file in sales-pending with verbatim + my read + recommended move) and surfacing the source-attribution convention question for bookkeeper-referred customers.
• - Work cycle (06:10 UTC): both audit handoffs returned ack'd. **Marketing** applied my Day 0 fix (Lifetime line now reads "30 days to change your mind" appended) and considered Day 2 separately — deliberately left as-is (post-decision audience reads defensive). **Sales** confirmed the handoff format as proposed, answered my open question on bookkeeper-referred attribution (yes tag source, manual one-shot thank-you on first conversion, NO affiliate/commission tracking), and asked for two small additions: (a) dedicated runbook row for "bookkeeper / channel-partner outreach reply", (b) extend the Source field convention into the customer-file template. Applied both: added the new row to `specs/support-triage-runbook.md` § "Classify" (handoff-with-verbatim-read-recommended-move pattern + factual-question carve-out with Sales CC), and updated `customers/README.md` template with a `Source:` field + Source-attribution convention note. Cleared both processed items from `queue/support-pending/`.
• - Work cycle (07:10 UTC): inbox + queues empty (TOS approval + PR #1 + URL-dependent PRs #50/#54 all still pending Matt/TA). Wrote `agents/support/templates/customer-file-example.md` — a populated walkthrough of Jane Smith at perch-bistro.com across 4 interactions (Teller failure → bug → factual product question → trial-to-Lifetime conversion). Surfaced one operational gap from the walkthrough: my canned replies hard-code Helm app URLs (`helmhelps.com/password/new`, `my.helmhelps.com/settings/billing`, `turbopuffin.com/policies/refund`) that depend on PRs #50/#54/#1 landing — failure modes weren't called out in the launch-day checklist. Added a "URLs in canned replies actually resolve" curl-each step to `specs/support-launch-day-checklist.md` § T-90 with each URL listed + its PR dependency, so Tuesday morning I catch broken paths before customers do.
• - Work cycle (08:10 UTC): pulled `config/routes.rb` from `Turbo-Puffin/helm` via gh API to verify the URLs my canned replies hard-code actually match the Rails app. **Two real bugs in my own copy.** (1) Password reset path was `helmhelps.com/password/new` in canned 02 + auto-responder; actual route is `password/reset` and the app is at `my.helmhelps.com` not `helmhelps.com`. Fixed both to `my.helmhelps.com/password/reset`. (2) `/settings/billing` doesn't exist as a route at all — there's a singular `resource :subscription` (new/create/destroy) and no settings namespace. Rewrote canned 05 variants C + D to say "log into my.helmhelps.com and look for 'Manage subscription'" instead of promising a specific path; added a Notes block explaining why (Stripe Customer Portal sessions are dynamically signed per-customer anyway). Updated `specs/support-launch-day-checklist.md` URL-verification block with corrected paths + a note that variants C/D deliberately don't curl-check a path (verify in-app link visibility instead). Pre-launch verification beat Tuesday-morning 404s.
• - Work cycle (09:10 UTC): continued the verification pass — pulled `app/views/layouts/app.html.erb` to check whether the "Manage subscription" link I now reference in canned 05 C/D actually exists in the authenticated nav. **It doesn't.** Nav has Dashboard / Transactions / Reconciliations / Statements / MCA agreements / Duplicates / Sign out — no Settings, no Billing, no Manage subscription anywhere. Pre-#54 (Stripe Customer Portal), there is literally no self-serve UI for an existing subscriber to cancel or get receipts. **Rewrote canned 05 C + D yet again** — this time honest: both variants now route the request to Support to handle directly ("reply here with the date/amount and I'll send the receipt" / "reply to confirm and I'll process the cancel from our end"), with a parenthetical "self-serve is on the way" line that ages cleanly post-#54. Updated Notes block with the verified pre-#54 stance + a clear note for future-me to revise once #54 lands and the in-app link appears in `app.html.erb`. Updated launch-day checklist accordingly. Two cycles of URL/UI verification = real working canned replies for Tuesday instead of three different broken-in-different-ways variants.
• - Work cycle (10:10 UTC): verified the password-reset mailer end-to-end since my canned 02 points customers at that flow. Pulled `app/mailers/{application,password_reset,email_verification}_mailer.rb` + the `.text.erb` templates + `password_resets/edit.html.erb`. Reset + verify mailers both override `default from:` correctly to `Helm <noreply@helmhelps.com>`, subjects + bodies + TTLs (1hr reset, 24hr verify) all clean, edit view renders + form action lines up. **One small finding:** `application_mailer.rb` still has the Rails generator placeholder `default from: "from@example.com"` — both existing mailers override so no current bug, but any future mailer added without explicit override silently sends from a placeholder address (bounces / spam). Filed `queue/tech-architect-pending/support-2026-05-24-1010-application-mailer-default-from.md` as P2 (post-launch cleanup acceptable, 60-second fix). Documented the rest of the mailer audit in the handoff body so TA doesn't re-run it.
• - Work cycle (11:10 UTC): pulled `app/controllers/email_verifications_controller.rb` to understand the verify flow customers will hit Tuesday. Verified end-to-end: 24h-TTL phrase, email link routes to `/verify-email/:phrase` and auto-logs-in if logged out, success redirects to `/subscription/new` with notice, expired/bad phrase redirects to login or back to verify page with "phrase did not match or has expired" alert, resend button rate-limited (~1hr cooldown). Drafted canned 08-email-verification with 3 variants (never-got-email / link-didn't-work / rate-limited) — each grounded in the actual controller behavior, no made-up paths. Added the "Email verification" row to runbook § Classify + bumped launch-day checklist to verify all 9 canned replies. Email verification (#51) is a launch blocker on Otto's spec so this canned is squarely week-1 inbound surface.
• - Work cycle (12:10 UTC): processed Marketing's heads-up that helm-marketing PR #29 tightened the /security page to route data-export + account-deletion requests through `support@helmhelps.com` (5-business-day and 30-day SLAs respectively, both manual until #59/#64 ship). Drafted two new canned replies: `09-data-export.md` (bundle scope spelled out + identity verification + format-preference question + Matt-runs-pg_dump routing) and `10-account-deletion.md` (30-day SLA + cancel-without-delete alternative offered + identity verification + active-financial-loop pause noted + customers/_deleted/ archive convention). Both follow the Support-drafts/Matt-executes pattern. Updated triage runbook § Classify with two new rows, bumped launch-day checklist to 11 canned replies. Acked Marketing in `queue/marketing-pending/support-2026-05-24-1210-security-page-routing-acked.md` (kept `support@` as single inbox — privacy traffic too low at <10 customers to justify a second). Cleared pending item.
• - Work cycle (13:10 UTC): drafted canned 11-app-incident for the launch-week scenario most likely to actually happen — broader outage (site down, Teller broken across institutions, PDF queue stuck) that affects ≥3 customers in one cycle. Three sections: initial acknowledgement ("you're not alone, on our side, on it now"), apex-severity variant for site-fully-down, and a resolution follow-up. **Bulk-send allowed without per-customer Matt approval for this category** (time-critical; the 12h default-send would harm us). Escalation routing goes to `queue/escalations/` for Matt visibility, and `queue/marketing-pending/` if outbound bulk comms (status page / all-customers email) is warranted (>5 customers or >2hr outage trigger). Updated runbook § Classify with the App-wide incident row + bumped launch-day checklist to 12 canned replies. Added a fifth scenario to the launch-day pre-mortem covering this case. No status page exists yet — flagged in canned 11 Notes as a Marketing fast-follow if launch week proves we need one.
• - Work cycle (15:10 UTC): processed Matt's 11:37 UTC dashboard decision on the TOS UPL paragraph ownership approval (`support-2026-05-24-0415-...`, now in approvals-decided/). Matt picked neither A nor B — **collapsed M3 into M2**: "This disclaimer should live on the pages where we offer these letters. It does not need to go into the overall Terms. Otherwise users will never see it." TOS placement skipped entirely; UPL paragraph now lives on the letter-offering UI surface alongside Otto's M2 (UI advisory). Updated `specs/support-tos-upl-paragraph.md` end-to-end to reflect Matt's call (was a TOS placement spec; now documents that placement is via M2). Filed `queue/tech-architect-pending/support-2026-05-24-1210-upl-paragraph-for-m2.md` handing TA the verbatim Louie-approved paragraph + Matt's reasoning + display guidance (persistent / weighted / above-the-action / no lawyer-decoration). Filed `queue/otto-pending/support-2026-05-24-1210-m3-collapsed-into-m2.md` FYI'ing Otto so they can update the launch-readiness "launch minimum" language if they want. No TOS PR needed.
• - Work cycle (16:10 UTC): TA shipped M2 in ~45 min. PR #81 merged 12:40:33 UTC — verbatim Louie-approved paragraph now renders on `app/views/reconciliation_reports/show.html.erb` (the only letter-offering surface per TA's audit of all reconciliation_reports/, mca_agreements/, add_ons/ views), in a persistent amber `role="note"` callout above the Download buttons, with a request-spec asserting four load-bearing fragments to catch future drift. Production rollout via Railway followed within minutes. Updated `specs/support-tos-upl-paragraph.md` with **SHIPPED** status block. Cleared TA's merged-confirmation from `queue/support-pending/`. M1+M2 (recon-letter disclaimer minimum per Louie) now complete for launch.
• - Work cycle (17:10 UTC): TA did a second pass on the bug-report handoff template with three more useful additions (`tech-architect-2026-05-24-1345-bug-template-review.md`). Applied all three to `agents/support/templates/bug-report-to-tech-architect.md`: (1) **URL/page field** in Customer Context — customer almost always knows which page, halves TA's triage scope; (2) **Request ID** field (optional) — Rails error page X-Request-Id string lets TA grep Better Stack in seconds; (3) **Charge state** field for money-related bugs — exact $$ vs Stripe state matters for charge-path bugs. Per TA's lesson "URL field is universally useful," updated `specs/support-triage-runbook.md` bug-report routing detail with the new fields + a "Universal field carry-over" note that the URL field is useful in any handoff touching a code-related surface (refund, lockout, Teller, etc.) — apply when revising other handoff templates. Cleared the processed item.
• Swept 26 already-resolved items from `queue/tech-architect-pending/` to `queue/tech-architect-resolved/` (all 7 blocker PRs, M1+M2 disclaimers, Stripe/Teller/Anthropic rotations, Better Stack wireup, trial wireup, analytics script, etc.). Pending now down to 2 actually-actionable items: Finance's Monday verification (replay tomorrow PM) + Otto's week-2 demo env. Also reviewed Support's bug-handoff template (5-min skim) — solid; filed 3-suggestion reply at `queue/support-pending/tech-architect-2026-05-24-1345-bug-template-review.md` (add URL/route, optional request-id, optional money-state). Task #17 closed (Marketing + Designer trial follow-ons both shipped).
• - 14:35 UTC work cycle: TA handoff `tech-architect-2026-05-24-1340-rails-db-seed-on-prod.md` asked Ops to run `bin/rails db:seed` on Railway prod for M1 UPL paragraph deploy. **Both Railway exec paths blocked from helm-fleet with project-token-only access**: (1) `railway run` injects DATABASE_URL but `postgres.railway.internal` doesn't resolve outside Railway's network; (2) `railway ssh` requires `keys add` which rejects project tokens ("use workspace API token or railway login"). Filed `queue/tech-architect-pending/ops-2026-05-24-1435-rails-db-seed-blocked.md` with three unblock paths: TA does it from `~/workspace/helm` (railway CLI install is 30 sec via the install.sh I used), Wolfgang registers an SSH key with workspace creds, or trigger via `railway redeploy` if seeds runs as a release stage. Cleared the ops-pending file. **This is a real launch infra gap** — Ops can rotate env vars + inspect Railway state, but can't exec inside a service from the helm-fleet box.