White-Label Client Onboarding

Onboarding is where an agency either earns the next twelve months or quietly loses them. Most agencies treat it as a handful of emails and a kickoff call, improvised by whoever closed the deal. The client signs on a Friday full of enthusiasm, hears nothing until the following Wednesday, is then asked for assets by someone they have not met, and spends the first two weeks unsure whether anything is happening. Enthusiasm is perishable. By the time real work begins the client has already started grading the relationship on responsiveness rather than results.

The specific failure is that onboarding depends on an individual remembering a sequence. There is no written path, so the steps that happen are the ones the account manager happens to recall, in the order they happen to recall them. Two clients signed the same week get materially different experiences. When the person who onboards well is on holiday, the client who signs that week gets the degraded version, and nobody finds out until the first review. And because the path is invisible, there is no way to tell a stalled onboarding from a slow one until the client asks what is going on.

Money leaks at both ends. At the front, every day of delay is a day of retainer with nothing to show, which shortens the runway before the client starts asking what they are paying for. At the back, a client who never properly onboarded never adopts the thing they bought, never sees the result it was supposed to produce, and churns at month four with a complaint that sounds like a performance problem but is actually an adoption problem. The white-label dimension compounds it: an onboarding path that leaks agency branding, or arrives from three different sending identities, undermines the premise that this is the client's own system rather than a reseller's.

Onboarding pipeline and stages

A pipeline named Client Onboarding in the agency workspace, running alongside provisioning rather than inside it. Provisioning builds the system; onboarding builds the relationship and the adoption. One opportunity per client, closed only when the client has seen a first result.

• Signed - agreement countersigned, welcome sequence firing.
• Welcome Sent - first contact made, portal access issued, kickoff link out.
• Kickoff Booked - date agreed and in the calendar.
• Kickoff Held - goals, owners and the 30-day definition of success recorded.
• Assets Pending - waiting on something only the client can supply.
• Access Pending - waiting on account access or authorization.
• Build In Flight - the agency is working; the client is being kept informed on a cadence.
• Training Scheduled - the team session is booked.
• Trained - the client's staff have been through the session and have the recording.
• First Result Logged - a real, named outcome has occurred and been recorded.
• Onboarded - moved into business as usual, enrolled in reporting and churn monitoring.
• Stalled - a parallel holding stage with a recorded reason and owner, used instead of letting an opportunity rot in place.

Calendars

• Kickoff Call - 60 minutes, booked from the welcome email, 1-day minimum notice so momentum is not lost to a two-week lead time. Attendance by the client's decision maker is a stated requirement in the booking description.
• Team Training Session - 60 minutes, group booking, recorded. Offered once the build is in flight so the training is against a real system, not a demo.
• Day 14 Check-In - 20 minutes, offered automatically, deliberately short so it gets taken.
• Day 30 Review - 45 minutes, the formal close of onboarding and the handoff to the reporting cycle.
• Office Hours - a standing weekly 30-minute slot any onboarding client can book into without asking, which absorbs the small questions that otherwise become email threads.

Custom fields

• onboarding_stage_entered_date, onboarding_owner, onboarding_days_elapsed.
• client_goal_primary, client_goal_metric, client_goal_target_30d - the client's own words and number for what success looks like in the first month. Captured on the kickoff call, quoted back in every later message.
• client_decision_maker, client_day_to_day_contact, client_technical_contact.
• asset_logo_received, asset_photos_received, asset_copy_approved, asset_service_list_received - each yes or no, each individually chaseable.
• access_calendar_granted, access_ads_granted, access_analytics_granted, access_payments_granted.
• kickoff_held_date, training_held_date, training_attendee_count, training_recording_url.
• first_result_type, first_result_date, first_result_detail - what actually happened, in a sentence, for use in the day 30 review.
• portal_last_login_date, portal_login_count, adoption_score.
• stall_reason, stall_owner, stall_days.
• nps_30d_score, nps_30d_comment.
• brand_sending_identity, brand_portal_subdomain - so every onboarding message and every portal page carries the client's identity, not the agency's.

