Client Onboarding and Kickoff

The gap between yes and started is where professional services firms lose the most goodwill they will ever lose with a client, and it happens at the worst possible moment. The client has just decided to trust the firm. They are at their most enthusiastic and most willing to do work on their own side. What they encounter instead is two weeks of silence punctuated by scattered requests: an agreement to sign from one email, an invoice from another, a questionnaire attached to a third, a request for access to a system that arrives after someone noticed it was missing.

The reason is structural, not cultural. Onboarding is a sequence of dependencies that nobody owns. Delivery cannot start without system access; access cannot be requested until someone knows which systems are involved; that comes from the intake pack; the intake pack is not sent until the deposit clears; the deposit is not invoiced until the agreement is signed; and the agreement is chased by whoever remembers. Each handoff is a manual act performed by a busy person, so each one introduces days of latency, and the delays compound rather than overlap.

The costs are concrete. Revenue recognition slips because the engagement cannot start, which moves cash out of the quarter for reasons that have nothing to do with selling. Senior time - frequently the most expensive time in the firm - is spent chasing documents, which is both wasteful and demoralising. Scope drifts, because a kickoff held without a completed intake pack becomes a discovery session and the assumptions in the proposal go unchallenged until they surface as a change request. And the client's own impression of the firm's competence is set here, before any actual work has been seen. A firm that is disorganised in week one has to be twice as good in week six to recover the perception. Worst of all, some deals quietly die in this gap - signed, deposited, and then stalled on an unanswered request until the client's internal sponsor moves on.

Pipeline and stages

A dedicated Client Onboarding pipeline that begins where the sales pipeline ends and finishes at a formal handover. Each stage represents a dependency satisfied, not a task attempted, which is why the board can be read at a glance.

• Agreement Sent - entry stage, created automatically when the sales opportunity is marked won.
• Agreement Signed - executed copy returned and filed.
• Deposit Invoiced - invoice issued to the billing contact with any purchase order reference attached.
• Deposit Cleared - payment confirmed by the payment processor.
• Intake Pack Sent - the structured questionnaire is with the client.
• Intake Complete - every mandatory section answered.
• Kickoff Scheduled - appointment confirmed with all required attendees.
• Kickoff Held - meeting took place and notes are filed.
• Access Confirmed - every system named in the intake pack is accessible and tested.
• Onboarding Complete - formally handed to delivery. The won stage.
• Stalled - Awaiting Client - a holding stage entered automatically after a defined period of no client action, from whichever stage the card was in. The stage it came from is recorded so it returns to the right place.

Calendars

• Kickoff Call: a 60-minute collective calendar requiring both the engagement lead and the delivery owner, so a kickoff can never be booked into a slot where the person doing the work is unavailable. This is the single most valuable calendar configuration in the build.
• Technical Access Session: 30 minutes, booked with the client's IT or operations contact rather than the project sponsor, used to resolve access and credentials live. A fifteen-minute screen share resolves what three weeks of email cannot.
• Onboarding Check-In: 20 minutes, offered proactively at the midpoint if any stage has been open longer than its target, so a stall becomes a conversation rather than a chase.
• All three generate conferencing links automatically on booking and sync two-way with the team's own calendars.

Custom fields

• Engagement Type - dropdown, matching the firm's service lines. Drives which intake pack sections appear.
• Engagement Start Date - the contractual start, which is what every stall calculation is measured against.
• Agreement Sent Date and Agreement Signed Date.
• Deposit Status - dropdown: Not invoiced, Invoiced, Part paid, Cleared, Waived by agreement.
• Billing Contact Name and Billing Contact Email - captured separately from the project contact, because they are different people more often than not and sending the invoice to the sponsor is a reliable way to add ten days.
• Invoicing Requirements - dropdown: No purchase order needed, Purchase order required, Submission through client portal - and Purchase Order Number. Discovering a portal requirement after invoicing is one of the most common causes of a late first payment.
• Intake Sections Outstanding - text, written automatically as a readable list. This field is what every chase message and every BO answer reads from.
• Access Systems Required - multi-select, populated from the intake pack.
• Credentials Received - switch - and Access Tested - switch. Two fields, because received and working are not the same thing and the difference surfaces on day one of delivery.
• NDA Status and Data Processing Agreement Status - dropdowns: Not required, Sent, Signed. Kept visible so they cannot be discovered at kickoff.
• Stakeholder List - long text, from the stakeholder form.
• Kickoff Date, Delivery Owner, Client Portal Activated - switch.
• Days Since Last Client Action - number, recalculated nightly. The stall detector.
• Stall Reason - dropdown: Awaiting signature, Awaiting payment, Awaiting documents, Awaiting access, Client internal delay, Scope being revisited.

