Onboarding a new client into your support operation: the SOP

A support client's first month with you sets the ceiling on the entire relationship. Onboard cleanly and the service feels inevitable — renewal becomes a formality nobody schedules a meeting for. Onboard messily and you spend two quarters apologizing for a first impression that took four weeks to make. The difference is rarely talent. It is whether onboarding lives as a documented SOP or as a memory in a founder's head. Here is the regimen, step by step, with go-live criteria you can put in a contract.

Before kickoff: qualify and scope

Onboarding starts before the signature. During the sales cycle, collect five facts that will shape everything downstream:

• Expected volume — real inbox history if it exists, honest guesses if it does not. Volume drives your tier quote and your staffing plan.
• Channels — where their customers actually write: email, website chat, WhatsApp, Telegram. Every channel is an integration task with an owner and a date.
• Product complexity and release cadence — a stable product with monthly releases needs a very different knowledge-base rhythm than a startup shipping daily.
• Client-side contacts — who answers product questions during setup, and who takes escalations after go-live. No named contact, no go-live date.
• The client's definition of success — response speed, deflection, customer satisfaction, or just "make it stop landing on my desk". Write it down; it becomes the headline of your first monthly report.

Two red flags to catch now, not in week three: a complex product with no documentation at all (sell a knowledge-base build as a preceding project), and any expectation of guaranteed resolution times (promise first-response times inside coverage hours — never resolution).

The output is a one-page scope: channels, coverage hours, SLA tier, knowledge-base scope, go-live date. Both sides sign it.

Days 1–3: access, channels and the workspace

Provision the client's workspace first, because everything else hangs off it. Each client gets an isolated workspace — their conversations, their knowledge base, their settings, never mixed with any other client's. In Ownadesk this is the unit everything is built around: one workspace per client brand, while your team and your AI work across all of them from a single place. Plans include 1, 5 or 10 brands and an additional brand is $29/mo, so provisioning client number seven is a line item, not a procurement cycle.

Then run the access checklist:

• Support email — forwarding from the client's existing address or a new one on their domain, with sender authentication set up so replies come from their name and land in inboxes, not spam folders.
• Chat widget — a snippet the client's team can add through their site or tag manager the same day. Chase this early; "we'll ask our developer" is the single most common onboarding delay.
• Messengers — connect the accounts their customers already use.
• A product test account — your agents and your knowledge-base writer need to see what customers see.

Week 1: brand every surface

White-label onboarding fails on details, so audit like a pessimist. Logo, brand colors, help-center domain (help.theirbrand.com, not a subdomain of yours), email signatures and footers, widget appearance, agent display names. The rule that keeps you honest: walk every surface the client's customers can see — widget, email thread, help center, portal — and if your name appears anywhere, the ticket is not done. Clients are buying "our support got better", and one stray vendor logo undercuts the entire premise.

Weeks 1–2: seed the knowledge base

Do not aim for complete; aim for the top of the distribution. Twenty to thirty articles that answer the questions customers actually ask will outperform a hundred articles written from the org chart. Source them in this order:

1. Import existing docs — whatever the client has, however rough.
2. Mine the inbox history — the last three months of real conversations name your top twenty intents better than any brainstorm.
3. Interview the founder or product lead for an hour — walk the top intents and record the answers in the client's voice.

Structure the result around getting started, billing, troubleshooting and policies, and write every article answer-first: the resolution in the first two sentences, context after. This same corpus becomes the AI agent's training material, so quality here pays twice.

Weeks 2–3: routing, macros and the AI in review mode

Now the operational skeleton: queue and priority rules matching the SLA tier, canned responses written in the client's tone, and a tested escalation path to the named client-side contact.

Then switch on the AI agent — trained only on this client's knowledge base, never on another client's data — and keep it in review mode: the AI drafts replies, your humans approve every one. Review mode is not caution theater. It is how you discover which answer categories the knowledge base actually supports before a wrong answer teaches the client's customers to distrust the widget. Categories earn their way to automatic replies with a track record, one by one.

Week 3: the internal pilot

Before a single real customer sees anything, run a scripted pilot. Your team sends thirty to fifty realistic conversations through the live channels: the top twenty intents, a handful of edge cases, an escalation trigger, an off-hours message. Score four things — correct-answer rate on top intents, the escalation path completing end to end, branding rendering correctly on every surface, and SLA timers counting what you think they count. Fix what failed, rerun the failing subset, and only then talk dates.

Go-live criteria: a gate, not a vibe

Publish the gate list in the SOP so nobody argues on the day:

• All channels live and verified under the client's domain and branding
• Knowledge base covers the top-20 intents; pilot answer-rate threshold met
• AI agent in review mode with a tested escalation path
• SLA targets configured and timers verified against the contract
• Client has signed off on voice, macros and the help center
• Named escalation contacts on both sides, with response windows
• First monthly report date agreed

Any gate red means no go-live — a slipped week costs less than a botched launch. If the client is impatient, soft-launch one channel (chat is ideal) and cut email over a week later.

The first 30 days after go-live

Onboarding does not end at launch; it ends at the first report.

• Week 1: skim the queue daily. Feed every question the AI could not answer into the knowledge-base backlog — the gap report is your work queue.
• Weeks 2–3: graduate answer categories with clean track records from review mode to automatic. Tune macros that agents keep editing.
• Day 30: deliver the first monthly report and hold a review call — volumes, response times against the SLA, resolution rate, gaps closed, next month's plan. The first report is the moment the client decides the retainer was a good idea. Do not improvise it.

Template everything

Every artifact above — the scope sheet, the access checklist, the brand audit, the KB seed structure, the pilot scripts, the gate list, the day-30 report — should live as a reusable template. The second client onboards a third faster; by the fifth, onboarding is a calm, week-numbered march that junior staff can run. That is the real product of an SOP: not a document, but the ability to say yes to the next client without flinching.