Leea, an author-led practice.
I help CRM and Lifecycle teams identify a critical journey transition, organize the evidence and leave with a measurable intervention.
Author-led practice applying AI to CRM and Lifecycle. AI organizes the evidence, the decision is mine.
Synthetic demonstration
This demonstration shows how I propose organizing a trajectory. Each row is a period with a start, an end and a state. The data is synthetic.
| cliente_id | estado | inicio | fim |
|---|---|---|---|
| 1001 | trial | 2024-01-05 | 2024-02-04 |
| 1001 | ativo_basic | 2024-02-05 | 2024-07-31 |
| 1001 | ativo_pro | 2024-08-01 | 2024-11-15 |
| 1001 | churned | 2024-11-16 | 2024-12-31 |
Read out loud: customer 1001 trialled for a month, became a paying basic user, upgraded to pro in August, and cancelled on November 16. The monthly report says one thing: churn in November. The table says the customer upgraded 107 days before leaving, and that is where the question lives.
All example data on this page is synthetic, created for demonstration.
The problem
Every month, one number summarizes customer loss. A 3% churn, for instance. That number does not say when inside the month the loss happened, or what changed before it.
One number per month. No time inside the month, no state, no language. The same rate can hide a customer who canceled yesterday and another who had already gone quiet weeks earlier.
The same aggregate rate can come from very different trajectories. See three illustrative clients in the same window.
The turn
The Trajectory Architecture reconstructs the customer's relationship with the brand over time. The result is a State Map: where the customer is now, and where it can go. Click each state.
Customer with recent behavior consistent with the journey's healthy pattern: frequent interactions, response to stimuli, language of continuity.
Signs of behavioral and language decline appear before formal cancellation: lower frequency, shorter responses, absence of continuity mentions.
No interaction within the window defined by the problem contract. Not confirmed churn yet. It is a state that can reverse or consolidate as a loss.
Customer that resumed the healthy behavior pattern after a period of risk or dormancy. Recovery also has a state. It is not a single point.
Drag the control. Above, the synthetic trajectory changes state across twelve weeks. Below, the illustrative rule recalculates the criteria and shows when a hypothesis should move to human review.
In this simulation, the rule is evaluated weekly. Three criteria, all of them must be met.
SE dias_sem_uso >= 14
E mencoes_continuidade_30d = 0
E queda_frequencia >= 40%
ENTAO especificar('hipotese_recuperacao')The 14-day cutoff is illustrative. In a real diagnostic, any threshold would need to come from the available history, be documented and pass human validation.
The method
Sulco is the methodology. These are the terms it uses to name each part of the work.
Meaning Reading→ Journey Time Reading→ CRM Decision→ Intervention→ Measurement
Methodology for reading meaning, trajectory and CRM intervention.
Data infrastructure: states, events, exposures, transitions.
Logic for the time based reconstruction of the customer's relationship with the brand.
How the customer moves through the stages of the journey.
Actionable hypothesis about the moment a change in language precedes a change in behavior.
Recurring cycle of testing, measurement, assumption review and model updates.
The operating framework
Each step produces a verifiable artifact. Open each one to see what comes out of it.
Defines the exact retention problem: population, time window, constraints, success criteria.
Gathers the brand corpus (campaigns, emails, surveys, support) and the data contract. Maps voice rules and brand protection limits: what the brand does not allow an AI to generate.
Time based reconstruction of customer data. Structures behavior into continuous episodes, with start date, end date and a censoring indicator: what separates a customer still active at the end of the window from real churn.
Crosses behavioral variation with language change. Formulates the Turning Points.
Specifies the CRM intervention: treatment versus control group, eligibility rules, channels, message. Human approval and controlled execution.
Demonstration architecture
This excerpt documents one possible architecture. It is not in production. AI agents would read, classify and write a specification; any implementation or send would depend on the client and human approval.
One query sweeps the CRM history and turns loose events into episode rows, with a start, an end and a state. It is the four row table from above, run over the whole base.
in eventos_crm out episodios.csv
In the proposed architecture, a trigger would schedule the query and deliver the result to the agent. This flow is a specification, not an executed integration.
in cron 0 7 * * 1 out payload json
This is where the agents come in, and there are two. leea_sentido reads the text of the customer's last contact and decides whether there is a continuity mention, which is what code does not do well. leea_retem takes that classification, joins it with the numbers and applies the cutoff. The arithmetic itself stays in code, not in the model. The one calling both in the right order is leea_maestro.
in episodios + texto out intervention_spec.json
The proposed specification includes audience, copy, control, risks and acceptance criteria. Without human review, no recommendation moves to implementation.
in intervention_spec out approved or returned
The diagnostic defines how to preserve control, record exposure and compare populations. Implementation and sending are outside the offer.
in approved journey out measurement_record
In the hypothesis, agents support reading and documentation. They do not set thresholds, send campaigns or approve actions. Code calculates; people decide.
How the work gets done
The demonstration architecture separates eight narrow roles and one orchestrator. They document how the reading could be divided, with a human gate and explicit limits.
I do not sell AI agents or production operations. These roles are documented prototypes used to explain an architectural hypothesis.
Defines analytical intelligence, interpretation of meaning and trajectory reading.
Represents how a workflow could organize evidence and prepare specifications.
Runs the calculations, consolidates history and processes metrics.
Defines what the brand can test, protect and put live.
Describes which role would be called, in what order and with which data. The specification maintains state, avoids write conflicts and includes a human gate.
configures: execution order, approval gates and reprocessing limitsThe planner. Takes a vague request and returns a scoped problem: which population, which transition, which window, and what counts as success.
Differentiator: sets the success criterion before seeing the data, so the metric that looks good afterwards is not the one chosen
The one that cleans. Removes duplicates, fixes broken dates, flags invalid contacts and separates who was still active at the end of the window from who actually left.
Differentiator: censoring rule, which is what stops counting as churn someone whose term simply had not ended yet
The builder. Turns loose events into episodes with a start, an end and a state. It builds the table you saw above, for the whole base.
Differentiator: a state grammar specific to each brand, because "active" does not mean the same thing in subscription and in education
The language and semiotics reading. It reads what the customer wrote in support, in surveys and in campaign replies, and classifies what is a continuity signal and what is an exit signal.
Differentiator: brand lexicon and protection limits, what the brand will not let an AI write in its name
The pattern catcher. Looks at the whole base and finds repeating trajectories, groups that behave alike and the point in time where behavior turns.
Differentiator: pattern capture crossing behavior with language, not just with usage counts
Retention. This is the role illustrated in the panel. It would evaluate criteria and recommend when a hypothesis should move to human review.
Differentiator: threshold set from the base's own history, not from an industry benchmark
The one that grows. It works the other side of the same reading: where the customer is ready to upgrade, buy again or refer, and when to speak without getting in the way.
Differentiator: opportunity window with a frequency cap, so growth does not cannibalize retention
The one that improves. Compares who received it against the control group, says whether the rule held up, and returns the corrected cutoff to the earlier agents. It is what closes the loop.
Differentiator: recalibrates against a control group and also records what was discarded, not only what worked
In the proposed architecture, learning would return to planning and the retention hypothesis. This illustrates the need for recalibration, not a recurring Leea offer.
The demonstration makes dependencies and controls visible. It does not prove an implemented chain or end-to-end operation.
The LLM interprets and coordinates. The code calculates. The connector prepares. The human decides and approves irreversible action.
Evidence and limits
My demonstrated experience in CRM, Lifecycle, automation, governance and measurement.
View storiesProduct semiotics applied to email and landing pages, inside a full orchestration plan. It is not a Leea delivery.
View Fênix caseData reading and consumer psychology applied to experience. An RFM score, stage-based offers and surveys took a party from 300 to 500 to 2,000 to 3,000 attendees per edition.
View storiesLanguage used to read the brand. The institutional agenda becomes segmentation, journey and nurturing. Documented strategy, not production execution.
View caseLanguage used to design prospecting. A social project becomes an acquisition channel, with the invited guest as the high value lead. Documented strategy, not production execution.
View caseTables, maps and rules illustrate the hypothesis with synthetic data. They are not client results.
View demonstrationLeea is a retention study that reads the signals preceding the decision to cancel across four layers: behavior, brand voice, semiotics and time spent in each journey state.
The complete authorial case is currently available in Portuguese only.Prefer anonymized CSV files, client-run queries, examples without PII, a data dictionary and read-only access only when essential and approved.
Fit
The team feels something changed (activation, risk, retention, reactivation or expansion) only after the KPI has already moved. The diagnostic locates the transition, gathers the signals that support the hypothesis and defines how to measure the next test.
If this describes the team, the conversation starts with a transition.
How I work
This is how I move when I join a CRM operation. Within ten business days, with the right data in hand, I already have a journey mapped, a transition identified and an intervention ready to test.
That ends with one documented decision:
Journey, population, states, observable change, decision at stake, inclusions, exclusions and limitations.
Events, timestamps, messages, current rules, sources, gaps and reading limits.
Audience, channel, entry condition, proposed rule, human control, risks and acceptance.
Events, properties, baseline, denominators, population, window, comparison, causal limits, success and guardrails.
What to test, instrument or leave unautomated, with dependencies, owners, open issues and prioritization.
Next step
Describe the journey at stake, what changed and which data already exists. I will respond if the diagnostic fits the scope.