Tags

• onboarding-active - applied at creation, removed at handover. Suppresses all prospect marketing for the duration.
• awaiting-signature, awaiting-deposit, awaiting-intake, awaiting-access - exactly one of these is live at a time, so a smart list answers what is every client waiting on us or on themselves for? instantly.
• kickoff-booked and kickoff-held
• onboarding-stalled - applied automatically, removed on any client action.
• onboarding-complete
• portal-activated
• onboarding-at-risk - applied at twice the target stall threshold, which routes to a partner rather than another reminder.

Forms and surveys

• Client Intake Pack - the centrepiece. Sectioned, with save-and-resume so it can be completed over several sittings and by several people. Sections: organization and contacts; objectives and success measures in the client's own words; current state and what has already been tried; constraints, deadlines and known blockers; systems and access required; stakeholders and approvers; billing and invoicing requirements. Conditional logic shows only the sections relevant to the Engagement Type. Mandatory fields are kept to the minimum that genuinely blocks delivery - everything else is optional, because a pack that feels like an audit does not get finished.
• Access and Credentials Request - a separate, short form sent to the client's technical contact rather than buried in the main pack. It names each system from Access Systems Required and asks for the access method, the account to use, and who to contact if it breaks. Never ask for passwords by email or form; the form asks the client to grant access to a named account or to book the Technical Access Session.
• Stakeholder Map - who decides, who approves, who must be informed, who can block. Asked once, properly, and worth more to delivery than almost anything else collected here.
• Onboarding Experience Survey - three questions sent after handover. The only reliable way to find out which part of this process is annoying from the other side.

Client portal and onboarding guide

• A logged-in portal space activated at signature, holding the executed agreement, the invoice history, the intake pack, the kickoff notes and the current status of every outstanding item. One link the client can return to instead of searching their inbox.
• A short onboarding guide delivered as a sequenced course inside the portal: what happens in week one, who to contact for what, how the firm communicates, what is expected from the client and when. Four or five short lessons released on a schedule, which answers the questions that would otherwise arrive as emails to the engagement lead.
• Progress on the onboarding checklist is visible to the client. Visible progress is a far better motivator than a reminder email, and it changes the dynamic from chasing to shared tracking.

BO's role and guardrails

BO answers the one question clients ask most during onboarding - what do you still need from me? - reading directly from Intake Sections Outstanding, Deposit Status and Credentials Received.

• BO may list exactly what is outstanding, resend any form or portal link, confirm what has been received, state the kickoff date and time, and offer the booking link for the kickoff or the technical session.
• BO may answer process questions already documented in the onboarding guide: what happens next, who to contact, expected timings.
• BO may never discuss fees, invoice amounts, payment terms, discounts or late payment. Anything financial routes to the billing owner.
• BO may never interpret the agreement, confirm what is in or out of scope, or agree to a date or deliverable. Scope questions go to the engagement lead without exception - this is the guardrail most worth testing.
• BO may never accept credentials, passwords or access tokens in a message. The scripted response declines and offers the Technical Access Session instead.
• Immediate handoff on: any mention of canceling or pausing, any complaint about the process, any legal or data protection question, a change of the client's primary contact, or two consecutive turns BO could not answer.

Numbers and channels

