Idea-stage exploration. No product exists yet.
Technology direction
Customer Growth Engine
A governed direction for one repeated decision: from the customer sources a company already holds and may use, check who is eligible and who stays suppressed, then propose one recommendation with its reason for a person to review.
Static illustration: every record, person, and recommendation on this page is invented or anonymized — nothing runs, nothing is sent or scheduled, and no real customer is contacted.
The decision flow
Permitted sources in, one reasoned recommendation out
The capability is designed around one repeated task — deciding, for one person, whether a recommendation is allowed and worth a human follow-up — never around running an autonomous marketing system.
Three bounded stages
Permitted sources only
The flow reads only the customer sources the company already holds and has the right to use for the agreed purpose — order history, consent ledger, support tickets, and product views in this sample. No bought list and no third-party enrichment ever enters.
Eligibility and suppression
Before any recommendation is considered, every person is checked against the rules the company agreed: which contact right exists, which channels are allowed, and which opt-outs stand. A suppression wins over every signal, and a missing record is never guessed from silence.
Recommendation with a written reason
For a person still eligible, the flow proposes one recommendation and writes the reason in plain language, naming the sources it used. Nothing is sent or scheduled: a person reviews, approves, changes, or rejects it, and the decision is recorded.
Where the scope stops
The flow covers one decision point and one reviewed recommendation. It does not send messages, manage every campaign, replace the company CRM, or build audience profiles from outside data.
Everything below describes that bounded flow as a static illustration with invented text — not a service that runs, and not a system any company can switch on from this page.
An inspectable example
Four invented people, four honest verdicts
The shortest sample shows the whole shape before any real work: a few invented source rows feed one decision table where a permitted case proceeds, an opt-out stays suppressed, a missing record is paused, and a conflict is flagged for a person.
Static illustration — invented people, invented records, no real data
Permitted source rows (invented and anonymous)
Every row names its source; every name, order, and preference below is fabricated for this page.
- Order historyRefill product ordered twice in the past year; last order eight months ago.
- Consent ledgerContact opt-in is active for the product category, email channel.
- Consent ledgerMarketing opt-out is active on this person, all channels.
- Consent ledgerNo consent row exists for this person yet.
- Support ticketsClosed ticket reads: “Please do not email me again.”
- Product viewsVisited the refill page twice in the last week, without purchasing.
What the flow decides, in a person-reviewable table
| Person (invented) | Sources read | Verdict | Reason, written for a reviewer |
|---|---|---|---|
| Person A | Order history, Product views, Consent ledger | Permitted | Repeated visits to a refill product match the past order pattern, and the consent ledger shows an active opt-in for that category and channel. The flow proposes one refill reminder with its reason; a person still reviews and can reject it. |
| Person B | Order history, Product views, Consent ledger | Suppressed | Strong product interest is visible, but the consent ledger shows a marketing opt-out. The opt-out wins over every signal: no recommendation for contact is made while it stands, and no reason is invented to work around it. |
| Person C | Order history, Consent ledger | Missing information | The person has an order history but no consent row in the ledger. There is no record of the right to contact, so the case is flagged as missing information and paused for a person — silence is never read as permission. |
| Person D | Product views, Consent ledger | Ambiguous input | The product-view record does not identify which category the visit belongs to. The input is ambiguous, so no eligibility decision is guessed; the case is paused and labelled for a person to clarify. |
| Person E | Order history, Support tickets, Consent ledger | Conflicting sources | The consent ledger shows email updates allowed, while a support ticket records “please do not email me again”. The two sources disagree, so the case is flagged for a person; nothing is recommended or sent until the conflict is resolved and the decision recorded. |
What a reviewer sees next
A proposal, never a send
For the permitted case the reviewer sees one draft recommendation with its sources and can approve it, change it, or reject it — approving starts a human follow-up, never an automatic message.
A pause that stays visible
The missing case stays flagged until a person decides how to record consent; the flow does not quietly drop it or guess.
An escalation with a recorded decision
The conflicting case is escalated to a named reviewer, who resolves which source wins for that person and writes the reason into the record before anything else happens.
What runs on this page
- Static illustration
The source rows, cases, and decisions are fixed text here; nothing reacts, changes, or moves.
- Manual steps
Checking consent, deciding a verdict, and following up are human actions, shown only as text.
- No connected systems
No CRM, ledger, or storefront is connected, so nothing is read from or written to one.
- Working functionality
None runs here — no model reads the sources, and no message is drafted, sent, or stored.
Explicit boundary: these panels and values are fixed text on this page. No model executes, no system is connected, no opt-out is overridden, and no real person is contacted, messaged, or sent anything.
A real engagement would agree the sources, the consent rules, and the review steps first, then replace this sample with its own reviewed case.
Honest measurement
Observed, attributed, and causal stay separate
Three different questions are never collapsed into one score. The words below keep them apart, and the page promises none of them as a result.
Three senses of “what happened”
- Observed
- What the company records actually show: an order was placed, a page was visited, an opt-out was registered. Observations are facts of the record, nothing more.
- Attributed
- Where the company agrees a comparison method in advance, an estimate can connect an activity to an outcome. Attribution is shown as an estimate with its limits — never as proof that one activity caused the outcome.
- Causal
- Saying that an activity caused an outcome needs a designed experiment with a control group. No result on this page claims causality, and none has been measured.
What is not promised
- No uplift guarantee: no figure on this page promises a revenue lift, and no number is offered as a prediction.
- No invented benchmark: no comparison or industry figure is fabricated to make the direction look better.
- No reported result: the invented cases above illustrate the decision flow; they are not outcomes of a run.
Measurement is described here as direction. This page reports no result, and a real run would be a separate, reviewed step with its own labelled evidence.
Boundaries and responsibilities
Purpose, data rights, and where the flow stops
Four plain commitments keep the direction reviewable. Each one is settled with the company before any real customer data is handled.
Purpose and data rights
Data is used only for the purpose the company and the person agreed, and only from sources the company already holds. A person can ask what is held, why, and to have it corrected or removed — the request goes to a human, not a model.
Human review before anything
Recommendations are proposals for people. Nothing is sent, scheduled, or executed until a human owner reviews and approves it, and an opt-out is never overridden by any rule or automation.
Rejection, escalation, and fallback
A reviewer can reject any recommendation and the reason is recorded. A case the flow cannot decide is escalated to a named reviewer, and the manual fallback — a person working from the same permitted sources — always stays available.
Scope exclusions
Out of scope: no outbound sending, no buying or renting of contact lists, no third-party enrichment, no replacement of the company CRM, and no claim of revenue uplift.
Rejection, escalation, and the manual fallback stay in place at every step, so a suppressed, missing, or conflicting case never forces an automated choice.
Human ownership
Every step has a human owner
A human owner stands behind every recommendation: nothing is sent, scheduled, or executed until a person reviews, adjusts, and approves it, and every rejection records its reason.
Ownership is built into the flow itself, not a bolt-on review step at the end.
Honest status
Planned state, from the same registry
The name and the three axes below come from the typed registry every public page reads: one capability at its planned state, nothing more.
- Registry name
- Customer Growth Engine
- Stage
- concept design
- Availability
- not offered
- Proof
- design illustration
Stated scope in the registry
Offline preview: no outbound messages, outreach stays off, and no causal claim is made. Nothing on this page authorizes the operation of the described product.
The capability stands at concept design: no customer data has been processed by this flow, no run has been measured, and this page reports no result — only the direction above.
No evaluation is claimed here. This page alone does not fulfil PRD v2 FR16 evaluated-product evidence: that evidence would come from a separately reviewed run of the direction under an agreed scope.
Sibling direction
Seed a studio brief from an approved follow-up
An approved follow-up idea can seed a creative brief in the planned Super Studio — the Academy and Workspace creative product explained there, still planned and not ready to produce anything. The handoff stays a proposal a person starts and reviews, never a silent pipeline.
Explore the Super StudioPrivate consultation
Scope one sample brief locally
The private consultation preview runs entirely on this site: three local, rule-based questions about one real operational problem produce a brief you can review and edit in ephemeral in-tab memory. It does not contact Halsamer. Clipboard/download only on explicit user action; browser restore/session behavior is outside page control.
Draft a sample briefLocal preview only: rule-based and no AI model runs; no answer/form submission or contact occurs; form answers exist only in ephemeral in-tab memory and are not sent to Halsamer. Clipboard/download only on explicit user action; browser restore/session behavior is outside page control.