---
id: "12.7"
title: "Notices to customers, Scoop"
dept: customer-success-and-support
status: draft
owner: Param
branded: true
direction: raccoon
last_verified: "2026-10-26"
sources:
  - "brew/public/app.js:1609-1615, 2966-2967"
  - "brew/connectors/index.js:53, 474-493"
  - "brew/alerts.js:1-12"
  - "brew/docs/production.md:114-115"
  - "brew/tools/promote.sh:1-9"
  - "brew/legal-pages.js:6, 18-19, 35-36"
  - "memory brew-qa-round2-2026-10-24, brew-prod-backend"
  - "brand-directions/docs2/data/dirs.json"
  - "brand-directions/raccoon/system.md"
  - "brand-directions/book/content/g.js g-3, checked against the code"
---

# Notices to customers, Scoop

## Answer

How we tell brands about an incident, planned maintenance, a lost connection, a change or a policy change, and the one place Scoop may appear in them.

## Today

No notice system exists. Nothing tells a brand about an incident, maintenance or a change except what is below.

| What exists | Detail | Source |
|---|---|---|
| Writing paused | A one time toast when AI writing is paused: `Our writing is paused for a while. Everything here still opens; new replies, drafts and rewrites wait until it’s back.` | [src: brew/public/app.js:2966-2967] |
| Plays paused | The feed's paused card: `The plays are paused` with how many Plays are written | [src: brew/public/app.js:1609-1615] |
| A sign in running out | An email to admins 7 days ahead and when it runs out | [src: brew/connectors/index.js:53, 480-493] |
| A stale connection | Last numbers are marked stale after 72 hours or 3 failed reads | [src: brew/connectors/index.js:53, 474-478] |
| Alerts to us only | Billing, quota, AI pause, treg, server errors, Sloosh, worker and queue alerts go to our inbox, never to brands | [src: brew/alerts.js:1-12] |
| Monitoring to us only | Uptime and alert policies email param@ and hello@ | [src: brew/docs/production.md:114-115] |
| Releases | Each release promotes staging's exact image and rolls back on a failed check | [src: brew/tools/promote.sh:1-9] |
| Policy | Privacy and Terms are preview pages dated 19 October 2026. A full policy comes before the product opens to everyone. | [src: brew/legal-pages.js:6, 18-19, 35-36] |
| Known after a release | The first load after a release is slow. Noted 25 Oct. | [src: memory brew-qa-round2-2026-10-24] |

## Tomorrow

| Version | Tag | Item |
|---|---|---|
| v1 | New | Six notice templates, below, sent by a named person for anything on our side. |
| v1 | New | Incidents that last more than 30 minutes or touch a brand's data get a notice. Shorter blips do not. Proposed. |
| v1 | Changes | The writing paused toast and the paused card drop the product name and say Plays. |
| v1 | Changes | Stale connections tell the admins by email the same day, as sign in expiry already does. |
| v1 | Stays | Alerts and monitoring stay with our team. Brands hear from a person, never from an alert. |
| v2 | New | A status line in the product while an incident is open. |

### The templates

| Notice | When | Plain words | Who and how | Scoop |
|---|---|---|---|---|
| Incident | Something on our side stopped working for you | `<What broke>, since <time>. Your <feed, jams, briefs> are safe. We are fixing it and will write again by <time>.` | A named person, email, within the hour of knowing | None |
| Incident resolved | It is fixed | `<What broke> is fixed since <time>. <What you may need to do, or nothing>. Sorry for the trouble.` | The same person, email | None |
| Maintenance | Planned downtime | `On <day> from <time> to <time>, <brand> may not open. Nothing is lost. Reads and drafts wait until it is back.` | Email, 2 working days ahead | None |
| Connection lost | A tool stopped reading | `<Tool> stopped reading for <brand> on <day>. Its last numbers are marked stale. Connect it again to bring them back.` | Admins, email, the same day | None |
| Change | Something new or different in the product | `New: <one sentence on what changed>. <Where to find it>.` | In the product, once, and in the weekly founder note | One line allowed: “Everything everyone says about your store.” as a sign off, never in the change itself |
| Policy change | Privacy or terms change | `Our <privacy page or terms> change on <date>. What changes: <one line>. Read it here.` | Email to admins, 14 days ahead | None |

### Scoop's rules for these lines

- Talk to you about your store. Scoop talks about itself for four words at most.
- One idea per line, two sentences at most.
- Say what the read looks at whenever reading happens: public pages, and read only connections if any.
- Describe rivals by patterns across what runs in a category. No names or logos.
- A person, never Scoop, handles money, privacy, apologies and anyone upset.

[src: brand-directions/docs2/data/dirs.json; brand-directions/raccoon/system.md]

In a notice that rule means Scoop stays out of every incident, maintenance, connection and policy notice. Those are errors on our side, access or something a person must agree to.

Lines Scoop never says, in any of these:

- “I posted it for you.”
- “Your sales went up this week.”
- “I looked through your inbox.”
- “Your rival, named, is losing customers.”
- “Psst, upgrade for more.”

[src: brand-directions/docs2/data/dirs.json]

## How we do it

1. When an alert or a partner shows something broke, the reader of the day decides within the hour: does it last more than 30 minutes or touch data. If yes, it gets a notice.
2. Find who is affected: the brands on production, and their admins.

   ```bash
   gcloud run jobs execute brew-ops --region=asia-south1 --wait
   ```

3. Send the incident template from hello@joinsquareup.com, signed by a first name, to each affected brand's admins.
4. Write again when it is fixed, with the resolved template, the same day.
5. For maintenance, send the template 2 working days ahead, and pick a time outside the brands' working hours.
6. For a policy change, update the date on the page and email admins 14 days before it takes effect.
7. Add a row to known issues for anything a brand may still see after the fix.

## Numbers

| Metric | Definition | Where measured | State |
|---|---|---|---|
| Time to first notice | Minutes from our first alert to the first notice sent | alert email time against the notice | Proposed |
| Incidents per month | Incidents that got a notice | hello@ sent, label incident | Proposed |
| Notices resolved same day | Share of incident notices followed by a resolved notice the same day | hello@ sent | Proposed |

## Open

1. What counts as an incident worth a notice? Proposal: more than 30 minutes down, or anything that touches a brand's data or connections.
2. Who sends notices? Proposal: Param during the design partnership, from hello@joinsquareup.com, signed with his first name.
3. Do we pick a fixed maintenance window? Proposal: no fixed window; releases already roll back on their own, and planned downtime gets 2 working days notice.
4. May Scoop appear in change notices? Proposal: only as the sign off line in the table, never in incidents, maintenance, connections or policy.