Tags

• Progress: onboarding-active, kickoff-held, assets-complete, access-complete, trained, first-result-logged, onboarded.
• Blockers: waiting-assets, waiting-access, waiting-approval, onboarding-stalled.
• Engagement: portal-never-logged-in, kickoff-no-show, training-no-show, low-adoption, onboarding-at-risk.
• Journey: journey-clinic, journey-home-services, journey-professional, journey-fitness - selects which onboarding variant and which training module set applies.

Forms and surveys

• Goal Setting Worksheet - sent before kickoff, completed by the client. Three questions: what does success look like in 30 days, what number would prove it, and what has stopped this working before. The third question is the most valuable and the most often omitted from onboarding forms.
• Asset Collection - one section per asset type with file uploads, partial save enabled, and a visible progress indicator. Writes to the individual asset_ fields so chasing is item-specific.
• Access Grant Checklist - one row per account, each with its own instruction, link and status write-back.
• Training Comprehension Check - five questions immediately after the training session. Not a test of the client; a test of the training. Low scores on one question mean that module needs rewriting.
• Day 30 Pulse - a single recommendation-likelihood question plus one free-text comment, writing to nps_30d_score and nps_30d_comment.

Client portal and training library

• A client portal on brand_portal_subdomain, in the client's branding, showing their onboarding progress as a checklist with their own outstanding items at the top. The portal replaces the where-are-we email.
• A training library of short modules, assigned by journey- tag, each under eight minutes, with completion tracked per named user. Modules cover reading the pipeline, answering an inquiry, taking a booking, and finding their numbers.
• A welcome page that doubles as the first portal landing, carrying the named team, the agreed goal in the client's own words, and the dates of kickoff, training and day 30.

BO's role and guardrails

• BO chases outstanding assets and access by item, in the client's own channel, under the client's sending identity.
• BO answers where-are-we questions by reading the pipeline stage and the outstanding-item fields, and points to the portal.
• BO handles scheduling: offering slots, rescheduling, reminding.
• BO never represents itself as the agency's staff and never claims work has been done. It reports stage and outstanding items only. Progress claims come from humans.
• BO never answers a question about results, performance or strategy during onboarding. Those go to onboarding_owner unanswered.
• BO never discusses pricing, scope, contract terms or renewal.
• BO cannot move an opportunity to First Result Logged or Onboarded. Both require a human to record what actually happened.
• Every BO message sends from brand_sending_identity, so the white-label boundary holds in the channel the client actually reads.

Numbers and channels

• All client-facing onboarding email sends from the client's own authenticated sending identity, never the agency's shared domain.
• SMS used for appointment reminders and for the final chase on a blocking item only, to contacts who opted in at signature, within their local business hours.
• A single named human contact introduced by name and photo in the welcome email, so the client has a person rather than a function.
• Internal stall and no-show alerts to Slack.

One client, signature to onboarded. A four-van plumbing company on the Home Services journey.

