Automating commercial actions from performance segmentation
A fictional automation case: translating a classification into follow-up without duplicates and without orphans.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01The outcome
For every eligible account, exactly the actions its current segment requires; for every exit, the old actions closed with a reason.
A segment change creates tasks and campaign memberships—but nothing removes them when the account recovers or leaves the population.
How does a segment become exactly the right actions—and stop being them when it changes?
Drive entries and exits from one action matrix, keyed per account, segment and entry period, with eligibility re-checked when the action runs.
Accounts are classified monthly as On Track, Underperforming, At Risk or No Sale. Each segment should drive different follow-up: campaign membership, a task for the owner, a required recovery plan, a notification. The first version reacted to the segment field with a trigger that created actions—and never removed any.
A new segment version is published for an account.
- Actions for the current segment exist exactly once
- Actions for the previous segment are closed or exited
- The owner is notified once
- Differences are visible to a reconciler
02The reality · current state
What the automation does today.
- Accounts that recovered still receive At Risk campaigns
- A rerun of the segmentation creates a second task
- Accounts that left the population keep open recovery plans
- Tasks are created for accounts without an active owner
- Nobody can say whether actions match the current segments
03Target steps
Each step with its mode, its actor and its guard.
- 01Segment updated
A new version arrives with previous and current segment.
- 02Eligibility check
Active account, active owner, not excluded.
- 03Campaign membership
Enter the current segment’s campaign; exit the previous one.
- 04Task generation
One task for the owner when the segment requires one.
- 05Recovery plan requirement
At Risk requires a plan; the owner writes it.
- 06Owner notification
One summary per owner per run, not one per record.
04Key dimension · Entries, exits & deduplicated actions
One action matrix—entries and exits
What each segment requires, read row by row. The exit rules matter as much as the entries.
| Segment | Campaign | Owner task | Recovery plan | Notification |
|---|---|---|---|---|
| On Track | Nurture | None | None | None |
| Underperforming | Growth offer | Review call | None | In weekly summary |
| At Risk | Retention | Recovery call | Required | Immediate |
| No Sale | Reactivation | Reactivation task | None | In weekly summary |
| Not eligible | Exit all | Close open | Close with reason | None |
- At Risk → On Track
Exit retention campaign; close recovery task as “recovered”; plan archived
- Any → Not eligible
Exit every campaign; close open tasks as “no longer eligible”
- Underperforming → At Risk
Close review call; create recovery call; require plan
- Same segment, next period
Nothing new: the entry period is unchanged, so the key already exists and open actions carry on
Most duplicate and orphan problems are exit problems. Design the exit column first.
05Execution safety
If it can run twice, it is designed to run twice.
Changes arrive per account, but effects must stay consistent across two systems and several runs.
- Effect key
- Account + segment + entry period
- Eligibility guard
- Checked when the action runs, not only when triggered
- Exit rule
- Leaving a segment closes its open actions with a reason
- Notification
- Batched per owner and run
- Rerun
- Same version in, no new effects out
06Exceptions & recovery
Not every failure is a retry.
- Owner inactive ConfigurationEligibility guardHolding queue for the team leadSales operations
- Campaign platform unavailable Dependency · retryConnection failuresQueue memberships; apply when backPlatform team
- Segment republished DuplicateEffect key existsNo new effectsNobody: absorbed
- Account left the population Stale stateEligibility guard or reconcilerRun the exit ruleAutomation
07The trade-offs
Credible options, judged against these premises.
Field trigger that creates actions
Entry-only, one-off actions
Cost: No exits; duplicates on rerunRecreate all actions every run
Tiny populations
Cost: Churns tasks and campaigns; loses work in progressAction matrix with keyed entries, designed exits and reconciliation
Segments that drive work
Cost: Needs a matrix owner and a reconciler08The second layer
Questions that change the design.
Change
- What happens when the segment changes?
- What happens when the account becomes ineligible?
- How are obsolete actions removed?
Safety
- Can repeated execution create duplicate tasks?
- When is eligibility checked?
- What if the campaign platform is down?
Ownership
- Who owns the exit path?
- Who owns the action matrix?
- How is downstream state reconciled?
09Decisions & outputs
What the work produces.
- 01Action matrix
- 02Eligibility guard
- 03Deduplication keys
- 04Exit logic
- 05Owner notification rule
- 06Reconciliation hook