All work

Customer lifecycle automation

Proving a member was really removed

Cancellations that used to say “done” without being done now prove every step before they close.

OffboardingCustomer successMakeCRMRead-back checks
Business type
Paid membership and coaching
Systems
Make, CRM, community platform, Airtable, Slack
My role
Designed, directed, verified and operated
Shown here
The method on made-up data, from a flow I rebuilt in production

01The situation

When a member cancels, four things must happen: remove community access, update the CRM, tidy the member record and send one goodbye.

The old flow marked a request “Completed” when it could not find the member in the community. A failed removal counted as a success, so some people kept access after cancelling while every dashboard looked green.

Before“not found” meant “removed”
  1. Cancel requeststaff pick the member
  2. Look upby billing email
  3. Not founddifferent login email
  4. Completedbut still has access

02What I found

  • Staff picked the member from a list, and the flow used that record’s billing email in every system. If the person joined the community with another email, the lookup found nobody.
  • “Not found” was then treated as “removed”.
  • Nothing went back to check the result.
  • I rejected adding more email fields to the form: the problem was identity, not data entry.

03What I built

  1. Each request resolves to exactly one member through the identity registry, or it is held for a person with the reason.
  2. Each step runs, then is read back from the system it changed.
  3. “Completed” is written only after every step has proved itself.
  4. A guard stops the goodbye email going out twice to the same member on the same day.
  5. The same pattern also runs a check-in reminder flow for customer success, which now finds members by ID instead of by their first email.
Afterno request closes without proof
  1. Cancel request
  2. One member?via identity registry
  3. Run and read backeach step
  4. Completedor held for staff

04How it fails safely

  • “Could not read” is never treated as “not there”.
  • A staff test run checks every path before anything goes live.
  • The upgrade went live only after it had been proven on two real requests.

05Result

What changed

  • No cancellation can close as “Completed” unless each step has been read back.
  • Requests the system cannot resolve are held and explained, not guessed.
  • Onboarding is next: the same identity check is being applied there, and is not yet live.

06Lessons

A successful run is not proof the work happened. Check the destination, not the log.
Holding a request with a clear reason is a better outcome than finishing it wrongly.

Read: A successful run is not proof

Next case studyFaster lead response, cleaner lead data

Have a system that keeps drifting?

Tell me where it breaks. I’ll tell you what I’d check first.

Get in touchWork with FlowThinkers