Run Your Outsourcing Transition With the AI You Already Have

This teaches your assistant the tracker, the columns and the rules, so you don't have to repeat them in every chat. Rule 1 is the whole article in one sentence.

You're helping me run our side of an outsourcing transition.

The transition: [WORK THAT IS MOVING] is moving from [OUR TEAM OR THE CURRENT PROVIDER] to [NEW PROVIDER]. Planned go-live: [DATE]. I'm [MY NAME], [MY ROLE].

Our record is the Transition Readiness Tracker workbook [FILE NAME OR LINK]. On the Readiness Tracker tab the columns are: Area, Readiness item (what has to be true), How we'll know (evidence), Our owner, Provider owner, Needed by, Status, Critical for go-live?, Waiting on our side?, Go-live impact if late (days), Days late (auto), Flag (auto), Notes and next action. Status is one of: Not started, In progress, Claimed done, Proven, Accepted risk, Not needed. The Stakeholder Map tab lists who owns, approves or needs to hear about each part of the transition.

Follow these rules every time:
1. Nothing is Proven because someone says it's done. Proven means our own team has seen the evidence in How we'll know. If the only evidence is the provider's word, the most you can suggest is Claimed done.
2. Every change you suggest names its source: the email's sender, subject and date, the meeting name and date, or the file name. If you can't find a source, say so. Don't fill gaps with guesses.
3. You suggest. People decide. Go/no-go, accepting a risk, changing dates or scope, and anything about someone's job belong to the named decision makers.
4. Anything about individual employees, retention plans, accepted risks, our budget or our negotiating positions is internal only. Never put it in anything written for the provider.
5. Use plain English and short sentences. When I'll paste results into the workbook, give me a table in the tracker's column order with only the rows that change.
6. When something is unclear, list it as a question for me.

Your contract and the provider's plan already contain most of the tracker. The valuable part is what they expect from your side that nobody owns yet.

Read [THE CONTRACT'S TRANSITION SCHEDULE OR SOW], [THE PROVIDER'S TRANSITION PLAN] and my email and meetings about [PROVIDER NAME] or [PROJECT NAME] since [START DATE]. Then compare them with the Readiness Tracker.

Give me:
A. Rows the tracker is missing, in the tracker's column order. Write each Readiness item as something that has to be true ("Access tested by the provider's actual operators"), not a task ("set up access"). Write How we'll know as evidence our team could actually see.
B. Every date or obligation in the contract or plan that isn't on the tracker yet, with the section it came from.
C. Everything the contract or plan expects from our side: data, access, approvals, decisions and people's time. For each one, tell me whether there's a tracker row and whether it has a named owner on our side. Mark these Waiting on our side = Yes.
D. Starter rows that don't apply to this transition, and why.
E. Questions I need to answer to finish the tracker.

Leave an owner blank when you can't find one in the documents, and list it in E.

Transitions rarely fail because of the people in the weekly meeting. They fail because of the privacy review, the audit control or the supplier letter nobody owned.

Build the Stakeholder Map for [PROJECT NAME]. Use my email, calendar invites, meeting notes and [ORG CHART, CONTRACT, TRANSITION PLAN].

For each person or group give me: Stakeholder group, Name(s), Side (Ours, Provider, Both or Other), What they own, approve or decide, Sign-off they give, What they need from us, How often, Channel, Internal only? (Yes or No).

Then check the groups transitions usually forget and tell me which ones have nobody named: executive sponsor; our transition manager; the provider's transition manager and delivery lead; process owners; the people who know the work; the team whose work is moving (through HR); HR and employee relations; a works council or union, if one applies; IT identity and access; information security; privacy and data protection; legal and contracts; finance and the budget owner; procurement or vendor management; internal audit and controls; teams that hand work in or out; business users, customers or suppliers who will notice the change; training and communications; facilities; the outgoing provider, if we're replacing one; the steering committee.

Also flag: anyone who can block go-live but isn't getting regular updates, any sign-off the contract or plan requires that has nobody named, and anyone acting in a role that belongs to someone else. Don't guess names.

This is the chasing, collating and status-updating your transition manager would otherwise spend Monday doing by hand.

Time for the weekly sweep on [PROJECT NAME]. Look at my email, chats, calendar and meeting notes from the last 7 days that mention [PROVIDER NAME], [PROJECT NAME] or anyone on the Stakeholder Map. Compare what you find with the Readiness Tracker.

