Choose one journey.
“Improve our follow-up” is a direction, but it is not yet a workflow. Start with a specific journey: an enquiry arriving through a website form, a conversation that needs a next step, or a booking that needs preparation.
Write down where that journey begins and what a useful end state looks like. Keep the first scope small enough that your team can explain it without opening the software.
Define exactly what starts it.
Name the event that should start the workflow and any conditions that make a contact eligible. Think about whether the same person could trigger it twice, and whether an existing customer needs a different route.
A new enquiry arrives through a particular form. The workflow assigns an owner and creates a follow-up task. An enquiry from someone already in an active conversation may need to go to their existing owner instead.
Give the next step an owner.
For each step, record the action, its purpose and who is responsible. A message, a task and a pipeline update do different jobs. Choose the action because it helps the customer or the team—not simply because it is available.
Make the handover to a person explicit. Who sees the task? What information do they need? How will they know whether the customer has already replied or booked?
Plan how the sequence changes.
A customer journey rarely follows one straight line. Decide what should happen when someone replies, books, asks for a different next step, submits the form again or becomes ineligible for the sequence.
Record the stopping conditions alongside the starting conditions. If a workflow sends messages, include the permissions, customer preferences and relevant platform requirements in the implementation review.
Work through one enquiry.
Imagine a service business receiving a new website enquiry. The aim is to acknowledge an eligible enquiry, give a person responsibility and avoid chasing someone who has already replied or booked. This is a fictional planning example, not a client result or a tested account configuration.
Starts: an enquiry through one agreed form. Owner: the assigned enquiry handler. Limit: one acknowledgement and, if still appropriate, one reminder. Ends: a reply, an applicable booking, loss of eligibility or a handover after the reminder limit.
- Identify the enquiry. Check the submitted details and match the contact using the agreed rules. Keep the enquiry event distinct from the contact record: recognising the person does not by itself decide whether a new follow-up sequence should run.
- Assign responsibility. Give the enquiry an owner and a clear next task. An existing conversation should reach the person handling it instead of starting an overlapping chase. Missing details or unclear eligibility go for human review.
- Acknowledge when appropriate. Send the agreed message only when the contact, channel and communication requirements permit it. Record the intended outcome of that message; a recorded send alone does not establish that the customer received it.
- Check again before the reminder. After the agreed interval, check the latest reply, booking and eligibility state. Send the single planned reminder only if the enquiry still qualifies. Timing and working hours need to be agreed for the actual business.
- Give changed circumstances their own path. A reply should reach the responsible person with context. An applicable booking should end obsolete requests to book and move into the agreed appointment process. Appointment confirmations or reminders may still be appropriate; stopping this enquiry sequence does not mean stopping all communication.
- Finish at the limit. If there is still no response after the planned reminder period, end this sequence and create or update the owner's review task. Further outreach is a separate decision, not an endless loop.
This brief describes the behaviour to build. It does not establish that one software switch handles every path. In GoHighLevel, Stop on Response applies to a reply to a message from that workflow. If it ends that run, do not rely on a later action in the same stopped run to notify the owner. Confirm the handover separately.
Booking exits also need the relevant calendar and status rules, plus a way to stop the particular sequence that has become obsolete. HighLevel documents both the Appointment Status trigger and Remove from Workflow action. Check the actual account and connected tools before choosing the implementation.
Write the test scenarios before the build.
Turn the plan into a short set of scenarios with an expected result. This helps the person building the workflow and the person reviewing it agree on what “working” means.
- A new enquiry follows the intended path.
- An existing contact is matched and handled appropriately.
- A repeated event does not create unintended duplicate actions.
- A reply or booking changes the sequence as intended.
- Missing information or a failed connection becomes visible to the right person.
| Scenario | Expected result to verify |
|---|---|
| New eligible enquiry | The correct contact and enquiry are recorded, an owner is assigned and the agreed acknowledgement reaches the controlled test destination. |
| Repeat submission or existing conversation | The matching and entry rules prevent unintended duplicate messages and preserve the appropriate owner. Contact matching and workflow entry are checked separately. |
| Reply before the reminder | The obsolete reminder is withheld and the owner receives the conversation context. Test each reply channel included in scope. |
| Booking without a reply | An applicable booking ends the request-to-book sequence. The agreed appointment handling remains active. |
| Booking changes | A cancellation or reschedule updates the intended next step. Check that outdated reminders are removed or revised as designed. |
| Missing information or changed eligibility | Affected outreach is withheld and the owner can identify what needs review before any resumption. |
| No response through the limit | Only the agreed acknowledgement and one reminder are attempted. The sequence ends and the owner's review task is visible. |
| Failed action or interrupted update | The designated person can detect the failure and follow the agreed recovery process without blindly repeating a message. |
These are expected results, not completed tests. Use controlled contacts and destinations, agree when sending may be enabled, and record the actual result and evidence for each scenario. HighLevel notes limitations in its Test Workflow control; inspect the relevant execution records, contact changes and message outcomes as well.
Put the essentials on one page.
Your first brief can be simple. Give the team a shared answer to these questions:
- Purpose: What problem should this journey solve?
- Start: Which event and conditions begin it?
- Steps: What happens next, and why?
- Ownership: Where does a person take responsibility?
- Exceptions: What changes or stops the sequence?
- Checks: Which scenarios demonstrate that it works?
- Aftercare: Who checks failures and maintains it when the process changes?
With that brief in place, it becomes easier to discuss the scope of the configuration and the questions that still need an answer.