build.allanninal.dev

Part 5 of 7 · Onboarding guide series ~5 min read

How an onboarding finishes

A flag lands in Sam’s Slack at 9:04am. Priya is stuck on the “invite a teammate” step, five days in. There are buttons on the flag. What happens when he taps one? The honest answer is “it depends on what’s actually going on.” This post walks through the three ways a sequence ends — finish, pause, hand off — and how the onboarding list, the step state, and the audit trail all stay in sync.

Key takeaways

  • Three ways a sequence ends: finish (all steps done, send a wrap-up), pause (hold without dropping), hand off (a human takes over).
  • Each action updates the onboarding sheet via the Sheets API and writes an audit row.
  • A finish archives the journey to a separate sheet for history.
  • Pause is open-ended but visible — paused customers show up in the weekly digest so none are forgotten.
  • The flag buttons are a Slack interactive message backed by a Function URL.

Three ways a sequence ends

Three ways an onboarding sequence ends A diagram showing one input on the left flowing through a small interactive Slack panel, then branching into three end paths. Far left: an "Flag in Slack DM" box showing a typical flag message — customer name, plan, the stuck step, days since signup — with three Slack-button placeholders below: Pause, Hand off, Done. The owner taps one button, or the customer finishes on their own. The middle column shows the three branches. Branch one, Finish: the customer has completed every step in the plan (or the owner marks them done); a Function URL Lambda marks the customer finished in the onboarding sheet via the Sheets API, sends one warm wrap-up email, archives the journey to a separate completed sheet, clears the live step state in the og-sends DynamoDB table, and writes a finished event to the audit trail. Branch two, Pause: opens a small Slack modal with an optional note; on save, the Function URL Lambda sets the paused flag on the customer's row so the daily tick treats them as on track and sends nothing. The sequence isn't deleted — a paused customer can be resumed later, and shows up in the weekly digest so none are forgotten. Branch three, Hand off: assigns the customer to a named human owner; the guide stops sending automated messages and the human takes the conversation from here. Useful when the customer needs a real person rather than another email. The right side shows the convergence: every action writes a row to the og-audit DynamoDB table with timestamp, customer id, action, by-user, and notes. A note at the bottom: Pause doesn't drop the customer — it holds the sequence. A paused customer can always be resumed. Flag in Slack DM name, plan, step, days [Pause] [Hand off] [Done] Action 1 Finish • All steps done or marked done by owner • Sheets API marks finished • Wrap-up sent, journey kept Action 2 Pause • Modal: optional note (why paused) • paused flag set; tick sends nothing until resumed Action 3 Hand off • Assign to a named human owner • Guide stops sending — the human takes over Audit trail DynamoDB og-audit timestamp · customer_id action · by-user notes Pause doesn’t drop the customer — it holds the sequence. A paused customer can always be resumed.
Fig 5. Three ways a sequence ends, three different effects. Finish marks the customer done and sends a wrap-up. Pause holds without dropping. Hand off lets a human take over. Every action writes to the audit trail.

Action 1: finish (the goal)

The happy path. Priya works through every step in her plan — she connects her data, invites a teammate, books the check-in — clicking the one-click done link on each as she goes. When the daily tick sees that the last step in her plan is done, it lands her at finish. Or, if a human knows she’s set even though a step is technically unmarked, the owner can tap Done on the flag to finish her manually.

Either way, the finish runs through a Function URL Lambda. Three things happen, in order. First, the Sheets API updates her row in the onboarding sheet: the finished flag is set and the finished_date is stamped with today and the user who acted. Second, her step rows in og-sends are copied to og-sends-archive with a journey id, and the live state is cleared. Third, a action: finished row is written to og-audit with the user, timestamp, and how long the whole onboarding took. One warm wrap-up email goes out — “you’re all set, here’s where to go next” — and then the guide goes quiet for her.

Tomorrow’s tick reads the list, sees she’s finished, and lands at on track with nothing to do. She won’t hear from the guide again unless someone re-enrolls her for a new plan.

Action 2: pause (the hold)

Some onboardings need to stop without the customer being done. The customer asked to be left alone for a few weeks while they finish a migration. They’re a team of one and the “invite a teammate” step will never apply. A deal is being renegotiated and nobody wants automated mail going out in the middle of it. Sam isn’t finishing Priya and isn’t handing her off — he just needs the guide to be quiet for now.

Pause opens a small modal with an optional note (“team of one, revisit after Q3”). On save, the paused flag is set on her row and a row is written to og-state. The next day’s tick reads that flag in the “paused or finished?” check from Part 3 and treats her as on track — sends nothing. Pause is open-ended; there’s no timer. But it’s not a black hole: every paused customer appears in the weekly digest with their note and how long they’ve been paused, so nobody is quietly forgotten. Resuming is one click in the sheet (clear the flag) or a button in the digest, and the guide picks the sequence back up where it left off.

Action 3: hand off (the human)

Sometimes another automated email is exactly the wrong answer and a real person is the right one. The customer is clearly confused and needs a call. They’re a big account that deserves a dedicated contact. They replied to a step email with a question the guide can’t answer. Whatever the reason, it’s time for a human to take the wheel.

Hand off assigns the customer to a named human owner — picked from a short list in the modal — and writes a row to og-state with (customer_id, handed_off_to). The guide stops sending automated messages for that customer entirely; from here the human owns the relationship. The assigned person gets a Slack ping with the full journey so far so they’re not starting cold. If the human later decides the guide should resume (the call went well, the customer just needs the rest of the sequence), they can clear the hand-off and the guide picks back up.

Hand off is the escape hatch that keeps the whole system honest: the guide is for the common path, and the moment a customer needs more than the common path, a person steps in cleanly instead of the customer getting more of the same.

Every action is logged, every action is reversible

The og-audit table records every finish, pause, and hand-off with the user who took the action, the timestamp, and a snapshot of the row before and after. If a customer gets paused by mistake, or finished a week early, a rep can run an “undo last action” through a small admin command that reads the previous-state snapshot and restores the row. The undo is itself an audit row, so the trail of edits stays clean.

This reversibility matters because onboarding is the first impression. The next time anyone looks at how a customer’s first week went — a support rep picking up a ticket, an account manager prepping a renewal — the audit trail is the memory of exactly what the customer saw and when.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go and why it’s so cheap.

All posts