1. The agreement is countersigned at 16:40 on a Thursday. An opportunity is created in Client Onboarding at Signed, onboarding_owner is assigned, onboarding_stage_entered_date is stamped, and journey-home-services is applied.
2. Twenty minutes later the welcome email arrives from the client's own sending identity. It names the owner with a photo, states the dates to expect, and carries three links: the portal, the Kickoff Call calendar, and the Goal Setting Worksheet. The opportunity moves to Welcome Sent. Nothing in this email mentions the agency's platform stack.
3. The client books kickoff for Monday and completes the worksheet on Sunday evening. The answer to what has stopped this working before is that their office manager left and nobody picked up the phone for two months. That sentence is worth more than the rest of the form and is carried into the kickoff agenda.
4. Monday kickoff. The owner confirms client_goal_primary as more booked jobs from existing inquiries, client_goal_metric as booked jobs per week, and client_goal_target_30d as twelve. Contacts are recorded. kickoff_held_date is stamped, kickoff-held applied, and the opportunity moves to Kickoff Held.
5. Asset and access requests go out in a single message with one link each, not two separate sequences. waiting-assets and waiting-access are applied, and the opportunity moves to Assets Pending.
6. The client uploads the logo and service list on Tuesday but not the van photos. BO chases Wednesday naming only the photos. The portal shows one outstanding item, not four, which is the difference between a client who finishes and one who gives up.
7. Calendar access is granted Tuesday. Analytics access stalls because nobody knows the login. On day four BO offers the office hours slot; the technical contact takes it and the access is granted on the call. access-complete is applied and the opportunity moves to Build In Flight.
8. While the build runs, the client gets a progress note every Monday under their own identity. Copy is specific rather than reassuring: what was done, what is next, nothing needed from them this week. Silence during build is what breaks onboarding, and a weekly note costs nothing.
9. Training is offered for the following Thursday with the whole team invited. Three of five staff book. The opportunity moves to Training Scheduled.
10. Training runs and is recorded. training_held_date, training_attendee_count of 3 and training_recording_url are written. Because attendance is below the full team, the two absentees are assigned the training modules individually with a seven-day completion window rather than being quietly written off. trained is applied.
11. The comprehension check comes back with four of five questions answered well and everyone wrong on where to find their numbers. That is a training defect, so the module is rewritten and the revised version reissued to all three attendees.
12. Day 14. The short check-in is offered and taken. The owner says inquiries are coming through but nobody is calling them back fast enough, which is the same failure that caused the original problem. The owner adds a missed-inquiry alert to the staff phone and logs the change against the record.
13. Day 19. A booking comes through the new path and is attended. first_result_type is set to Booked job from inbound inquiry, first_result_date stamped, and first_result_detail records the job in one sentence. first-result-logged is applied and the opportunity moves to First Result Logged. A human did this, not BO.
14. Day 30 review. The agency opens with the client's own words from kickoff and the number they named, then shows booked jobs per week against twelve. The Day 30 Pulse is sent immediately after, while the conversation is fresh.
15. The opportunity moves to Onboarded. onboarding_days_elapsed is computed, every blocker tag is removed, the client is enrolled in the monthly reporting cycle and the churn-risk monitor, and client_goal_primary and client_goal_metric are copied forward so the first monthly report is judged against the goal the client set on day four rather than a target the agency invented later.

1. Welcome and First Contact

Trigger: agreement countersigned.

Conditions: exits if an opportunity already exists in Client Onboarding for this contact. Every message in this workflow sends from brand_sending_identity, never the agency domain.

Actions:

1. Create the opportunity at Signed. Stamp onboarding_stage_entered_date. Apply onboarding-active and the matching journey- tag.
2. Assign onboarding_owner.
3. Wait 20 minutes. Long enough not to look automated, short enough to arrive the same hour.
4. Send the welcome email. Copy: Welcome aboard, [first name]. I am [owner first name] and I will be looking after you. Here is what the next four weeks look like: we will have a kickoff call this week to agree exactly what success looks like, your system built the week after, your team trained the week after that, and a proper review at day 30. Three links to start: your portal, where you can always see where things stand - [portal link]. Your kickoff slot - [kickoff link]. And a short worksheet to fill in before we talk - [worksheet link]. Fifteen minutes and it makes the call ten times more useful.
5. Issue portal credentials to client_day_to_day_contact.
6. Move to Welcome Sent.
7. Wait 24 hours. If no kickoff booking, BO sends a short nudge: Hi [first name] - grab whichever slot suits: [kickoff link]. Sixty minutes, and we will agree the target we are working to.
8. Wait 48 hours. If still unbooked, create a task for onboarding_owner to call, and SMS the consented contact.
9. Wait 72 hours. Escalate to the principal. A client who will not book a kickoff in the first week is already a risk signal.

