The customer has bought. A few hours later, an email asks, “Did you leave something in your basket?” They report a late delivery; the next message invites another order. Technically, the automation works exactly as configured. The problem is what the rules overlooked.
An automated flow applies rules to data and events. If the event is incomplete, delayed or misinterpreted, the message may be inappropriate even if its text is good.
The question is not just what starts an automation, but what should stop it or change its course.
From calendar to situation
“Send three days after the order” is a timing rule. “Send after confirmed delivery, if the message is appropriate and its conditions are met” is a rule built around the customer’s experience.
The second approach needs more than better wording.
- Is delivery status reliable?
- When does it reach the system?
- What counts as an exception?
If the data cannot support that logic, choose a message consistent with what is known.
Do not say “Now that you have received the product” based only on an estimated date. You can communicate helpfully without inventing an order status.
What types of flows can make sense
| Situation | Possible role | Question before implementation |
|---|---|---|
| Confirmed entry | Orientation and clear expectations | What did the person ask for? |
| Unfinished commercial action | Help to continue the journey | Do we know they have not completed it elsewhere? |
| First experience | Help with using the product | What real status can we use? |
| Repeated-use product | Relevant reminder | Is there a basis for the chosen interval? |
| Relevant inactivity | A possible reintroduction of the offer | Is the inactivity unusual for the category? |
The table describes directions; it does not recommend activating every flow. Some businesses first need to fix their confirmation and service messages.
What to check before sending
An event can make someone eligible for consideration. Before sending, check the applicable rules: permissions, preferences, commercial status, previous messages and reasons to stop.
Data can change during the wait. A new order may make a reminder irrelevant. Apply unsubscribe choices according to the message’s purpose. A failed synchronization should not be treated as proof that every condition is satisfied.
What should we check before sending?
The initial event does not replace the current status check.
ELIGIBILITY
Scope, preferences and applicable conditions.
CURRENT STATE
Order, delivery, return or unresolved issue.
COORDINATION
Messages already sent and other active flows.
DECISION
Send, delay, stop or ask someone to intervene, according to the agreed rules.
Illustrative framework. Application depends on the project’s context and data.
For commercial messages, the legal basis and contact rules must be set before activation. An abandoned-basket automation is not exempt from marketing rules just because someone acted on the website.
An example where the sequence changes the experience
Take a fictional appliance store. A customer buys a device and, after delivery, could receive a user guide. Later, there may be a communication about compatible accessories, if justified and allowed.
Between those two moments, however, the product is returned. If the marketing platform learns about it, the accessories offer can be stopped. If the status never arrives or is not part of the rules, the flow continues as if nothing had changed.
| New event | Question for the flow |
|---|---|
| Delivery is delayed | Does the message assume the customer has received the product? |
| Complaint or support request | Is commercial communication appropriate now? |
| Order is canceled or returned | Is the related product still relevant? |
| Marketing preference changes | Was eligibility updated before sending? |
Not every support request should block all communication. The rule depends on the type of situation and the role of the message. A message needed to solve the problem has a different priority from a promotion.
Several flows can speak at once
In one week, someone may receive the newsletter, a welcome sequence and post-purchase emails. Each can look reasonable alone while the combined experience feels overwhelming or contradictory.
We set priorities, frequency limits where systems allow them, and rules for overlaps. We do not promise perfect coordination across all services if the integration cannot support it. We check concretely what information flows between ecommerce, CRM, email and advertising.
Messages do not have the same priority.
Example of questions for an order with a delivery problem.
ESSENTIAL INFORMATION
What does the customer need to know about the order?
RESOLUTION
What message helps the customer get support?
PROMOTION
Is the additional offer suitable now?
Fictional example, not NOT MORE. results or forecasts.
What it means to test a flow
Receiving a test email is not enough. Check who enters the flow, what data is used, what stops it and what happens when an integration is delayed.
Test cases might include an order confirmed during the waiting period, a duplicate event, an unsubscribe, an unavailable product or an undeliverable address. Define the expected outcome before testing.
These checks are not technical formalities. They prevent experiences that feel careless: duplicate emails, incompatible recommendations or offers sent after someone asks marketing to stop.
Who maintains automation after launch
Catalogs, products, forms and commercial policies change. A workflow that was correct at launch can become wrong if nobody reviews what it depends on.
We establish responsibilities for data, content and operation. We need a way to observe errors and stop or correct communication when the situation requires it. Automation reduces certain repetitive operations, but introduces design and maintenance work.
A platform can attribute revenue to a flow without showing that the flow caused all those purchases. We compare the result with the costs, relevance and effects on experience.
How we work at NOT MORE.
We start from the customer’s journey and the reliable information we have. We choose the automations that can help, define the rules and messages, then check how they behave in normal situations and important exceptions.
Sometimes a simple workflow supported by reliable data is best. Other situations need broader integration. Strategy defines the purpose; implementation has to make it work in real conditions.
Who receives the alert and can stop the workflow
A useful automation needs rules for checking it. NOT MORE. can implement the integration, conditions and alerts, then test the agreed situations. The client validates commercial rules and names the person who can investigate a real case, correct information or temporarily stop communication.
We document what happens when a status is missing, two systems disagree or an action fails. Monitoring has a frequency, an owner and an escalation process. In ongoing work, observations lead to adjustments and reporting that shows both what is working and what remains unresolved.