Most outsourcing decisions are played out in the sales stage: the quote gets compared, the rate gets negotiated, the contract gets signed. But the relationship is not decided there. It is decided in the first 90 days of operation, when the process stops being a slide and starts running with real people and real volume. A well-run transition does not guarantee an excellent service forever, but a badly run one almost always dooms the whole relationship.
The 90 days are not a magic number. They are, in practice, the time a process of medium complexity usually takes to move from "the provider watches how you do it" to "the provider does it alone and with stable quality". Less than that is usually optimism; much more is a sign that something is not advancing.
Before day one: what decides the rest
The transition starts before the go-live date. If the process is not documented —steps, exceptions, decision criteria, systems, escalation contacts— the receiving team will reconstruct it through questions, and every question is a day lost. The quality of the knowledge base the client hands over is the best predictor of how fast the operation performs.
Documenting does not mean writing a hundred-page manual nobody reads. It means putting in writing the decisions that today live only in the head of the person doing the work: what to do when the case does not fit the normal flow, who authorises an exception, what gets prioritised when two things arrive at once. That is what does not transfer just by watching.
Days 1 to 30: knowledge transfer
The first month is not about production, it is about learning. The pattern that works is observation in both directions: first the provider's team watches how the client's team or its predecessor works, and then the roles are reversed —the provider executes and the client supervises—. That second stretch, the reverse-observation one, is the one most often skipped for haste and the one that prevents the most problems.
This month you have to resist the temptation to measure productivity. An agent still learning the process will be slow, and pushing for volume too early produces errors that cost more to fix later than the delay you were trying to avoid. What is worth recording from day one are the questions that come up, because every repeated question flags a gap in the documentation that needs closing.
Days 30 to 60: the team takes on volume
In the second month the operation starts carrying real volume, ideally in steps rather than all at once. Going from zero to full in a day is the most common way to break a transition: the team has no reflexes yet, supervision cannot keep up, and errors pile up exactly when the client is watching most closely.
Here the first honest thermometer appears: not productivity, but stability. Do times and quality hold as volume rises, or do they degrade? If they degrade, the problem is almost never the people; it is the sizing or the documentation, and it is better to slow the ramp than to keep climbing on a base that cannot hold.
Days 60 to 90: stabilisation and baseline
The third month is where the operation should stabilise and, above all, where the real baseline is measured. Only now, with the team running at full volume, does it make sense to agree on service numbers. Signing an SLA before this point means committing to figures nobody has seen yet (how to write an SLA you can meet). The baseline from the first 90 days is what turns a wished-for target into an achievable one.
It is also the month to decide what will be watched permanently. The metrics that matter from day 91 are not the same ones that served during the learning phase (what to measure in a BPO operation from month one). The transition ends when the dashboard stops looking at "how fast the team learns" and starts looking at "how well it sustains the service".
The governance cadence matters as much as the work
A transition with no follow-up rhythm is discovered broken when it is already too late. During the first 90 days the contact frequency has to be higher than the mature service will need: short, frequent meetings at first, spaced out as the operation proves its stability. The meeting is not for reviewing metrics that do not mean anything yet; it is for closing documentation gaps, resolving new exceptions and adjusting the ramp.
The opposite mistake is real too: filling the transition with long meetings where everything is discussed and nothing is decided. The useful cadence is the one that produces decisions —the client closes this gap, the provider resolves this exception, this metric starts being measured next week— and leaves a record of who does what.
Signs the transition is going well or badly
A healthy transition shows in concrete things: the same questions stop repeating, new exceptions drop in frequency, quality holds as volume rises, and the client's team starts spending fewer hours supervising. If at 60 days the client is still correcting the same type of error, the transition is not advancing: it is stuck, and it is worth finding out whether the problem is documentation, sizing or profile.
The most underrated warning sign is early attrition on the provider's team. Changing people in the middle of learning resets the clock: every replacement starts the curve over. That is why a stable transition depends as much on retaining the team that started it as on the quality of the process being transferred.
Where smartBPO fits
We treat the first 90 days as a project with phases and owners, not as an informal grace period. We start with documentation before the go-live date, ramp volume in steps, measure the baseline before committing to numbers, and hold a high follow-up cadence at first that relaxes once the operation proves it. We do not promise everything goes perfectly in the first month; we do promise the transition has structure, so problems surface while they are still cheap to fix and not three months later.