Stop or exit: cancels on kickoff booking. Does not cancel on portal login alone, because logging in is not the same as engaging.

2. Kickoff Preparation, Reminders and No-Show

Trigger: kickoff booking confirmed.

Actions:

1. Move to Kickoff Booked. Create a prep task for onboarding_owner due 2 hours before, carrying the worksheet answers.
2. Wait until 24 hours before. Email reminder. Copy: Looking forward to tomorrow at [time]. Two things to make it count: please have [client_decision_maker] on the call, and if you can, finish the worksheet first - [link]. We will come out of this with one number we are both working to.
3. Wait until 2 hours before. SMS reminder to consented contacts, within quiet hours.
4. Wait until 15 minutes after the start. Branch on attendance.
5. Attended: move to Kickoff Held, stamp kickoff_held_date, apply kickoff-held, and create a task to record client_goal_primary, client_goal_metric, client_goal_target_30d and the three contacts. The opportunity cannot advance until client_goal_metric is populated.
6. No-show: apply kickoff-no-show, send Sorry we missed each other - here is my calendar: [link]. If this week is difficult, reply and tell me when and I will work around you. Create a call task for the owner the same day.
7. Second no-show: apply onboarding-at-risk, notify the principal, and have a human - not BO - make contact.

Stop or exit: cancels on the goal fields being populated. A kickoff that happened but produced no recorded goal is treated as not held.

3. Asset and Access Collection with Item-Level Chasing

Trigger: tag kickoff-held applied.

Conditions: every step re-reads the individual asset_ and access_ fields and names only what is still outstanding. Generic chasing is what makes clients stop opening onboarding email.

Actions:

1. Send one message containing both the asset form and the access checklist, with a line stating how many items in total. Copy: Four things from you and we can build. Two files and two account authorizations, about ten minutes all in: [asset link] and [access link]. Your portal shows what is outstanding at any point: [portal link].
2. Apply waiting-assets and waiting-access. Move to Assets Pending.
3. Wait 48 hours. BO chases the outstanding items by name only. Copy: Hi [first name] - down to [n]: [item list]. [link]
4. Wait 48 hours. Second chase, plus the Office Hours link. Copy: If any of these are fiddly, drop into office hours and we will do them together: [link].
5. Wait 72 hours. Create a call task for onboarding_owner, SMS the consented contact, and post to Slack with the item list.
6. Wait 5 days. Move to Stalled, set stall_reason to the outstanding item, set stall_owner to Client, apply onboarding-stalled, and notify the principal.
7. Branch: when all asset_ fields read yes, remove waiting-assets and apply assets-complete. Same independently for access. Only when both are complete does the opportunity move to Build In Flight.
8. Branch: where an item is genuinely unavailable, a human records a documented substitute on the record and the item is marked satisfied with a note. The build is not held hostage by a missing photograph.

Stop or exit: cancels per item as it arrives, so the client never gets chased for something already supplied.

4. Build-In-Flight Progress Cadence

Trigger: opportunity enters Build In Flight.

Conditions: runs weekly while the opportunity remains at this stage. Each note requires a human to have written a one-line progress summary that week; if none exists, the workflow asks the owner for it rather than sending something empty.

Actions:

1. Every Monday at 09:00 in the client's timezone, send the progress note from brand_sending_identity. Copy shape: Quick update on [client_goal_primary]. Done this week: [summary]. Next: [next step]. Nothing needed from you this week. Anything on your mind, office hours are open: [link].
2. Where something IS needed, the same note leads with it and the subject changes to name the item.
3. Wait 4 days from the first note, then offer the Team Training Session booking link to client_day_to_day_contact with the whole team invited.
4. If the owner has not supplied a progress line by Friday 15:00, Slack the owner, and if still missing by Monday 08:00, Slack the principal. Do not send a reassuring note with nothing in it.

Stop or exit: exits when the opportunity leaves Build In Flight, or after four weeks at this stage, which triggers the stall workflow rather than continuing to send cheerful updates about a build that is not finishing.

