Both current flows, piece by piece. A single lifecycle across three routes, with the event logic that fires it. And how I would measure whether it works in revenue, not in opens.
00 · Thesis
Both flows are built on the day of the cycle: the Pro gets the third message because three days have passed, not because they did or failed to do something. That is where the duplicate pieces come from, the ones that contradict each other, and the claims about their visibility the product has not yet delivered.
The proposal swaps the calendar for a state machine. The Pro moves through observable milestones, and time only serves to rescue when a milestone does not arrive.
Launch priority: orchestrate the first enquiry within minutes; verify the Pro's real state before making any claim; and close the trial with a transparent value recap, measured against a persistent holdout.
Seven sends in ten days to Pros who sign up and do not start the trial. In six of the seven I find something the Pro can notice.
It is better built than A: three welcome variants, genuinely segmented. Where I see the problem is the moment that decides the subscription, which it reaches late.
Piece-by-piece audit: 7 sends, 27 observations and the original screenshots.
← → to move between pieces
Piece-by-piece audit: 6 sends, 23 observations and the original screenshots.
← → to move between pieces
Today, what goes out is decided by the day of the cycle. In the proposal it is decided by where the Pro sits in the milestone chain. The three routes share attributes, suppression and channel priority, and a Pro is only ever in one.
They saw the trial offer at signup and did not take it. Repeating it unchanged adds nothing; what is needed is an answer to the doubt that stopped them.
Profile ready → impressions → enquiry → reply. Each message pushes the link that Pro is missing, not the next one on the calendar.
It does not exist today. It is where month two renewal is decided, and where failed payments sit unrecovered.
A note on trial_eligible, which lives in the rules rather than in the routes. It is not a segment: on a new signup it is almost always true, and the only reason that applies to someone who has just signed up is their category not offering a trial — that variant changes the ask inside Route 1, it does not create a route. Where the flag does matter is later, so a trial that has already been spent is never offered again. Confirmed
Three routes. A Pro is only ever in one. Each route reads left to right, and above every step is what fires it. Click any piece to see the mockup, its entry and exit conditions, and what it suppresses while it is active. Every one of those conditions is an event or an attribute that has to exist: checking which ones already do is the first task in the role.
They saw the trial offer at signup and did not take it.
trial_eligible AND NOT trial_startedIf their category offers no trial, it is the same route with a different ask: direct plan fit instead of activating the trial. That variant is flagged, not built.
Has full access and a card already on file.
trial_started = trueThe card has been charged; the goal is no longer conversion.
subscription_activeEach state answers one question: what is stopping this Pro from reaching the next milestone. And it declares its entry, its exit, what it suppresses and which KPI it moves.
The rule that changes the system: an event in the chain cancels any time-based message chasing that same milestone. That is where most of the current repetition disappears.
Every entry and exit condition in the flow rests on one of these. The certainty column is what separates a proposal from a plan: 12 are already used by the current flow, 2 are confirmed in the documentation, and 17 I need without knowing whether they exist. That last group is the instrumentation audit, and it is why that is the first task in the role.
A message goes out for one of two reasons: the Pro has done something, or has not done it in time.
HIGH PRIORITY · SECONDS
Product emits the event, the Pro's state is recalculated and, if it passes suppression, frequency and consent, it goes out on the channel the action calls for: push if it is immediate, email if it needs context, SMS only as a consented fallback. Content is resolved at send time, not pre-composed.
LOW PRIORITY · RESCUE ONLY · CANCELLABLE
Every milestone in the chain has a window; if the milestone does not arrive, a rescue goes out. The specific windows sit on each arrow of the proposed flow, and they all share one rule: the moment the real event happens, the pending rescue is cancelled.
Today there is one suppression rule across the whole programme. Without this layer, an incoming enquiry competes with the onboarding messages themselves.
It is the contract between CRM and Product. Without it, the state machine stays a diagram.
Two moments need it: before the trial, when the profile cannot compete yet, and when the Pro appears in searches but nobody picks them. In both, the rule is to ask for the first thing missing from this list, and only that one, until its exit condition is met.
Why not `profile_score < 70`. An aggregate score does not tell a Pro with no reviews apart from one with no pricing. Those are two different blockers, with two different actions and two different resolution times. And a threshold of 70 would be a made-up number: there is nothing behind it. Inference
And the order is a proposal, not a finding. It would need agreeing with Product — who already have the analysis: the Bark Assistant reads the profile and says what to improve. The sensible thing is to lean on that engine.
It joins monetisation and retention in one number. It stops us celebrating a conversion that cancels before the second charge, which is exactly the risk when the subscription activates on its own.
If Finance has margin by plan, use contribution instead of gross revenue. Inference
Paid conversion is automatic unless the Pro cancels, so trial-to-paid alone mixes inertia, product and CRM. What genuinely informs is how many Pros reach value during the trial.
The ones that explain the main metric
Vanity metrics. Opens, clicks, deliveries, SMS cost — They tell you why a metric is not moving. They are never the result.
«If trial-to-paid goes up, how do you know it was the CRM?»
By comparing the Pros who received the new flow against the holdout, on the metric fixed up front. If the difference survives the first renewal and the limits do not get worse, it was the CRM.
First what costs credibility, then what adds conversion, then optimisation. Foundation holds whatever blocks everything else if it is missing.
Items marked 2 WEEKS are what I would launch in the first two weeks. What I would not build yet: incentives as a blanket layer, founder offers, predictive scoring or twenty journeys — until a diagnosed friction and the data justify them.
Three uses of AI in real CRM work. The first produced this document; the other two are shown running.
Two models with me in between. Neither decides alone.
What today is days of back-and-forth before anything is visible.
From the approved design to the dynamic template, with no rework loop with development.
MARIO CALVO · SENIOR CRM MANAGER · BARK POLARIS PRO
