Most onboarding fails in the first three days, always the same way: the visible work gets built first and the registrations get left until someone needs them. Launch day arrives, SMS is not approved, and the wait is two to four weeks that could have elapsed in the background for free.
The order below is dependency, not preference. Each phase unlocks the next, and the two items gated by outside parties go in on day one whether or not anything else is ready.
Phase 00Before the account exists
Nothing is built until three things are in hand. Chasing any of them mid-build is what turns four weeks into ten.
The technical intake
Not goals. That was diagnosis. This is the unglamorous detail the build consumes:
- Legal entity name, character for character as registered (highest-stakes field in the build, see phase 04)
- EIN or tax ID, registered address, entity type (sole proprietor changes the A2P path)
- Live website URL with a reachable privacy policy and terms page
- Business hours including holidays, plus what happens to a lead at 9pm Sunday
- Current phone number, who answers it, and where it forwards today
- Timezone, and whether staff span more than one
- Existing contact export with unsubscribe and bounce history
- Who owns bookings: every person who needs a calendar
The access list, split by when it is needed
Snapshot or blank
A snapshot is a saved template of a full account setup that loads into a new sub-account. When the client fits one I maintain, that is roughly two weeks saved. When their model is unusual enough that the template fights me, I start blank and say so upfront rather than bending the business to fit the template.
Phase 01Account creation & foundation
Create and load
- Create the sub-account under the agency, correct timezone from the start
- Load the snapshot, then immediately repair what snapshots always break
- Set business hours and holidays before any calendar or wait step exists
- Upload logo and brand assets, set the account favicon
What a freshly loaded snapshot leaves broken. Loading is never the end of the job. Every time, I check:
- Custom values are empty: they carry the key, not the value, so every phone number and link is blank
- Workflows referencing calendars, forms or trigger links from the source account may point at nothing
- User assignment steps point to users who do not exist in this account
- Email and SMS templates still contain the template business's name
- Workflows may load in a published state, so check every one before a contact enters
Business profile: the ten highest-stakes minutes
Legal name, address, EIN, website, timezone. This takes ten minutes and determines whether SMS works, because these exact fields get submitted to The Campaign Registry for A2P brand verification. A mismatch against the registration document is the most common cause of rejection.
Type it from the document, never from memory. "Smith & Sons Roofing LLC" and "Smith and Sons Roofing, LLC" are different entities to an automated verification check. Same for suffixes, punctuation, and the address format on file with the IRS.
Users, permissions and ownership
- One invited user per person: never a shared login, or calendar ownership and audit history both break
- Permissions at the minimum that lets each role work; widening later is a two-minute conversation, narrowing after a deleted pipeline is not
- Decide who sees conversations: full inbox visibility versus assigned-only
- Disable dashboard access for roles that should not see revenue figures
Billing and wallet
- Payment method on file before any number is bought or message sent
- Auto-recharge enabled with a sensible threshold: a wallet hitting zero stops every text and call silently, usually on a Friday
- Rebilling margins set if reselling usage to the client
- Agree who pays for what in writing: A2P registration fees, per-segment SMS, call minutes, email volume
Phase 02Domain & DNS
DNS is the internet's address book: the records saying where a site lives and who may send email as that domain. Records can propagate in minutes or take a day, which is why this sits early.
- Funnels on a subdomain such as
go.oroffers., never the root domain when a live website already exists, so nothing we do can take their site down - SSL confirmed issuing correctly after the record resolves
- A redirect strategy decided for any old URLs being replaced
- Client's registrar documented: half of all delays here are nobody knowing who controls the domain
Ask "who registered your domain" in the intake. The answer is regularly a former web developer who is no longer contactable, and recovering a domain takes longer than everything else on this page combined. Better to learn it in week zero.
Phase 03 · start day oneEmail infrastructure
Authentication records
Three records, and no longer optional, because major inbox providers now reject bulk mail that lacks them.
| Record | In plain terms | If it is missing |
|---|---|---|
| SPF | Lists which servers may send email for this domain. | Mail is treated as forged. |
| DKIM | Cryptographically signs each message so tampering is detectable. | Delivery to spam, or outright rejection. |
| DMARC | Tells inboxes what to do when the first two fail, and where to send reports. | No visibility, and bulk senders get blocked. |
Sending domain decisions
- Dedicated sending subdomain:
mail.clientdomain.com, so campaign reputation never touches the root domain the team uses for real email - From-name and reply-to set to a monitored human address, not a no-reply
- Unsubscribe header enabled alongside the visible footer link
- Choose the sending route: the built-in LeadConnector service or the client's own Mailgun account, decided on volume and who owns the reputation afterwards
Warm-up
A brand-new sending domain that suddenly sends five thousand emails looks exactly like a spammer. Volume ramps gradually over two to three weeks, starting with the most engaged contacts. This cannot be shortcut, which is why the records go in on day one though the first campaign is weeks away.
Phase 04 · start day onePhone system & A2P 10DLC
The phase that sets the launch date. A2P 10DLC stands for application-to-person messaging over standard 10-digit long codes: the framework US carriers require before a business may send automated texts from a normal local number. It exists because the channel was abused, and there is no way around it.
What brand registration needs
- Legal entity name exactly as filed
- EIN or tax ID matching that name on record
- Registered business address, entity type, and industry vertical
- Live website: a holding page is a rejection
- Named contact with a business email at the domain, not a free mailbox
What campaign registration needs
- Use case: mixed, customer care, marketing, account notification, or 2FA
- Sample messages, usually two to five, written before submission rather than guessed
- Opt-in description and evidence: the exact URL of the form, or a screenshot showing the consent checkbox
- HELP and STOP language present in the samples and honoured in the build
- Message flow description matching what the workflows will actually send
The privacy policy trap. Registration commonly requires the client's website to carry a reachable privacy policy that states phone numbers collected are not sold or shared with third parties for marketing. A surprising share of small businesses have no privacy policy at all, and if you are also building their new site, you have a loop: A2P needs a live site, the site is not live yet. Resolve it by publishing a compliant policy page on the existing domain in week one, before anything else.
Sole proprietor versus standard brand
Businesses without an EIN can usually register on a sole proprietor path, with materially lower throughput limits and tighter restrictions. Establish which path applies during intake, because discovering it at submission means re-gathering documents.
Toll-free is a separate process
Toll-free numbers use toll-free verification, not 10DLC. Different form, different reviewer, different timeline. If the client wants both a local and a toll-free number, that is two registrations, both submitted on day one.
What I configure while approval is pending
- Call forwarding and the ring order across the team
- Whisper message so whoever answers hears which campaign the call came from before speaking
- Voicemail and after-hours behaviour, matched to the business hours set in phase 01
- Call recording with a consent announcement where the jurisdiction requires it
- Missed-call text-back, drafted but left off until A2P clears
- Number pool if call tracking by source is in scope
Port existing numbers late, never early. Porting takes a number out of service for a window. You do not want that window in week one, when nothing is ready to catch the calls. Buy a new number for building and testing, port the real one days before launch.
Phase 05Integrations & connected accounts
Each of these fails silently when it disconnects, so each one gets documented and re-checked at the day-7 checkpoint.
| Connection | What it unlocks | Watch for |
|---|---|---|
| Google Business Profile | Review requests and replies, GBP messaging, call tracking from the listing | Must be connected by a profile owner, not a manager |
| Google / Outlook calendar | Two-way sync so real availability is respected | Every booking user needs their own connection, not just the owner |
| Meta Business Manager | Lead form sync, messaging, ad-source attribution | Page access and lead access are separate permissions |
| Stripe or payment processor | Invoices, products, subscriptions, payment-triggered automation | Test versus live keys, a classic launch-day discovery |
| Analytics and pixels | Conversion tracking on funnels and forms | Add to funnel settings, not just the page, or steps get missed |
| Webhooks / Zapier / Make | Anything the platform does not do natively | Document every one, these are invisible in the account |
Phase 06Data structures
The containers everything else references. Built before a single workflow, because a workflow pointing at a field that does not yet exist has to be rebuilt rather than edited.
- Custom fields created with final names: the hidden field key is generated once and never catches up with a rename
- Custom values populated: business phone, booking links, addresses, office hours, so no message hardcodes a value that later changes
- Tag namespaces defined and the closed list documented
- Pipelines and stages in the client's own words, not mine
- Calendars built with notifications switched off until testing ends, so forty test bookings do not email the team forty times
- Buffers, minimum notice and booking windows set to what the team can actually honour
Phase 07Assets & copy
The visible layer, and the most collaborative phase, where client feedback is genuinely useful rather than a distraction.
- Forms and surveys with the consent checkbox and policy links required by phase 04
- Funnels and landing pages, mobile checked first rather than last
- Booking pages per calendar, with confirmation content
- Email and SMS templates written before any workflow exists
- Trigger links for click-based branching, named to convention
- Review request assets and the direct Google review URL
Write every message before building any workflow. You cannot write the reminder sequence without deciding how many reminders exist, when they fire, and what happens when someone replies to one. Those decisions belong in a document, not discovered halfway through a canvas. It also gives the client something to react to weeks earlier.
Phase 08The compliance layer
Not a legal opinion. I am not a lawyer, and jurisdictions differ. These are the build settings that keep a system defensible, and they are configured deliberately rather than inherited from a snapshot.
- Opt-in is explicit and recorded: an unticked checkbox with plain wording, and the submission stored as evidence
- STOP, UNSUBSCRIBE and HELP honoured across every channel, tested by actually sending STOP
- Quiet hours enforced in workflows, respecting the contact's timezone rather than the account's
- Suppression list imported from the old system before any send
- Do-not-contact flags as a system tag that every outbound workflow checks first
- Recording consent announcement where required
- Privacy policy and terms linked from every form and every email footer
Opt-out status does not migrate automatically. Someone who unsubscribed from the old system is, to a fresh import, just another row in a spreadsheet. Carrying suppression across is a deliberate step, and skipping it is both a legal problem and the fastest way to get a number flagged.
Phase 09Automation
Workflows are built in the order the customer experiences them, not by difficulty. That way you can stop at any point and still have something coherent to demo.
- Intake and routing: capture, deduplicate, assign an owner, stamp the source
- Speed to lead: the first-minute response and the internal alert
- Booking: confirmation, calendar invite, reschedule handling
- Show rate: reminder sequence and no-show recovery
- Nurture: for leads who do not book
- Post-service: review requests, referral asks, reactivation
- Internal operations: stale-lead sweeps, escalation, reporting alerts
Everything is built switched off, tested against a dummy contact, and left off until phase 12.
Phase 10Data migration
The most dangerous step in the build, and the one I move slowest through.
- Confirm every workflow is off. Then confirm again from the list view, not from memory.
- Import twenty records first and inspect them field by field.
- Fix the field mapping, which will be wrong somewhere. It always is.
- Standardise phone formats to international notation before the full run.
- Import the full list, tagged with its source and date so it can be identified or reversed.
- Apply suppression flags: unsubscribed, bounced, complained, previously asked not to be contacted.
- Deduplicate, deciding in advance which record wins on conflict.
- Spot-check fifty records against the source before declaring it done.
Phase 11Testing
Not clicking through once. Walking a test contact down every branch, including the ones nobody expects anyone to take.
| Path | What is being checked |
|---|---|
| Happy path | Form → booking → reminders → follow-up, end to end, as a real person |
| No response | Lead never replies. Does nurture start, and does it stop? |
| Opt-out | Reply STOP. Does everything cease, across both SMS and email? |
| Duplicate | Same person submits twice. Do they receive two of everything? |
| Out of hours | Lead arrives at 2am. Does anything fire at 2am that should not? |
| Reschedule | Do reminders for the old slot stop? |
| Cancellation | Does the opportunity move, and does recovery start? |
| Payment | Live key, real card, real refund |
| Deliverability | Seed sends across major providers. Where does it land? |
| Mobile | Every page and email on a phone, not a resized browser |
The client tests too, on their own phone. Not because I expect them to find bugs, but because it is the moment the system stops being abstract, and it surfaces the "we would never say it like that" feedback which is far cheaper now than after launch.
Phase 12Launch & handover
Launch is staged, not flipped. If something breaks, staging tells you exactly which piece.
- Day 1: intake and routing live on real leads, watched closely
- Day 2–3: booking and reminders
- Day 4–5: nurture and longer follow-up
- Last: port the existing business number across
DependenciesWhy the order cannot be rearranged
| This must precede this | Cost of getting it backwards |
|---|---|
| Business profile → A2P brand | Rejection, resubmission, restarted clock, possible fee |
| Privacy policy live → A2P campaign | Campaign rejected; needs the client's web access to fix |
| DNS records → email warm-up | Warm-up cannot begin; launch slips by weeks |
| Business hours → calendars & waits | Reminders fire at 3am; painful to unpick retroactively |
| Data structures → workflows | Automations get rebuilt rather than adjusted |
| Copy written → workflows built | Logic gaps discovered mid-canvas; rework |
| Workflows off → contact import | No undo for eight thousand accidental texts |
| Suppression list → first send | Legal exposure and a flagged number |
| Testing → number port | Live calls landing in an untested system |
Everything else flexes. A client desperate to see their landing page can have assets pulled forward. Someone with no existing list skips migration. But the rows above are not negotiable, and a builder who offers to rearrange them is telling you something about how they handle risk.
QuestionsFrequently asked questions
What is A2P 10DLC and why does it delay my launch?
A2P 10DLC is the framework US carriers require before a business can send automated texts from a standard 10-digit local number. It has two stages: brand registration, which verifies who the business is against its EIN, and campaign registration, which reviews what will be sent and how people opted in.It delays launches because approval is entirely outside your builder's control, rejections restart the clock, and most people submit it in week three instead of day one. Submitting on day one means the waiting happens in parallel with everything else.
Why did our A2P registration get rejected?
In rough order of frequency:Legal name or address not matching IRS records exactlyNo privacy policy on the website, or one that permits sharing data with third partiesOpt-in that cannot be demonstrated: no visible consent checkbox on the formSample messages missing HELP and STOP languageWebsite unreachable or still a holding pageMost are fixable in an afternoon, but each round trip costs days to weeks, which is why the details are gathered from documents at intake rather than typed from memory.
How long does onboarding take?
Three to four weeks for a standard build. The limiting factor is almost never the building. It is A2P approval and email warm-up. A client who returns intake and access on day one, with a live website and copy ready, lands at the fast end. One who takes two weeks to send a logo does not.
What do you need from me, and when?
Day one: exact legal entity details and EIN, domain or DNS access, logo and brand, existing contact list with opt-out history, and a live website with a privacy policy.By week two: payment processor, Google Business Profile, calendars for anyone taking bookings, ad accounts, and message copy if you are writing it.Total client time is usually two to four hours across the project, concentrated in week one and in testing.
Will this disrupt what we are running now?
No, and the sequence is built to guarantee it. Funnels go on a subdomain so the existing website is untouched. Email goes on a dedicated sending subdomain so campaign reputation never affects your day-to-day mail. The phone number ports last, not first. Nothing is switched on until tested, and launch is staged across several days rather than flipped at once.
Can we import our existing contacts?
Yes, with care. The import runs with every automation switched off, after a twenty-record sample has been checked field by field. Suppression history, meaning anyone who unsubscribed, bounced or asked not to be contacted, has to be carried across deliberately, because it does not travel automatically and messaging those people is a legal problem, not just a rude one.
Do you need our passwords?
No. Everything is requested as an invited user on accounts you own, so access can be withdrawn the day the engagement ends without changing a single password. If a builder asks for shared credentials or a texted 2FA code, that is worth questioning regardless of who they are.
What happens after launch?
Checkpoints at day 7, day 30 and day 90. Day 7 catches anything firing incorrectly and confirms integrations are still connected. Day 30 is the one that matters most, because it checks whether the system is being used rather than sitting beside the old way of working. Day 90 asks what should change now there is real data to look at.
What is the most common cause of delay?
Three things, in order: an A2P rejection from incorrect business details, a missing privacy policy blocking campaign approval, and waiting on message copy when the client is writing it. All three are solved by front-loading the request, which is why intake asks for documents rather than answers.
We already have a GoHighLevel account that is a mess. Is this the same process?
Mostly, with an audit phase in front of it. Existing accounts usually already have A2P sorted, which removes the longest wait, but they arrive with duplicate contacts, half-finished workflows and tags nobody can explain. The audit maps what exists before anything is changed, and that map is frequently more valuable to the client than the rebuild that follows.