5. Training Delivery, Attendance and Comprehension

Trigger: training booking confirmed.

Actions:

1. Move to Training Scheduled. Send confirmation to all invitees with a one-line prompt of what to bring.
2. Reminders at 24 hours and 1 hour before, to every registered attendee, not just the booker.
3. Wait until 30 minutes after the session ends. Branch on attendance. Write training_attendee_count and training_recording_url, stamp training_held_date, apply trained, move to Trained.
4. Send the recording and the Training Comprehension Check within 30 minutes, while it is fresh. Copy: Here is the recording and a five-question check - it takes two minutes and it tells us which bits we explained badly: [link].
5. Branch on training_attendee_count against the client's recorded headcount. Below full attendance assigns the self-paced modules to each absentee individually, with a 7-day window and a reminder at day 4.
6. Wait 48 hours. Any invitee who neither attended nor completed a module is tagged training-no-show and listed to onboarding_owner by name.
7. Branch on comprehension results: any question answered incorrectly by more than half of respondents creates an internal task to rewrite that module, and the revised module is reissued to everyone who took the original.
8. Zero attendance applies onboarding-at-risk and escalates to a human call. A team that will not attend training will not adopt the system.

Stop or exit: cancels when attendance plus module completion covers the client's headcount.

6. First Result Detection and Logging

Trigger: tag trained applied.

Conditions: watches the client workspace for the first qualifying event defined at kickoff against client_goal_metric - a booked appointment attended, an inquiry answered inside target, a payment taken, whatever the client named.

Actions:

1. On detecting a candidate event, create a verification task for onboarding_owner. Copy: Possible first result for [client]: [event detail]. Confirm it is real and write one sentence describing it.
2. The owner confirms, which writes first_result_type, first_result_date and first_result_detail, applies first-result-logged, and moves to First Result Logged. BO cannot do this step.
3. Send the client a short, specific congratulation from their own identity. Copy: [first name] - first one through. [first_result_detail]. That is the thing we agreed we were aiming at on [kickoff_held_date].
4. Branch: 14 days after trained with no candidate event, apply low-adoption, create a diagnostic task, and offer a short working session. Copy: Nothing has come through the new path yet. That is usually one small thing in the way rather than a big problem - 20 minutes and we will find it: [link].
5. Branch: 21 days with no result applies onboarding-at-risk and escalates to the principal, because a client with no first result by week three is the profile that churns at month four.

Stop or exit: cancels on a human-confirmed first result. A detected-but-unconfirmed event never counts.

7. Day 14 Check-In and Day 30 Review

Trigger: 14 days after onboarding_stage_entered_date, and separately at 30 days.

Actions:

1. Day 14: offer the 20-minute check-in. Copy: Two weeks in. Twenty minutes to hear how it is actually going and fix anything that is annoying you: [link].
2. If unbooked after 48 hours, one reminder. If still unbooked, create a call task rather than chasing a third time by email.
3. Day 30: offer the 45-minute review, and create a prep task for onboarding_owner carrying client_goal_primary, client_goal_target_30d, the actual figure, and first_result_detail. The review opens with the client's own words from kickoff.
4. Reminders at 24 hours and 2 hours before.
5. Wait 30 minutes after the review ends. Send the Day 30 Pulse, writing nps_30d_score and nps_30d_comment.
6. Branch on pulse score. A low score creates a same-day task for the principal to call, not an automated apology. A high score creates a task to ask for a review or referral, timed 3 days later so it does not land in the same breath.
7. No pulse response after 5 days: one reminder, then stop. Do not chase a survey into resentment.

Stop or exit: both sequences end at the pulse, whether or not the review was attended. A missed day 30 review applies onboarding-at-risk and is handled by a human.

8. Stall Detection and Escalation

Trigger: scheduled, daily at 08:00. Evaluates every opportunity tagged onboarding-active.