• Email is the primary channel throughout, sent from the engagement lead's own address through a connected mailbox so replies thread naturally into the conversation and the client is talking to a person.
• SMS is used sparingly and only where a mobile was given with consent: the kickoff reminder ladder, and a single nudge at the point a card is about to be marked stalled. Texting a corporate client about paperwork more often than that reads as pressure.
• A #onboarding internal channel posts only three things: a new signature, a stall crossing the threshold, and the Monday digest of every card with its age and what it is waiting on.
• The client portal carries everything durable, so no document's only home is an email attachment.

1. The deal is marked won and onboarding starts itself. No handoff meeting, no email to operations, no note on someone's list. A card appears in Client Onboarding at Agreement Sent, the agreement goes out for signature, and every prospect marketing tag is stripped from the contact so the new client never receives a sales email again.
2. The client receives one email that sets expectations for the whole engagement. It confirms what has been sent, outlines the next three steps in plain language, gives them their portal link, and tells them explicitly that nothing else is needed from them until the agreement is signed. That last line prevents the most common week-one confusion.
3. The signature is chased on a schedule, then by a person. Two reminders over five business days, then a task for the engagement lead to find out whether the hold-up is legal review, a second signatory or a purchase order process - because those are solvable and hesitation is not, and only a conversation tells them apart.
4. Signature triggers invoicing against the right person. The invoice goes to the billing contact, not the project sponsor, with any purchase order reference attached. If Invoicing Requirements says a purchase order is needed and none is recorded, nothing is issued yet and the lead is tasked to get it, because an invoice without a required PO is simply a delayed invoice.
5. Payment clears and the intake pack goes out within the minute. This is the single most important handoff in the build. The client has just paid; their attention is on the engagement; the pack should be in front of them while that is still true.
6. The pack is designed to be completable. Sectioned, save-and-resume, forwardable to colleagues, with only the genuinely blocking fields mandatory. The covering email names which two sections matter most for the first conversation, so a partially completed pack is still a useful pack.
7. Chases name the actual gaps. Every reminder reads from Intake Sections Outstanding and lists the specific sections missing. If the pack still stalls, the next message offers a twenty-minute call to fill it in together, because a stuck pack is usually an ambiguous question rather than an unwilling client.
8. Intake completion forks the critical path in two. Kickoff scheduling and the access request go out simultaneously rather than in sequence. Access is almost always the longer of the two, so starting it early is what takes a week out of the timeline.
9. The kickoff can only be booked when both sides can attend. The collective calendar requires the engagement lead and the delivery owner, so the hour that gets booked is an hour the person doing the work can actually attend. The agenda is sent with the booking link, which improves both who attends and how prepared they are.
10. Access is requested properly and never by password. The technical contact gets a short form naming each system individually with the specific grant required, plus a standing offer of a fifteen-minute screen share. Anything that arrives as a password in a message is removed from the thread and the client is redirected to the sanctioned method.
11. Two days before kickoff an internal brief writes itself. Objectives in the client's own words, constraints, stakeholder map, access status, outstanding items, and any contradictions between answers given by different people. Nobody reads the intake pack for the first time in the meeting.
12. The kickoff happens and is summarized the same day. Notes are filed within four hours, a client-facing summary goes out by email and to the portal, and the scope boundaries and first deliverable date are restated in writing. Most scope disputes are prevented by this one message.
13. Access is confirmed by someone actually logging in. Credentials Received and Access Tested are two separate switches. The delivery owner logs in and confirms before the card advances, which is how the problem surfaces during onboarding rather than on the first morning of delivery.
14. Any silence is caught and named, not ignored. A nightly scan compares days since the last client action against the threshold for that stage. Crossing it moves the card to Stalled, posts internally, and sends one honest message asking whether something is blocking it or the timing has changed. Clients answer that question far more often than they answer a reminder.
15. Handover runs a checklist, not a vibe. Signature, payment, mandatory sections, kickoff notes, every system tested, NDA and data processing status resolved. Any gap holds the card and names an owner. Only a clean checklist creates the engagement in the delivery pipeline with everything already carried across.
16. The client is asked how it went, and the firm looks at its own numbers. A three-question survey after seven days; a low score triggers a call within one business day. Thirty days later the card joins a monthly review of elapsed days per stage and the most frequent stall reasons, which is the only mechanism that makes the next onboarding faster than this one.

