Run a readiness review before a new service site launches

A new service site can go live with logins active and phones ringing before anyone has decided who owns the local decisions that keep a queue running. The platform looks the same everywhere, but the people running it on day one do not know each other yet, do not share history, and have not agreed on who calls exception cases or checks quality. A readiness review closes that gap before launch day, not after the first bad week.

Why this conversation goes wrong

A launch date creates its own pressure. Everyone wants to hear that the site is ready, so a status update turns into a checklist of logins provisioned and hardware shipped, and nobody asks the harder question of who is accountable for judgment calls once agents start taking calls. A customer success manager who accepts "we are ready" at face value is signing off on a plan with no owner for the first messy week. The failure shows up fast. An agent hits a case he cannot complete, looks for a supervisor, and finds that no one has been named yet. Escalations pile up in a shared inbox nobody is watching. Two weeks later the launch lead is fielding complaints instead of running the site, and the review that should have happened before launch turns into a rescue after it.

How to prepare

Before you sit down with the launch lead, get specific about what day one actually looks like. Find out which tasks agents will handle without help and which ones need a supervisor in the room. Ask how the new site will receive current knowledge, meaning the workflows, exception rules, and product changes the existing sites already know. A site that opens with stale documentation is a site that will improvise, and improvisation is where inconsistent service starts.

Ask where questions go. Every site needs a named place, a person or a channel, where a confused agent can get an answer within minutes, not by end of day. Then agree on what evidence you will look at during the first two weeks. Incomplete records and unassigned follow ups are good early signals because they show up fast and point directly at a process gap, not a training gap you can fix over months. If the new site is opening because service priorities shifted, pair this review with a look at how you [Reset success goals when service priorities change], since a site with new goals needs early signals that match those goals, not the metrics carried over from an older plan. The same discipline applies if the launch also involves a change to how work gets assigned. A site that opens alongside a new routing setup faces the same adoption risk covered in [Support adoption after a routing change], and it is worth checking both at once rather than treating them as separate problems.

What to say

Bring the launch lead into a direct conversation and press for names, not intentions.

"The site opens Monday and everyone has a login," says Jae, the launch lead.

Morgan, the customer success manager, asks, "Which supervisor will check how agents use the case workflow after their first calls."

Jae says a manager is still being selected.

Morgan replies, "That is worth settling before launch, not after. What do agents ask most at your existing site when a case cannot be completed."

Jae names exception approvals and account access as the two most common questions.

Morgan says, "Let us bring the launch lead and an experienced supervisor together this week. We can set up a day one support route and decide who reviews a small sample of cases at the end of each shift."

Notice what Morgan does here. She does not accept a status update as readiness. She asks for the specific failure mode, the moment an agent gets stuck, and she does not move on until a name is attached to the fix. That is the whole review in one exchange, repeated across a handful of similar questions until every gap has an owner.

Mistakes to avoid

The most common mistake is treating readiness as a technical question. Access and hardware are easy to verify and easy to report on, so they crowd out the harder conversation about who makes decisions. A second mistake is accepting a role instead of a name. "A supervisor will handle it" is not an answer. Ask who, specifically, and if the answer is still open, treat that as the top risk on the list.

A third mistake is skipping the knowledge transfer question. A new site copies the platform but not the two years of exception handling the original site built up through experience. If nobody owns getting that knowledge to the new team before launch, the new site relearns it the hard way, one frustrated customer at a time.

A fourth mistake is picking signals that take too long to show up. If your first checkpoint is a monthly quality score, you will not catch a broken process until a month of customers have already felt it. Pick signals you can see within days, such as unassigned follow ups or a spike in escalations with no clear owner. A fifth mistake is running the review once and calling it done. Staffing changes, a supervisor leaves, a shift gets added, and the ownership map you built before launch goes stale within weeks unless someone checks it again.

How to practice and score it

Run this as a practice conversation before you run it for real. Use a simple board with three columns, task, support owner, and first evidence, and fill it in as you talk. Ask a colleague to play the launch lead and to hold back a name on purpose, the way Jae does above, so you get practice pressing for specifics instead of accepting a vague answer.

Then have that colleague add one launch risk you have not discussed, something like a new site running on a different phone system or a supervisor who has never used the case workflow. Score yourself on whether you caught it in the moment or missed it until later. A strong review ends with every row in the board filled in with a real name, not a role, and a first piece of evidence you can check within the first few days.

This is also a good one to rehearse with an AI counterpart before you sit down with the actual launch lead, since the pressure to just accept "we are ready" is real and worth practicing against. DealSpeak's [Contact Centers practice conversations] let you run this exact scenario, with a counterpart that holds back the name of a supervisor the same way Jae does, so you build the habit of asking the harder follow up question before it costs you a bad first month at a new site.

Close

A readiness review is not a formality before a launch date. It is the moment you catch the gap between a platform that works and a team that knows how to run it. Do the review, name the owners, and opening day becomes a normal day instead of an emergency.

You can rehearse this exact conversation in the Contact Centers practice conversations library before it happens for real. When you have this one down, read Reset success goals when service priorities change next.