Conditions: compares days at the current stage against that stage's own threshold - 2 days at Welcome Sent, 5 at Assets Pending, 5 at Access Pending, 21 at Build In Flight, 10 at Training Scheduled. A single global threshold produces either noise or silence, never useful alerts.

Actions:

1. On breach, move to Stalled, write stall_reason from the stage and outstanding fields, set stall_owner to Client or Agency, and increment stall_days daily.
2. Apply onboarding-stalled and post to Slack naming the client, the stage, the days, the reason and the owner.
3. Branch on stall_owner. Agency-owned stalls create a task for onboarding_owner due the same day and escalate to the principal at 48 hours. These are the ones the agency can actually fix and should be loudest.
4. Client-owned stalls trigger a human phone call rather than another automated chase. At 10 days, the principal contacts the decision maker directly and the conversation is about whether the engagement is viable, not about a missing file.
5. On resolution, return the opportunity to its correct stage, clear stall_reason and stall_owner, preserve stall_days as a historical record, and remove onboarding-stalled.
6. Post a weekly Slack digest: stalled count by stage, by owner and by reason, with the longest-running named.

Stop or exit: runs continuously for every active onboarding. Exits a record only on onboarded.

9. Onboarding Close and Handoff to Business as Usual

Trigger: tag first-result-logged applied and the day 30 review marked attended.

Conditions: requires both. A first result without a review, or a review without a result, holds at the current stage and notifies the owner.

Actions:

1. Move to Onboarded. Apply onboarded, remove onboarding-active and every blocker and engagement tag.
2. Compute onboarding_days_elapsed from signature to this moment.
3. Copy client_goal_primary, client_goal_metric and client_goal_target_30d into the reporting fields, so the first monthly report is measured against the client's own stated target.
4. Enroll the client in the monthly reporting cycle and the churn-risk monitor, passing through nps_30d_score, portal_login_count, training_attendee_count and any low-adoption history as starting signals rather than beginning that monitoring from zero.
5. Send the closing email from the client's identity. Copy: That is onboarding done. You said on [kickoff_held_date] that success looked like [client_goal_primary]. Where we got to: [actual]. From here you will get a summary on the [report_send_day] of each month, and office hours stay open if you need us: [link].
6. Create a 60-day adoption check task for onboarding_owner.
7. Post the completion summary to Slack: days elapsed, first result type, pulse score, stall days incurred.
8. Branch: where onboarding_days_elapsed exceeds the agency target, create an internal retrospective task naming the stages that consumed the time. The build improves from these, not from the clean cases.

Stop or exit: terminal. Any later issue is handled by the reporting and churn-risk builds, not by reopening onboarding.

What is different afterwards

• Every client gets the same path, in the same order, whoever closed them and whoever is on holiday. Onboarding stops being a function of one person's memory.
• The client's first week contains contact, a booked kickoff, a portal they can see progress in, and a named human. The gap that used to sit between signature and first contact disappears.
• The client's own goal, in their own words and their own number, is recorded on day four and carried into every later conversation and report. Reviews stop being arguments about what success was supposed to look like.
• Stalls are visible and owned. An onboarding waiting on the client looks different in the pipeline from one waiting on the agency, and both have a recorded reason and an owner.
• Adoption is measured, not assumed. Portal logins, training attendance and comprehension scores say whether the client can actually use what was built, which is the real predictor of month-four churn.
• The white-label boundary holds end to end. Every message, page and portal carries the client's identity, so the client experiences their own system rather than a reseller's.
• Onboarding ends at a defined moment with a recorded first result, instead of fading out and leaving nobody sure whether the client is live.

Metrics to watch

