Answer first: Before automating a customer journey, define five separate records: the event that happened, the person or organization involved, the permission that applies, the work the business must perform, and the verified outcome. Then define ownership, duplicate handling, failure recovery, and audit history between them.
Imagine a hypothetical mobile notary named Dana who runs the business from home and travels to appointments. A website form sends Dana an email. A calendar tool creates an appointment. A spreadsheet receives a new row. An automated message tells the customer the request is confirmed.
Then a visitor taps Submit twice.
Dana gets two emails, two rows, and two appointments. The customer receives two confirmations. Nobody knows which record is authoritative.
The problem is not a lack of automation. The problem is that the business never defined what each system was recording.
Record one: the event
An event is a fact about something that happened at a specific time. Examples include:
- a form was submitted;
- a resource was requested;
- a booking was selected;
- a payment provider reported a completed payment;
- a customer requested cancellation;
- a staff member approved a scope;
- a delivery attempt failed.
The event record should have a stable identifier, time, type, source, related object, and processing status. It should not rely only on an email address. The same person can perform the same kind of action more than once.
A stable event identifier helps the system recognize retries. If the same event arrives again, the workflow can return the prior result instead of creating duplicate work. Stripe’s API documentation describes idempotent requests as a way to safely retry without performing the same operation twice. The general lesson applies beyond payments: retries are normal, so duplicate behavior must be designed.
Do not invent an event ID after processing. Claim it before creating downstream records.
Record two: the person or organization
A contact record represents the person or organization the business is serving. It is not the event itself.
Keep source facts separate from guesses. A contact may contain a name, reply address, company, phone number when needed, and relationship history. It should not silently treat a customer as a newsletter subscriber, assign an industry from a domain, or merge two people merely because they share an address.
For a household or small business, decide when one organization can have multiple contacts. Decide which fields can be updated automatically and which changes need review.
The contact record should answer:
- Who is this?
- How can the business respond to the requested action?
- Which tenant or business owns the relationship?
- Which source supplied each important field?
- When was it last verified?
Tenant ownership matters. A customer record from one client or brand should not appear in another client’s workflow simply because they share an automation platform.
Record three: permission and suppression
Permission is its own record because it changes independently from the contact.
A person may consent to receive a requested resource but decline a newsletter. A current client may receive necessary service messages but not unrelated promotions. A former customer may unsubscribe. A hard bounce or complaint may require suppression even if an old opt-in exists.
Record the purpose, exact wording or policy version, source, time, and current state. Suppression should win over an older positive record.
Useful states may include:
- requested service communication allowed;
- marketing consent granted;
- marketing consent declined;
- unsubscribed;
- hard bounced;
- complained;
- manual do-not-contact;
- unknown—human review required.
Do not turn “unknown” into “yes.” Do not copy consent between separate brands or customers without a valid basis.
Record four: the work item
The work item represents what the business must do. It can be a lead review, appointment, order, project, support request, delivery, approval, or follow-up task.
This is where ownership becomes visible. Every work item needs:
- a type;
- current status;
- owner or queue;
- due time when relevant;
- related contact and source event;
- scope or selected option;
- exception state;
- next allowed actions.
Do not use “sent” as the only completion state for a customer request. An email can be accepted by a mail system while the work remains undone. A green workflow node does not mean a staff member reviewed the request.
For Dana’s hypothetical notary business, the form event may create one appointment request—not a confirmed appointment. The work item becomes confirmed only after availability, location, service type, and any required payment state are verified.
Record five: the outcome
An outcome is the verified result of the journey. It may be:
- resource delivered;
- consultation confirmed;
- request declined with an alternative;
- order fulfilled;
- payment confirmed by the payment provider;
- issue resolved;
- appointment completed;
- customer canceled;
- recovery required.
Outcomes should be based on evidence from the system or human responsible for that result. The website should not show “complete” merely because it sent a request downstream.
Keep operational outcomes separate from marketing attribution. “Consultation confirmed” is a business fact. “Article caused the sale” is an analytical interpretation that may require a defined attribution method.
Define the rules between records
Once the five records exist, write the transitions.
For each transition, specify:
- Trigger: which verified event starts the action?
- Guard: what must be true before it continues?
- Mutation: which one record may change?
- Owner: who is responsible if it stops?
- Idempotency: what prevents a duplicate?
- Failure route: what happens after a temporary or permanent error?
- Evidence: what proves the action succeeded?
- Audit: what minimal history is retained?
Avoid a workflow that updates every record at once. Smaller transitions are easier to test and recover.
Design for retries, delays, and disagreement
Real systems are not perfectly synchronized. A booking may be saved while an email provider is unavailable. A payment webhook may arrive after the browser closes. A staff member may change a status while an automation is retrying.
Use bounded retries for temporary failures. Park permanent failures for review. Never erase the successful booking because the confirmation email failed.
When two updates disagree, define which source wins. A provider-confirmed payment state should not be overwritten by an old browser response. A manual suppression should not be removed by a stale import. A cancellation should stop later reminders.
Record version or update time so the system can reject stale changes rather than silently overwriting current work.
Keep private data out of general logs
Logs should help an operator answer what happened without becoming another customer database.
Record workflow ID, event ID, record ID, step, result, error category, and time. Avoid full email addresses, phone numbers, appointment notes, payment details, and form content in general logs.
Use access controls appropriate to the record. The person troubleshooting delivery may not need the full customer message. The customer should not see another customer’s status. Test those boundaries with separate synthetic tenants or accounts.
Use synthetic acceptance before real traffic
Build a small test set that includes:
- a valid new event;
- the exact same event replayed;
- two legitimate events from the same contact;
- a non-consenting resource request;
- an unsubscribe received during a queued campaign;
- a temporary provider error;
- a permanent validation error;
- a stale update;
- a cross-tenant access attempt;
- a downstream success followed by an email failure.
Verify the expected record count and state after each test. Confirm that outbound adapters are mocked or pointed only to approved internal test destinations until a real-send test is separately authorized.
Add automation only where it reduces operating work
The best first automation is often a boring handoff: create one review task, attach the right record, alert the correct owner, and show a recoverable error if it fails.
Do not automate a decision the business has not made. Do not activate every installed integration. Do not connect a payment account merely because a node exists. Saved credentials and inactive templates are configuration, not a working customer journey.
Dana can now handle the duplicate submission correctly. Both browser attempts carry the same event identifier. The first creates one appointment request. The second receives the existing result. The contact remains one person, permission remains separate, the work item has one owner, and confirmation occurs only after the appointment is verified.
Automation becomes dependable when the business can explain the records without naming the tools.
Use the platform planning guide
Turn a useful idea into a practical next step.
Use what you learned, then choose the support that fits the work ahead.
- Identify the work
Decide whether you need a new website, a focused service or ongoing support.
- Compare your options
Review scope and current charges before choosing.
- Talk through your project
Bring your website, your goal and the question you want to solve.
Older tutorials may describe earlier software or interfaces. Confirm current requirements before making changes.