1. Won Deal to Agreement and Signature Chase

Trigger: sales opportunity marked won.

Branches: on Engagement Type, which selects the agreement template and determines whether an NDA or a data processing agreement must go out alongside it. If the client is a repeat client with an existing master agreement, the whole signature leg is skipped and the card jumps to Deposit Invoiced - repeat clients should never be asked to re-sign something that is already in force.

Actions:

1. Create the card in Client Onboarding at Agreement Sent. Apply onboarding-active and awaiting-signature. Remove every prospect marketing tag, so a new client never receives a sales nurture email.
2. Generate and send the agreement for e-signature to the named signatory, plus the NDA or data processing agreement where the branch requires them. Stamp Agreement Sent Date.
3. Immediately email the client: "[First name] - delighted to be working with you. Your agreement is on its way for signature, and here's exactly what happens next: [three-line outline]. Nothing else is needed from you until that's signed." Telling the client what is not needed yet is what stops them doing the wrong thing first.
4. Activate the client portal, apply portal-activated, and include the portal link in that first email.
5. Wait 2 business days. If unsigned, send a short reminder with the link, and nothing else in the message.
6. Wait 3 business days. Second reminder, and create a task for the engagement lead to check whether the delay is procedural - legal review, a second signatory, a purchase order process - rather than hesitation. These are very different problems and only a human call distinguishes them.
7. Wait 5 business days. Notify the engagement lead and the partner. Set Stall Reason to Awaiting signature.
8. On signature: stamp Agreement Signed Date, file the executed copy to the portal, move to Agreement Signed, swap awaiting-signature for awaiting-deposit, and post to #onboarding.

Exit: agreement executed, or the engagement is formally withdrawn.

2. Deposit Invoicing and Payment Follow-Through

Trigger: stage changes to Agreement Signed.

Branches: on Invoicing Requirements. Purchase order required blocks invoicing until Purchase Order Number is populated and tasks the engagement lead to obtain it - invoicing without it guarantees a rejection. Submission through client portal creates a manual task with the submission instructions rather than sending an email invoice. No purchase order needed invoices immediately. A separate branch handles Waived by agreement, which skips straight to the intake pack.

Actions:

1. Check that Billing Contact Email is populated. If it is not, ask for it before anything is issued - a single email to the right person saves a week of an invoice sitting in a sponsor's inbox.
2. Raise the deposit invoice against the billing contact, attach the purchase order reference where one exists, and set Deposit Status to Invoiced. Move to Deposit Invoiced.
3. Email the billing contact with the invoice and the payment link, copying the project contact so the sponsor knows it has gone out.
4. Wait 3 business days. If unpaid, send a short payment reminder to the billing contact only. Do not copy the sponsor on a first reminder.
5. Wait 5 business days. Second reminder, this time copying the project contact, and create a task for the firm's billing owner.
6. Wait 7 business days. Escalate to the engagement lead with the question framed as a decision: hold onboarding, proceed at risk with partner approval, or pause the engagement. Set Stall Reason to Awaiting payment.
7. On payment confirmation from the processor: set Deposit Status to Cleared, move to Deposit Cleared, swap awaiting-deposit for awaiting-intake, send a receipt, file it to the portal, and hand to workflow 3 within the minute. Momentum at this point matters more than anywhere else in the sequence.

Exit: payment cleared or formally waived with partner approval recorded.

3. Intake Pack Issue and Section-Level Chase

Trigger: stage changes to Deposit Cleared, or Deposit Status set to Waived by agreement.

Branches: on Engagement Type, which determines which sections appear. A second branch runs on which sections remain outstanding, so every chase message names the specific missing sections rather than saying the pack is incomplete. Generic reminders are ignored; specific ones get answered.

