Agree the MSP Start Date Around the Work That Must Happen First

A prospect wants to switch providers on the first of next month. Your delivery lead has an opening that week. Before you put the date in a proposal, establish what must be ready for your team to take responsibility for the agreed service.

The useful sales question is: “What needs to happen before we can support you on that date?” Work backwards from it with the customer and delivery lead. A calendar opening becomes a workable start date when access, handover, support coverage and approvals line up.

Define what starts on day one

“Start” can mean several different things: project kickoff, installation of management tools, the first day users contact your help desk, or the date your team takes over a particular service. Name each event separately.

Write a short description of the first support day: which users, locations and systems are included, when support is available, how requests reach your team, and who handles work outside that scope. Keep the one-time transition work beside it with its own owner and timing.

For detailed service boundaries, use the security responsibility guide. Carry the agreed responsibilities into the onboarding plan so the delivery team can act on them.

List the dependencies that can move the date

Ask the customer to bring the people who can confirm the current arrangement. Collect the relevant systems inventory, customer approval contacts, incumbent handover arrangements and specialist application contacts. Record what your delivery lead has checked and what still needs an answer.

For each dependency, write four things: the required result, the person responsible, the date needed and the evidence that will establish it is ready. “Access sorted” is too vague. “Customer administrator confirms the approved technician can access the named tenant using the agreed secure account” gives the team something concrete to check.

Avoid putting passwords into a sales worksheet or ordinary email. Use the agreed secure access process and involve the people authorized to approve it.

The NCSC’s guidance for choosing an MSP recommends clear service responsibilities, attention to contract exit terms, backup and recovery arrangements, and access limited to the work required. Those subjects belong in a transition conversation because they affect what the incoming team can actually operate.

Separate customer timing from service readiness

The customer may have a notice deadline, a finance preference and an operational blackout period. Record each against its actual source. A preferred billing date does not resolve an application vendor’s availability or an incumbent’s handover process.

Ask who is confirming the existing agreement’s dates and exit arrangements. Have that person report the relevant requirements to the transition team. Then ask delivery which preparation can begin while those details are being settled and which work depends on them.

Keep support ownership explicit during any overlap. Users should know where to report an issue, and both providers should know which service each is handling at that point.

Work through a changed start date

Consider fictional Alder Design, a 32-person firm asking for a November 1 support start. The incoming MSP has capacity, but the specialist design application vendor can join the handover only on November 4. The customer has also not confirmed who controls its backup administration.

The sales lead brings those two facts to delivery. They agree to begin inventory and approved access preparation first. The customer’s operations manager confirms the current provider’s support coverage and obtains the backup handover details. The application vendor and delivery lead then schedule the application checks.

The revised plan distinguishes the preparation kickoff from the support takeover. It names who supports users in the interval and puts the takeover date after the necessary checks. The proposal now describes a sequence the people doing the work can explain to the customer.

End discovery with a dated next step

Before sending the final proposal, review the dependency list with delivery and the customer’s transition owner. Resolve each item that affects the start date or show precisely how it changes the sequence.

If readiness supports the requested date, confirm the scope and schedule. If it requires a later takeover, explain the missing dependency and the work that can proceed meanwhile. If the customer needs a service your team cannot support, revisit service fit before agreeing the transition.

Finish with one named owner, a concrete action and a date: “Your operations manager will confirm incumbent coverage through November 4 by Tuesday; we will then finalize the support takeover schedule together.” That gives the customer a useful next step and gives delivery a start date built around the actual work.