• Signature to first contact, in hours. Should be under one. This is the cheapest number to fix and the one clients remember.
• Signature to kickoff held, in days, and the share of kickoffs attended by the recorded client_decision_maker. A kickoff without the decision maker rarely produces a usable goal.
• Signature to first result, in days - from first_result_date. The single most important number in this build, and the one to put in the sales conversation once it is real.
• Asset and access completion time, per item. The ranked list of slowest items is your form redesign backlog.
• Stall rate and stall days by reason - from stall_reason and stall_days. Separate agency-caused from client-caused and report both honestly.
• Training attendance rate and training_attendee_count against headcount. Partial attendance is a leading indicator of poor adoption.
• Comprehension scores by question - a question everyone gets wrong is a training defect, not a client problem.
• Portal login count in the first 30 days, and the count of clients tagged portal-never-logged-in.
• Day 30 pulse score, tracked against eventual retention at month six, so you learn whether the pulse actually predicts anything for your client base.
• Onboarding completion rate - share reaching Onboarded within the target window, and what happened to the ones that did not.

Prerequisites

• A written definition of what onboarded means for your agency, ending in something observable. First result logged is a defensible finish line; everything is set up is not.
• Agreement on who owns onboarding. If the closer owns it, they need protected time for it; if a delivery person owns it, the handover from sales needs its own step with the goal and context carried across.
• The onboarding path drafted on paper before anything is built, including what happens when the client does nothing for a week. The failure branches are most of the build.
• Training modules recorded against a real system, short, and segmented by journey. Do not try to build the library and the sequence in the same two weeks; ship the sequence with two modules and add the rest.
• Decided brand boundaries per client: sending identity, portal subdomain, logo, tone. The white-label discipline is only as good as the weakest asset, and the weakest asset is usually a calendar confirmation nobody rebranded.
• The provisioning build either in place or running in parallel. Onboarding a client into a workspace that is not ready produces exactly the silence this build exists to remove.

Integrations

• Google Calendar or Outlook per staff member with real availability, including the shared office hours slot.
• Stripe or the client's processor where onboarding includes collecting the first payment or setting up a subscription, authorized by the client to their own account.
• Ad platform and analytics access granted by the client to their own properties, tracked through the individual access_ fields rather than as one all-or-nothing flag.
• Slack for stall alerts, no-show alerts and the weekly onboarding digest.
• Zapier or Make only where a required step has no native path, documented per client.
• Video hosting for training modules and session recordings, with links written to the client record so a new staff member can find them.

Number provisioning and messaging compliance

• Where onboarding uses SMS, complete A2P 10DLC brand and campaign registration under the client's own legal entity before any message sends. Onboarding reminders are not urgent enough to justify sending ahead of approval.
• Capture SMS consent explicitly at signature or on the intake form, with the consent wording recorded and timestamped. A contract signature is not consent to be texted.
• Quiet hours bound to the client's local timezone, defaulting to 08:00 to 20:00, applied to every onboarding SMS including reminders.
• Honor STOP, UNSTOP and HELP, and make sure an onboarding opt-out does not also suppress the operational messages the client needs during their first month. Keep the consent flags separate.
• Every SMS identifies the sender by the client's own business name, not the agency's, consistent with the rest of the white-label path.

Compliance and data protection

• Onboarding collects a lot at once: staff names, emails, phone numbers, account access, sometimes photographs of staff. Collect only what the build genuinely uses, and delete uploads once they have been applied.
• Portal access should be per named user with individual credentials. A shared portal login defeats the adoption metrics and the audit trail at the same time.
• Access to the client's own third-party accounts should be granted by the client to a named agency user, never by the client handing over a password. Document which agency users hold which access, and revoke on staff departure.
• Training recordings often capture live client data on screen. Decide before recording whether that is acceptable, and keep recordings behind the portal rather than on a public link.
• Where the agency processes personal data on the client's behalf, expect to need a written processing agreement, a retention period, and a documented deletion process at the end of the engagement.
• None of this is legal advice. Have the client's own counsel confirm consent wording, processing terms and retention for their jurisdiction and sector, and have the agency's counsel review the standard onboarding pack.

The shape of the path and the number of journey variants drive the build effort. To scope it for a specific agency and client mix, book a call at bookings.appbo.io.