Actions:

1. Move to Intake Pack Sent. Send the pack link by email and place it prominently in the portal.
2. Email: "[First name], here's the intake pack: [link]. It's [N] sections, you can save and come back to it, and you can forward it to colleagues for the parts they know better than you. The two that matter most for our first conversation are [section] and [section]." Naming the priority sections raises completion of the sections that actually block work.
3. Release the first lesson of the portal onboarding guide the same day.
4. Wait 2 business days. If nothing has been started, send one SMS where consent exists: "Hi [first name] - intake pack is in your inbox and in the portal whenever you have ten minutes: [link]."
5. Wait 3 business days. Email naming the outstanding sections from Intake Sections Outstanding, verbatim as a list.
6. Wait 3 business days. Offer the Onboarding Check-In calendar: "If it's easier to talk it through than type it, grab twenty minutes here and we'll fill it in together: [link]." A meaningful share of stalled packs are stalled because a question is ambiguous, not because the client is unwilling.
7. Wait 5 business days. Task the engagement lead to call. Set Stall Reason to Awaiting documents.
8. On completion of all mandatory sections: move to Intake Complete, populate Access Systems Required and Stakeholder List, clear Intake Sections Outstanding, and hand to workflows 4 and 6 in parallel. Scheduling the kickoff and requesting access at the same time is what removes a week from the critical path.

Exit: mandatory sections complete, or the partner authorizes proceeding to kickoff without them - which is recorded on the card, because it is a decision with consequences.

4. Kickoff Scheduling

Trigger: stage changes to Intake Complete.

Branches: on whether the Stakeholder List names attendees beyond the primary contact. Where it does, the invitation asks the client to forward the booking link and names the roles that should be present. Where Engagement Start Date is inside five business days, the booking window tightens and the engagement lead is alerted to protect the slot manually.

Actions:

1. Assign Delivery Owner if not already set, so the collective calendar can resolve availability.
2. Email the Kickoff Call booking link: "Time to get started properly. Book our kickoff here: [link]. It's an hour, and the people who'll get the most from it are [roles from the stakeholder map]. Here's the agenda so you know what to expect: [agenda]." Sending the agenda before the booking improves both attendance and the quality of who attends.
3. Wait 2 business days. If unbooked, resend with two named slots offered in plain text.
4. Wait 3 business days. Task the engagement lead to book it by phone. An unbooked kickoff after five days is a relationship signal, not an administrative one.
5. On booking: move to Kickoff Scheduled, apply kickoff-booked, write Kickoff Date, send the confirmation with the conferencing link and the agenda, and file both to the portal.
6. Run the reminder ladder: email at 48 hours with the agenda and a note of anything still outstanding; email at 24 hours; SMS at 1 hour with the link alone where consent exists.

Exit: kickoff held, or the appointment is canceled - which returns the card to Intake Complete and restarts this workflow.

5. Kickoff Preparation and Internal Brief

Trigger: 2 business days before Kickoff Date.

Branches: on whether access has been confirmed. If Access Tested is still off, the internal brief leads with that as the first agenda item, because an hour of kickoff is the cheapest place to resolve it. If the intake pack was completed by multiple people with contradictory answers, the brief flags the contradictions for the lead to resolve live rather than discovering them in week three.

Actions:

1. Assemble the internal brief automatically: the client's stated objectives in their own words, constraints and deadlines, stakeholder map, systems and access status, deposit status, and anything still outstanding.
2. Email the brief to the engagement lead and the delivery owner, and attach it to the card. Nobody should be reading the intake pack for the first time in the meeting.
3. Create a task for the delivery owner: review the brief and add any questions to the agenda, due the day before.
4. On the kickoff ending, create a task for the engagement lead due in 4 hours: file kickoff notes, confirm scope boundaries agreed, confirm the first deliverable date, and set Access Systems Required if anything new emerged.
5. On notes being filed: move to Kickoff Held, apply kickoff-held, publish a client-facing summary to the portal and send it by email the same day. A written summary of what was agreed, sent within hours, prevents most scope disputes before they exist.
6. Wait 24 hours. If notes are not filed, remind the engagement lead daily. An unrecorded kickoff is the most expensive missing record in this build.