Give me:
1. Tracker updates: only the rows that should change, in column order, plus a column called What changed and source. Remember rule 1: the provider saying it's done is Claimed done at most.
2. Claims without proof: every Claimed done item and the exact evidence we should ask to see.
3. Our side is late or about to be: items Waiting on our side that are past Needed by or due in the next 7 days, with the owner and the go-live impact in days. If nobody has said what the impact is, write "ask the provider's transition manager".
4. New risks and new items that aren't on the tracker yet.
5. Short nudges to OUR owners of late items: two to four friendly, specific sentences each. Nothing to the provider.
6. Three sentences I can put at the top of this week's update.

Turns every green claim into a specific thing your team can go and see before it's too late to do anything about it.

For every row on the Readiness Tracker that is Critical for go-live and not yet Proven, tell me what proof looks like. For each one give me: what our team needs to see or do (for example, watch two operators handle a disputed invoice from start to finish), who on our side should see it (use the Stakeholder Map), the fastest way to get it done before Needed by, and the one question to ask at this week's review. Put the items with the least time left first.

Green on the outside, red on the inside. This compares the provider's report with what your own records say.

Here's the provider's latest status report: [ATTACH OR PASTE IT]. Compare it with the Readiness Tracker and what you can see in my recent email and meeting notes.

Tell me:
1. Everything the report shows as green or complete that the tracker doesn't show as Proven, and what evidence is missing.
2. Dates in the report that don't match Needed by on the tracker, or what people have said in email.
3. Delays, risks or open items our records show that the report leaves out, including the ones on our side, and anything the contract or plan requires that the report doesn't mention at all.
4. The five questions to ask at the next review, most important first.

Be fair. If the report is right and our tracker is out of date, say so.

Half the decisions in a steering committee are somebody saying "I think we can live with that." This separates real decisions from maybes, and checks who was allowed to make them.

Here are the notes or transcript from [MEETING NAME] on [DATE]: [ATTACH, PASTE OR POINT ME TO THE RECAP].

Pull out:
1. Decisions: what was decided, who decided it, and whether that person has the authority to decide it according to the Stakeholder Map and the contract.
2. Actions: owner, due date and the tracker row it belongs to, or "new row".
3. Risks someone accepted, and who accepted them. These are internal only.
4. Changes to scope, dates, go/no-go criteria or hypercare.
5. Anything that sounded like a decision but wasn't clearly made by someone with authority. List these as open questions.

Then give me the tracker updates in column order and a short recap email for the attendees. Leave internal-only items out of the recap.

Puts the evidence in front of the people who decide, before the date is close enough to make everyone say yes.

Go-live for [PROJECT NAME] is planned for [DATE]. Our go/no-go criteria are: [PASTE THEM, OR SAY: USE THE ONES IN THE CONTRACT]. Using the Readiness Tracker, the Stakeholder Map and recent email and meeting notes, write the pre-read for the go/no-go decision. Don't make the decision.

Include:
- Each criterion: Met (with the evidence), Not met or Unclear.
- Every critical item that isn't Proven.
- Late items on our side and their go-live impact.
- Accepted risks, who accepted them, and whether anything has changed since.
- Whether the people the fallback plan depends on are still available.
- Everyone who has to sign off, and whether each one has seen the evidence.
- The three questions the decision makers should ask.

End with what would have to be true to say go. No recommendation.

Hypercare should end when the service meets the exit criteria, not when the provider needs its senior people for the next deal.

We're in hypercare on [PROJECT NAME]. Our exit criteria are: [PASTE THEM]. Using the provider's performance reports, the tracker and my recent email and meeting notes:
1. Show each criterion as Met, Not met or Unclear, with the evidence and the weeks it covers.
2. List recurring problems and whether they're getting better or worse.
3. Flag anything that suggests the provider's senior people have already moved on.
4. Draft a short note to [EXECUTIVE SPONSOR] saying whether we should extend hypercare or end it, and why. Ending early should need their written approval.

One tracker, four audiences. The provider version leaves out everything that's internal only.

Using this week's Readiness Tracker and the Stakeholder Map, draft this week's updates on [PROJECT NAME]. Write each one for its reader.

A. Executive sponsor: five lines at most. How confident we are about go-live, in plain words; the top three risks; decisions we need from them; what our side is blocking.
B. Steering committee: one page. Progress by area (people, process, technology, governance), critical items not proven, late items and their impact, decisions needed, and risks accepted since the last meeting.
C. Provider: what we need from them and what we owe them this week, with dates. Nothing internal only: no employee details, retention plans, accepted risks, budget or negotiating positions.
D. Business users and other teams: what changes for them, when, and who to ask. Nothing about people's jobs; HR sends that.

Before the drafts, list anyone on the Stakeholder Map who is due an update this week and isn't covered by A to D.