How BHASM briefs are generated.
From raw data to a founder-facing message: every step, every decision, every check. The complete pipeline that produces the weekly dividend.
What triggers a brief
| Trigger | When | Cap |
|---|---|---|
| Weekly brief | Every Sunday 02:00 UTC, per tenant | 1 / week guaranteed |
| First-import brief | Immediately after CSV upload or first connector OAuth | 1 per import |
| Manual brief | Founder clicks Run brief now on the dashboard | 3 / UTC day |
| Event brief | Connector signals a spike (cart abandon, sentiment shift) | Per-event throttle |
Customer selection
Every active customer gets scored. Only those above the surfacing threshold land in the brief — and the threshold adjusts to the health of your business.
- Active set: customers currently in scope and not in permanent hold.
- Brief size: 3–10 cards per run, configurable per tenant.
- Priority: urgency descending. Ties resolved by value at risk.
- Adaptive surfacing: when retention risk is elevated across your customer base, the threshold lowers so more developing signals reach the brief.
- Minimum brief guarantee: BHASM ensures a useful brief even during unusual quiet periods — the founder never sees an empty brief when there is signal to surface.
The governance gauntlet
Before any message is generated — let alone sent — every customer passes through a multi-layer governance check. Each layer is a structural wall, not a suggestion.
The governance stack covers signal validity, contextual fit, sentiment safeguards, frequency limits, account scope, audit trail, send-timing guards, lifecycle classification, and calibration. Each layer can hold a send. Hold reasons are surfaced in plain English — never as opaque error codes.
Approximately 1 in 6 messages drafted is held at one of these checks. The hold is not a delay — it is a stop. The held record is logged and visible in the decision log of your private dashboard, with the originating check cited.
Message generation
Template selection
From a library of 60+ message templates. The selector matches each customer to the template best suited to their current state and the channel they actually respond on.
Internal polish
Five-pass cleanup: strip corporate language, apply archetype voice, inject cultural context, apply the tenant's voice profile, enforce channel length. Deterministic. No API calls. Always produces something better than the raw template.
Claude enrichment (top account only)
The highest-urgency customer of the brief gets a Claude-crafted message. Why only one? Best message goes to highest stakes. The rest are template + polish, which is good enough at scale and avoids API cost ballooning.
Final polish pass
Length cap per channel (WhatsApp 320 chars, email subject 50). Banned-phrase scrub. Voice profile final apply. The message that lands in the brief.
Channel and timing
Channel and timing are computed per customer, not per tenant.
Channel selection
Default rule: WhatsApp where the customer is opted in and has recently engaged on that channel. Email otherwise.
Override: per-customer channel preference from connector data wins. Tenant-wide setting overrides only when no per-customer preference exists.
Timing — when to send
BHASM learns from each customer's response history. The optimal send window narrows over time, based on when this specific customer has actually responded before.
For new customers without a response history, a sensible default is used — calibrated to similar customers in the same industry — until enough of the customer's own pattern emerges to refine it.
After the brief
| Founder action | What happens |
|---|---|
| Send | Message dispatches. Intervention row created. Outcome watcher armed for 14-day attribution window. |
| Edit + Send | Same as Send, plus the edit is captured as a voice training signal. After 3 edits, BHASM extracts and stores the tenant's voice profile. |
| Skip (no reason) | Customer marked as skipped this cycle. Resurfaces next brief if signal persists. |
| Skip + reason tag | Reason logged to your decision log. Feeds the calibration layer — future briefs adjust for similar patterns. |
| Hold customer | 14-day suppression. No surfacing. Useful for known life events. |
Attribution
A recovery counts when, and only when, a real purchase happens after a real BHASM intervention.
- Attribution window: 14 days after send.
- What counts: a purchase by the same customer (matched by email, phone, or connector ID) within the window.
- GA4 cross-reference: if connected, the conversion is matched to a session with the BHASM UTM tag for double-confirmation.
- What does not count: a purchase that occurred before the send (timing matters). A purchase from a different customer with a similar name. A return / refund / dispute.
- Recorded: in your decision log. Visible in the dashboard's recovery panel. Aggregated in the Performance tier billing calculation.