Exit: notes filed and the summary sent.

6. Access and Credentials Collection

Trigger: Access Systems Required populated, which happens at intake completion or at kickoff.

Branches: on each named system. The request message differs by system type, since granting access to an accounting system, an advertising account and a shared drive are three different procedures and a generic request produces three different kinds of confusion. If no technical contact was given, the request goes to the primary contact with an explicit ask to forward it.

Actions:

1. Apply awaiting-access. Send the Access and Credentials Request to the technical contact, naming each system individually with the specific access method and the named account to grant.
2. Include the standing instruction prominently: "Please don't send us passwords. Grant access to the account listed, or book fifteen minutes here and we'll do it together on a screen share: [link]."
3. Wait 3 business days. Resend, naming only the systems still outstanding.
4. Wait 3 business days. Offer the Technical Access Session directly, and copy the primary contact so the sponsor can unblock internally.
5. Wait 5 business days. Task the engagement lead. Set Stall Reason to Awaiting access. Access is the most common cause of a late delivery start and the least visible, which is why it gets its own stall reason.
6. On credentials or grants received: flip Credentials Received on, then create a task for the delivery owner to actually log in and confirm. Only when that task completes does Access Tested flip on and the card move to Access Confirmed.
7. Any credentials sent in a message are deleted from the thread, a note is written recording that they were received and removed, and the client is asked to use the sanctioned method instead.

Exit: every required system shows Access Tested, or the partner records a decision to start without a specific system.

7. Stall Detection and Escalation

Trigger: nightly at 01:00, recalculating Days Since Last Client Action across every open card.

Branches: on the current stage, because the tolerable wait differs - 5 business days for a signature, 7 for a payment, 7 for intake, 5 for access. A card at twice its threshold gets onboarding-at-risk and goes to a partner. Cards whose client has an out-of-office or a known holiday recorded are excluded, since escalating against someone's annual leave damages the relationship for nothing.

Actions:

1. At the stage threshold: move the card to Stalled - Awaiting Client, recording the originating stage so it returns correctly. Apply onboarding-stalled and set Stall Reason from the stage.
2. Post to #onboarding: client, stage, days stalled, what is outstanding.
3. Send one message, written as a check rather than a chase: "[First name], I don't want to keep nudging you - is there something blocking this on your side, or is the timing just not right at the moment? Either is completely fine, I'd just rather know which." That question resolves more stalls than any number of reminders, because it makes it easy to tell the truth.
4. Wait 3 business days. If no response, task the engagement lead with a phone call, not an email.
5. At twice the threshold: apply onboarding-at-risk, escalate to the partner, and create a decision task: continue, pause formally with a restart date, or close the engagement with the deposit position recorded.
6. On any client action: remove onboarding-stalled, clear Stall Reason, return the card to its originating stage, and resume whichever workflow owned it.

Exit: client action resumes the card, or the engagement is formally paused or closed.

8. Handover to Delivery and Onboarding Review

Trigger: stage reaches Access Confirmed with Kickoff Held already recorded.

Branches: none on the client side. Internally, a branch on Engagement Type determines which delivery pipeline the engagement is created in.

Actions:

1. Run the completion check: agreement signed, deposit cleared or waived with approval, mandatory intake sections complete, kickoff notes filed, every required system tested, NDA and data processing agreement status resolved. Any gap holds the card and tasks the owner by name. A handover that skips the checklist simply moves the problem into delivery.
2. Move to Onboarding Complete; apply onboarding-complete; remove onboarding-active and every awaiting tag.
3. Create the engagement in the appropriate delivery pipeline, carrying across objectives, constraints, stakeholder map, access notes and the kickoff summary. Delivery should begin with everything already known, not with a conversation about what was agreed.
4. Email the client the handover note: who their day-to-day contact now is, what happens in the first week, how to reach the team, and where the portal lives.
5. Release the remaining lessons of the portal onboarding guide on their schedule.
6. Wait 7 days. Send the three-question Onboarding Experience Survey. Any score below the firm's threshold creates a task for the engagement lead to call within one business day.
7. Wait 30 days. Add the completed card to the monthly onboarding review: elapsed days per stage, where the time actually went, and which stall reason appeared most often. That review is the only mechanism that makes the next onboarding faster than this one.

