Module · The nineteen workflows
Booking the meeting, and chasing the no-show
Lesson 21 of 40 · 7 min
The conversation went well and somebody agreed to come in. From here on, the work is unglamorous and it is where deals are lost: getting it into a diary, reminding them, and noticing when they do not turn up.
A workflow that watches another workflow's output
5.1 · Book the visit into your calendar
A task appears. If it is the right kind of task, the contact is looked up, the meeting goes into the calendar, and the enquiry moves stage.
Scroll for all 5 steps →
Look at what starts it: a task being created. Tasks in this org are created by other workflows — the routing one, the call-back one, the WhatsApp one. So this is a workflow triggered by another workflow's work, without either of them naming the other. Same composition-by-event as The first five minutes: call-back and routing, one layer further along.
And the join between them is a phrase. This one only proceeds if the task's title contains Advisor meeting. Rename that phrase in the workflow that creates the task and this one silently stops running — no error, no failed run, just nothing. When a client asks why the calendar stopped filling up six weeks after go-live, look here first.
The stage moves whether or not the invite went out
Follow the two arms leaving the calendar node. Both of them — the one for success and the one for failure — arrive at the same box, which writes:
| Field | What it is set to |
|---|---|
stage_name | Appointment Booked |
next_step | Advisor meeting booked — invite sent |
stage_name
- What it is set to
- Appointment Booked
next_step
- What it is set to
- Advisor meeting booked — invite sent
On the failure path, that second line is not true. The calendar refused the event and the enquiry now says an invite was sent. Nobody is lying; two arms were wired to one box because it was the tidy thing to draw, and the consequence turned up three fields later.
This is the judgement a partner is actually paid for. Would you ship it? There is a defensible yes — the meeting is agreed, the stage should reflect reality, and an advisor will notice a missing invite. There is a better no: send the failure somewhere that says so. What is not defensible is not having noticed.
The one that waits
5.2 · Remind them, and chase the no-shows
Two hours before the appointment, a reminder. Four hours later, a look back at the record to see what happened — and two quite different endings.
Scroll for all 9 steps →
It starts 2 hours before the appointment, sends the reminder, then sits still for 4 hours — which is the appointment happening, or not happening. One run of this workflow spans most of a working day.
It does not remember. It looks again.
After the wait, the workflow runs a query it already had the answer to before the delay: it reads the task's status back out of the database, and forks on whether it now says completed.
That re-read is the whole trick. In the four hours it was asleep, an advisor met the customer and ticked the task. The workflow cannot know that from anything it is carrying; it can only know it by asking again. A workflow that waits and then acts on what it knew before the wait will confidently chase a customer who is sitting in reception.
The record is the state; the workflow is a visitor. Every long-running automation you ever build should re-read before it acts. This is the sentence to carry out of Module 3.
| What the record says afterwards | What happens |
|---|---|
The task was marked completed | A note goes on the contact saying they attended. Nothing else. |
| It was not | A re-book task for the advisor, and a mail to the customer offering two other times. |
The task was marked completed
- What happens
- A note goes on the contact saying they attended. Nothing else.
It was not
- What happens
- A re-book task for the advisor, and a mail to the customer offering two other times.
Read the no-show message before you demo this. It does not scold and it does not ask why. That wording is a business decision sitting in a text box, and a client will want to change it — which is exactly the kind of change they can make themselves.
Change one thing — move the two numbers
Both of these workflows encode a business's timing in two numbers, and neither number is obviously right. Argue with them.
- Open
5.2 · Remind them, and chase the no-showsand find the trigger's offset — it currently fires2 hoursbefore the appointment. - Change it to what you would recommend to a client who sees a lot of no-shows. Say your reason out loud before you save.
- Now open the delay and ask whether
4 hoursis long enough for a meeting that starts late. Change it or defend it. - Leave both workflows as drafts. This one mails real customers when it is on.
Try it
- Work out what this workflow does if the advisor forgets to tick the task until the next morning. Then decide whether that is the workflow's fault.
- Find the other workflow in your org that creates a task whose title would satisfy this one's condition. If you cannot find one, that is the finding.
Next: Two kinds of follow-up: the cadence and the written-for-one message — not everybody says yes in the first week, and the two workflows that handle the ones who go quiet are quite different from each other.