The product
See every lifecycle stage running on real behaviour
Onboarding, activation, at-risk and win-back journeys operate across email and in-product channels. You approve the templates and journey logic; AI colleagues run the rest.
An operator's day
One journey, stage by stage
The same path a contact travels, from first send to recovery, as it happens in the product.
A new user enters
A new user arrives through your connected acquisition and product data. AI colleagues place them in a behaviour-based onboarding sequence, draft stage-appropriate copy and schedule the sends. Nothing activates until you approve the templates and the journey logic.
Disengagement is detected
AI colleagues watch engagement and usage signals for contacts going quiet. When a contact turns at-risk or lapses, a targeted recovery journey triggers — the stages under-resourced teams routinely skip while onboarding absorbs their time.
A change goes for approval
A new template or a material change to journey logic is routed to the accountable human owner. You approve or reject it before deployment. Approved changes deploy, and each resulting send is written to the audit trail.
Timing and variants iterate
Within approved templates, AI colleagues test send timing and content variants against observed engagement across many journeys. Non-material optimisations apply continuously; anything that alters approved logic is surfaced for your sign-off rather than applied silently.
What each module operates
Each module acts on a specific object in the product and states plainly what the AI colleagues do and what a human approves.
Journey Designer
AI colleagues build behaviour-based trigger and sequencing logic across the full lifecycle, moving programmes off fixed time schedules onto product-usage signals. You see each Journey and approve its logic before any material change goes live.
Message Studio
Each Template holds the copy for one channel and lifecycle stage, versioned so you can see what changed between revisions. AI colleagues produce the drafts and alternate variants; nothing deploys until you approve the wording under your brand.
Segmentation & Targeting
AI colleagues segment Contacts using upstream acquisition and product-usage data. Segments feed trigger logic, while each contact's Consent Record governs whether they are eligible to receive a send at all.
Consent & Suppression Gate
Suppression, consent state and unsubscribe are enforced as a deterministic constraint checked before every Send — no model judgement can override it. Advertising and data-protection decisions stay with the human owner.
The architecture, and its boundaries
How the AI colleagues run
AI colleagues operate continuously and at low marginal cost across many journeys and many accounts. They carry out the ongoing operating work: drafting and revising copy, building and maintaining trigger and sequencing logic, segmenting contacts, scheduling sends, and iterating on timing and variant performance against engagement signals.
The service takes upstream acquisition and product-usage data as its inputs and attaches to your existing CRM and email tooling as the system of record — it does not replace them. Autonomy is bounded by design rather than assumed: each account runs inside configured constraints and a set of defined human control points.
Where the human owner stays in control
An accountable human approves messaging templates, consent-handling rules, and any material change to journey logic before it goes live. AI colleagues may iterate on non-material optimisations — send timing and content variants within approved templates and logic — but cannot alter approved journey logic or consent rules without sign-off.
Brand, budget, and advertising and data-protection compliance decisions remain human-owned. The owner holds fiduciary accountability and keeps an auditable basis for oversight through the send-level record.
What is enforced, and where
Suppression, consent state and unsubscribe are enforced as configured constraints checked before each send, rather than left to discretion. The service is built for consent-governed, owned-channel messaging and does not undertake paid acquisition. Operating from DIFC aligns it with a common-law data-protection posture appropriate to this context. Every send is recorded with a full account of what was sent to whom and why, so regulated communication can be reviewed after the fact rather than reconstructed from memory.
Where the product is heading
This is direction, not a promise. In the first months the focus is a small cohort of design-partner clients running live onboarding, activation and initial recovery journeys, validating that AI-operated delivery under human governance matches a human specialist's output.
Over the following year, coverage extends across the full lifecycle — onboarding, activation, at-risk, win-back and expansion — with maturing segmentation and continuous iteration across multiple accounts, and consent and audit controls hardened for the primary market. Further out, the service runs many journeys across a growing client base on a repeatable onboarding and governance playbook, with geographic sequencing toward Europe subject to verification.
Product questions
What operators ask before starting
What does the service connect to in our existing stack?
It attaches to your existing CRM and email tooling as the system of record, and depends on your upstream acquisition and product-usage data as inputs. Journeys run across email and in-product channels. SMS, push and paid acquisition are outside the current scope.
What data do the AI colleagues process?
Contact records, consent state, and product-usage and engagement signals — used to segment contacts, decide eligibility and time sends. Each send is logged with what was sent, to whom, and why, so processing is reviewable rather than opaque.
Who can approve templates and journey changes?
A named human owner holds the approval role. AI colleagues draft copy, build triggers and iterate on timing; the owner approves templates, consent-handling rules and any material change to journey logic before it goes live.
What happens in the first days of an engagement?
We connect to your tooling, define an initial set of journeys — onboarding, activation and at least one at-risk or win-back journey — and route templates and consent rules to your owner for approval. Once approved, the journeys go live with the audit trail running.
How much of the setup and approval work lands on us?
AI colleagues do the building — drafting copy, constructing triggers and segmenting contacts. Your recurring effort is bounded to the defined control points: approving templates, consent rules and material journey changes. Routine iteration inside approved logic proceeds without further sign-off.
See a journey operate on your own stack
Bring one lifecycle stage and your existing tooling. We will walk through how it would run under your approval.