Exit: handover complete and the survey sent. The card is then read-only and used only for reporting.

What is different afterwards

The elapsed time between signature and work starting shortens, and - more importantly - becomes predictable. The firm can tell a client at proposal stage roughly how long onboarding takes, because it now has a measured answer rather than an optimistic one. Predictability changes how resourcing and cash forecasting are done.

Senior people stop chasing paperwork. Every chase in this build runs on a timer against a named field, and a human only becomes involved when the automated path has been exhausted or when a judgment is required. That is a direct recovery of the firm's most expensive hours, and it also removes the quiet resentment that accumulates when a partner spends Friday afternoon asking a client for a login.

Nothing is discovered late. Purchase order requirements, data processing agreements, which systems need access, who actually approves things - all of it is captured in a structured pack before kickoff rather than surfacing as a surprise in week two. The intake pack is doing the work of three separate conversations that used to happen by accident.

Stalls become visible and get named honestly. A card sitting untouched for a week is no longer something only one person vaguely remembers; it is on a board, in a digest, with a reason attached. And because the escalation message asks whether something is blocking it rather than nudging again, the firm learns the real reason - which is sometimes that the client's priorities changed, and knowing that early is worth more than another reminder.

The client's experience of week one changes character entirely. They get one clear email, one portal link, a form they can complete across several sittings, a short guide answering the questions they were going to ask, and visible progress against a checklist. That is a different impression of competence than a scatter of requests, and it is formed before any actual work has been delivered.

Metrics to watch

• Total onboarding cycle time - won to Onboarding Complete, median and the worst case. The worst case is the number that tells you where the process actually breaks.
• Elapsed days per stage, which is where the build earns its keep. One stage almost always dominates, and it is frequently not the one the team assumes.
• Signature turnaround - sent to executed - and the share needing more than two reminders.
• Deposit days outstanding, and the share of invoices delayed by a missing purchase order or an unknown portal requirement. That share should fall to near zero once the intake pack asks the question up front.
• Intake pack completion rate and time to complete, plus per-section drop-off. A section that consistently stalls people needs rewriting, not chasing.
• Kickoff booking lag - intake complete to appointment confirmed - and kickoff attendance rate against the roles the stakeholder map said should attend.
• Access lead time - request to Access Tested - tracked per system type. This usually identifies one specific system that is always the bottleneck, which can then be requested first.
• Stall frequency and stall reason distribution. The reason distribution is the agenda for improving the process.
• At-risk rate - share of engagements reaching twice their stall threshold - and how many of those ended up paused or closed.
• Handover completeness - share of handovers passing the checklist on the first attempt, without an override.
• Onboarding survey scores, and whether they correlate with cycle time. Sometimes a slower onboarding scores better because the client felt informed, which is a genuinely useful thing to learn.
• Change requests in the first 60 days, compared against whether the intake pack was fully completed before kickoff. This is the clearest evidence of what the pack is worth.

Prerequisites

• Agreement templates that are current and approved, one per Engagement Type, together with a clear statement of who is authorized to sign on the firm's behalf.
• A decision on deposit policy per engagement type - required, waived, or variable - and who may waive it. The build enforces whatever is decided, so the ambiguity has to be resolved first.
• The intake pack questions, drafted and then cut. The first version is always too long. Go through it and mark only the fields that genuinely block delivery as mandatory; everything else is optional or it will sink completion.
• A named engagement lead and a named delivery owner per engagement type, with deputies. The collective kickoff calendar cannot be built without them, and the task routing has nowhere to go.
• Agreed stage thresholds for stall detection. Five business days for a signature and seven for a payment are sensible defaults, but the firm has to own the numbers or nobody will respect the escalations.
• The content for the portal onboarding guide - four or five short lessons. This is writing work, not configuration work, and it is the most commonly underestimated item in the plan.
• A list of the systems the firm typically needs access to, by engagement type, which becomes the Access Systems Required options and the per-system request copy.

