Outsourcing engagements rarely fail because the provider was incapable. They fail because nobody on the client side invested the attention the first quarter required. The provider trained agents on what it was given, the client assumed the rest was understood, and three months later both sides are unhappy about problems that were visible in week one.
This is a plan for the first ninety days, written from the side of the table that runs launches for a living. It is organised by phase, with the work that belongs to your team and the work that belongs to ours in each one, because the split of responsibility is what most launch plans leave out.
Before launch: write it down
Everything the team needs to know has to exist in writing before the first contact is handled. Contact types in scope and out of scope. What a good answer looks like for each. When to refund, credit or replace, and the limits on each. What escalates, to whom, and how fast. Tone examples, including the phrases your brand never uses. The systems agents will work in, with the permissions each role needs and nothing more.
Most teams discover that their own process is inconsistent while documenting it. Two people on your side give different answers to the same refund question, or the escalation path leads to a person who left last year. That fix arrives before a single contact is outsourced, and it is the first return on the exercise.
On our side, this is where a project manager maps your process, prepares the systems and trains agents around your brand standards. That work is only as good as the material it starts from. Our guide to remote onboarding covers the knowledge-transfer sessions in more detail, and the data security guide covers what to agree about access before anyone logs in.
Days 1 to 14: pilot narrowly
Go live on one contact type or one channel. Not everything, not most things, one. Choose something with enough volume to generate contacts every day and a clear enough answer that quality can be judged without argument. Order status, appointment confirmation, password resets and first-line triage are all good candidates.
Review every contact in the first week. All of them. It is tedious and it is where the expensive misunderstandings surface while they are still cheap. An agent who has learned a wrong interpretation of a policy on day two can be corrected on day three. The same agent corrected in month three has trained the rest of the team.
Keep a daily fifteen-minute call between your owner and our project manager for the first fortnight. The agenda is short: what came in, what was unclear, what was decided, what changes in the documentation as a result. Every decision made on that call gets written into the knowledge base the same day, so the answer exists in one place rather than in a chat thread.
Days 15 to 45: correct drift, then widen
Move from full review to sampling once the first fortnight has produced a stable pattern. Sample across agents, across days and across times of day, not just the contacts that were escalated. Feed corrections back to individuals rather than as general guidance to the group, because general guidance is heard as applying to someone else.
Watch for drift. Drift is the slow change in how a policy is applied when nobody is checking: a refund limit that creeps upward, a greeting that gets shorter, an escalation that starts being handled locally because the agent thinks they know the answer. Drift is normal and it is not a sign of a bad team. It is a sign that the feedback loop needs to keep running.
Only widen scope once quality holds steady for a fortnight at the current scope. Add the second contact type or channel the same way as the first: full review for the first week, then sampling. Widening three things at once because the first went well is the most common mistake in this phase, and it is where programmes lose the quality they had built.
If you cannot see those five numbers at ninety days, the programme is not being managed, it is being hoped for.
Days 46 to 90: set the rhythm
Lock a reporting cadence and a standing review. The daily call becomes twice weekly, then weekly. The weekly review has a fixed agenda and a fixed report, and the report has the same shape every week so that trends are visible without anyone rebuilding a spreadsheet. The monthly review steps back and looks at contact drivers, at what the documentation still lacks, and at whether scope should change.
By day ninety you should be able to state volume, answer rate, resolution rate, quality score and the top three contact drivers without asking anyone. Those five numbers are the test of whether the programme is being managed. Our article on the KPIs that matter covers how each is defined and how each can be gamed, which matters as soon as a number becomes a target.
This is also the phase to test the staffing model against real volume. The forecast that set the initial headcount was an estimate made before launch. Two months of actual data will show whether the peaks fall where you expected, whether after-hours volume justifies the coverage you bought, and whether one contact type is consuming far more agent time than planned. Adjust the schedule and the scope on evidence, and agree with the provider how much notice a change in hours or agents needs, so that the adjustment is orderly rather than an argument.
What to review every week
A weekly review that runs longer than an hour is reviewing the wrong things. The purpose is to catch drift, clear blocked questions and make one or two decisions, not to re-read every contact. The report should arrive before the meeting so the meeting is spent on decisions.
- Volume by contact type, against forecast
- Answer rate and abandonment, by day and by interval
- Resolution rate and the repeat contacts behind it
- Quality score by agent, with the sampled contacts attached
- Open questions from agents that still lack a documented answer
- Escalations sent to your team, with whether each one needed to be
- Changes made to the knowledge base since the last review
Roles on the client side
The programme needs one named owner on your side with the authority to answer policy questions and the time to attend the reviews. When the owner changes repeatedly, the answers change with them and the team learns to wait rather than act. If the owner cannot commit the hours, the launch should wait until someone can.
It also needs a subject-matter contact for each system agents work in, so that a permissions problem or a tool outage is fixed the same day, and a decision-maker for anything commercial, such as a refund above the agreed limit. Write those names down in the escalation document and keep them current.
Failure signs worth acting on early
Escalations arriving without context. The same correction given three times. Reporting that changes shape each month. A named contact who changes repeatedly. Agents asking questions the documentation should have answered. Each is fixable at week four and entrenched by month six, and none of them is a reason to end the engagement. They are a reason to go back to the phase where the problem started and repeat it properly.
The opposite sign is worth naming too. A programme where nothing is escalated and no questions are asked in the first month is not running smoothly. It is running unobserved. Agents who never ask are guessing, and the sampling will find it eventually. Better to find it now.
The day-ninety review
Hold a formal review at the end of the first quarter with both teams in the room. State the five numbers. Compare scope delivered against scope planned. List what the documentation still lacks. Decide the reporting rhythm for the next quarter and which contact types or channels come next. Agree what would trigger a change in staffing, up or down, and how much notice each side needs.
That review is also the point to look back at the business case. The purpose of outsourcing was to reduce pressure, not to create another management problem. If your team is spending more time on the programme than it spent on the work before, something in the phases above was skipped, and the review is where it gets named.
How we run launches
Our engagements follow the four steps above in practice: a call to discuss needs, pain points, timeline and the approximate hours or agents required; a strategy phase where a project manager maps your process, prepares the systems and trains agents around your brand standards; a launch with clear guidelines, quality control, analytics and progress reporting; and ongoing checks and balances through regular reporting agreed up front. The customer support outsourcing page covers what to agree before scope is confirmed, and the first conversation is where the plan for your ninety days gets built.