Day 7, and nothing has arrived
Suppose a small design studio marks a client as won on a Monday morning. Within the hour, the welcome email goes out with the link for the kickoff call. Two days later, a second email asks for logins, brand assets and the billing address. The client goes quiet. On day 7, a third email asks how the start has felt. Nothing has started, because the studio is still waiting for the logins.
Workflow 02.05, the bonus workflow in The Automation Vault, behaves exactly like that with its default settings. So at which point does it wait for an answer? At none. The file reads no inbox, contains no Wait node and has no column for what the client sent back. It waits for the calendar and for nothing else.
What makes it a chain
A checklist depends on somebody remembering to look at it. Workflow 02.05 keeps its position in three columns on the client's row in the Leads sheet: onboardingStep, onboardingStartedAt and lastOnboardingAt. During working hours on weekdays, an hourly schedule reads the sheet. The code node Which Step Is Due? decides for each row whether a step is due. Then the model writes the email, Gmail sends it, the row is updated and Slack gets a note.
The default timetable has four stages, counted in days from the start:
- Day 0: welcome, with the booking link.
- Day 2: what I need from you, taken from a configured list.
- Day 7: first check-in.
- Day 21: settling in, with a request for feedback.
The handover is a status change. A row enters when its status is won, client or signed. The same change takes it out of the follow-up sequence in 02.04, which accepts only new, replied and contacted.
The line that does the waiting
All the waiting comes down to one line in the gate: if (days < target) continue;. Here, days counts from onboardingStartedAt, and target is the day of the next stage. These are fixed dates from one starting point. In 02.04, each gap restarts after the latest contact.
Two other rules can hold a row back. A row gets at most one step per day, whatever the hourly schedule does. And any status outside the accepted three stops it at the next run. That status is the only route by which a client's answer can affect the chain, and a person has to change it.
A pause does not stop the clock
Setting a row to paused works as a stop, but the day count keeps running from the original start. Take a client with two steps sent who goes back to won on day 25. The next run sends the first check-in, because day 7 has long passed. On the following working day, the settling-in note goes out, because day 21 has passed too. Two emails designed to be two weeks apart arrive a day apart. Before resuming, move onboardingStartedAt forward by the length of the pause.
Three other ways it goes wrong
The safety catch has a purpose. A row can start a sequence only if lastContact, or failing that receivedAt, is no more than startWithinDays old, 14 by default. Without that, the first run would email every client ever won. But changing a status by hand does not touch lastContact. A lead who signs after 15 quiet days gets no welcome email, and nothing tells the owner.
The sticky note contains a related error. It says that someone who was never a lead needs only a row with name, email and status won. With neither date present, the code falls back to the year 1970 and skips the row on every run. What works is the override from the same note: put today's date in onboardingStartedAt.
The third failure is a repeated email. The row is updated only after Gmail has sent. If that update fails, the unchanged row is due again at the next hourly run, and the client can get the same email again. Point the workflow's error setting at the error handler before activating it, so the first failure reaches a person.
Where the wait belongs
The chain needs one real wait, between day 2 and day 7. The welcome and the request are safe on a timetable. The check-in makes sense only once the client has had a chance to start. This repair is my proposal. It is not in the shipped file and has not been tested:
- Add a column
materialsReceivedAtto the Leads sheet. - Add
if (sent === 2 && !r.materialsReceivedAt) continue;to the gate, after the line that setssent. - Have a person enter the date once the items have arrived.
- Send a Slack warning when a row has been held for too long, so the hold does not become a silent stop.
Why a person, when n8n could watch the inbox? The Gmail Trigger can filter by sender, so it would notice a reply. But “which logins do you mean?” is a reply too. A reply shows that the client wrote back, not that the items arrived. Let the trigger notify the owner, and let the owner set the date.
n8n also has a Wait node that can resume on a webhook call or a submitted form, with an optional time limit. It suits a form the client fills in, because a submission records something specific. The trade-off is where the state lives. A paused execution is not a cell the owner can see and correct in the sheet.
Where this does not fit
If your onboarding has real dependencies, such as several people, contracts or tasks that depend on other tasks, a project tool will model them better than a sheet with a counter. If each new client is worth a personal call, four generated emails may be the wrong tone altogether. The chain suits a repeatable service where a late or slightly mistimed email costs little.
The workflow has been checked against a real n8n installation. It has not run end to end with real Google Sheets, OpenAI, Gmail and Slack accounts. The behaviour described here comes from reading the file, not from a live run.
What the chain does well is remember. Once a row is in, no step depends on somebody having time that week. What it cannot do is notice that the client has gone silent. That part stays with a person until somebody builds the wait.
Sources
- Workflow 02.05 Client Onboarding Sequence, The Automation Vault
- n8n Wait node documentation
- n8n Gmail Trigger documentation