Integrations

• Stripe - or PayPal, Square or Authorize.net - for the deposit invoice and the payment webhook that advances the card. The webhook is what makes the intake pack go out within a minute of payment rather than whenever someone checks the bank.
• QuickBooks or Xero, so invoices and receipts land in the books without rekeying and the finance view matches the pipeline view.
• E-signature, with the completion event wired back so signature advances the card automatically and files the executed copy to the portal. A signature that requires someone to notice it has been signed is a signature that waits.
• Google Calendar or Microsoft 365, two-way, for every person on a collective calendar. Without this the kickoff calendar will offer slots the delivery owner cannot attend.
• Zoom or Google Meet for automatic conferencing links on kickoff and technical sessions.
• Gmail and Google Workspace, or a Microsoft mailbox, so onboarding email sends from the engagement lead's own address and client replies thread into the conversation rather than vanishing into a personal inbox.
• A dedicated sending domain with SPF, DKIM and DMARC. Invoices and agreements landing in spam is the most expensive deliverability failure in this build.
• Slack or Microsoft Teams for the #onboarding channel and the Monday digest.
• Google Sheets or BigQuery and Looker Studio if onboarding cycle time needs to sit alongside wider firm reporting.

Number provisioning and messaging compliance

• Provision one number for the limited SMS use in this build - kickoff reminders and a single pre-stall nudge. Most of this build runs on email, and that is correct for corporate clients.
• A2P 10DLC registration is still required for any application-to-person SMS in the United States, even at low volume. Register the brand and campaign and submit the actual reminder samples.
• Capture SMS consent explicitly - on the intake pack is the natural place - with a clear statement of what will be sent. A cell number appearing on a signed agreement is not consent to text.
• Honor STOP, STOPALL, UNSUBSCRIBE, END, QUIT and CANCEL automatically. Note that an onboarding client opting out of SMS should not stop receiving operational email; keep the channels and the consent records separate.
• Quiet hours on every timed send, in the client's time zone. For business-to-business work, also consider restricting sends to business days - a stall nudge arriving on a Sunday evening reads badly.
• Keep onboarding email on a transactional footing and separate from any marketing list, so a client never receives prospect nurture content after signing.

Data protection, security and record keeping

• Never collect credentials through a form, an email or a chat message. The build is deliberately designed around granting access to a named account or resolving it live on a screen share. If a client sends a password anyway, remove it from the thread, record that it was received and removed, and ask them to use the sanctioned route. Brief the team on this before go-live, because the convenient thing and the correct thing diverge here.
• Decide who inside the firm can see client access notes and restrict the field by role.
• The intake pack frequently collects commercially sensitive information and sometimes personal data about the client's own staff or customers. Where that is the case a data processing agreement is likely to be required before the pack is sent, not after - which is why the status field is on the card from day one. Treat the pack as confidential, restrict access, and agree a retention period for engagements that never start.
• Portal access control needs testing deliberately: confirm that a client user can see only their own documents, and re-test after any change to the portal structure.
• Executed agreements, purchase order references and payment records have retention requirements that are usually longer than anything else in this build. Set them to match the firm's obligations rather than to a convenient default.
• Where kickoff calls are recorded or transcribed, obtain consent at the start of the call and state it in the confirmation email.

None of this is legal advice. Contract execution requirements, data processing obligations, security expectations for handling client system access, recording consent and record retention periods vary by jurisdiction, by sector and by what the firm's own client contracts and professional indemnity cover require. Have the client's own counsel confirm the agreement templates, the data processing agreement triggers, the access-handling policy and the retention schedule before this goes live. To scope the build, book a call at bookings.appbo.io.