Microsoft Delivery Partner Selection: The Scorecard, the Statement of Work and the Exit Clause

By Michael Branson | September 5, 2026

Quick answer. Microsoft delivery partner selection rests on four estate-level criteria: portfolio evidence across workloads, licensing and tenant governance, multi-workload sequencing, and exit and handback. Each one becomes a clause in the statement of work, and a firm that will not sign it has answered the question.

What a multi-workload Microsoft estate changes about the decision

A selection process built to compare capability asks what a firm can do, on which platforms, and with which certifications. It produces a shortlist of firms that can all plausibly do the work.

On an estate that spans several workloads, capability is rarely what fails. What fails is everything between the workloads: the tenant one team administers and another team’s change breaks, the licensing position nobody was made responsible for, and the dependency that sat in two plans and was owned by neither.

So the selection question is not whether a firm is capable. It is whether the specific arrangement you are about to sign will still be true once the program is under way, and whether you can demonstrate to a board or an auditor that you checked.

That changes what belongs on the criteria list, and it changes where the list ends up. Every criterion below was chosen because it becomes a clause somebody signs, and a clause leaves a record. If you are going to own this decision, the file should show that you asked answerable questions and got answers you could check.

The four program-level criteria, and the test for each one

Criterion What you are actually testing How to test it before you sign
Portfolio evidence across workloads Whether the firm has run a Microsoft portfolio, or one workload several times Name the three workloads in your estate with the most traffic between them. Ask which of the three they have run together, on one program, under one plan. A firm with single-workload depth answers with a list of projects where a portfolio was asked for.
Licensing and tenant governance Whether anybody will be accountable for the licensing position and the tenant configuration the program moves Ask who owns the true-up when the program adds seats or changes service plans, and who holds tenant administrative roles while the work runs. Ask for the answer as a named role on their side and yours, not as a process.
Multi-workload sequencing Whether the dependencies between workloads sit in one plan or in several Ask what has to be true in the identity and tenant layer before the second workload starts, and who is accountable for the order when two workstreams need the same change. A firm that plans every workload in parallel and none in sequence is planning a collision.
Exit and handback Whether your team can run the estate on the day the engagement ends Ask what is handed back per workload, and what state administrative roles are in on the last day. Ask to see the shape of a handback pack from a comparable program, with the client details removed.

Nothing in that table requires a reference call. Every test in the last column is a question you can ask in a room, and every answer is either specific or it is not.

When the four disagree. Licensing and tenant governance and exit and handback behave as gates: a firm that will not put a named role against the licensing position, or that cannot describe a handback, does not clear on strength elsewhere. Portfolio evidence and multi-workload sequencing narrow the field without closing it, and where those two pull against each other, sequencing wins, because portfolio evidence is a fact about somebody else’s program and the sequence is a fact about yours.

Scoring proposals against the four criteria

Proposals arrive written to the same brief, so they read alike. Scoring is what separates them, and the scoring rule is narrow: a criterion scores on the artifact produced, not on the answer given.

Run each proposal across the four criteria and record one of three states against each.

Produced. They answered with something you can read: a portfolio described by workload combination and estate condition, a named role against the licensing position, a sequencing dependency with an owner, a handback pack from a comparable program with the client details removed. Watch what gets redacted. A firm that redacts the client name and hands you the rest is showing you its work. A firm that replaces the deliverable with a sanitized template is showing you a template.

Asserted. They answered confidently and produced nothing. An asserted score is not a disqualification on its own. It becomes one when it repeats across criteria.

Absent. They did not answer the question you asked. Record it as absent instead of re-asking it in a softer form, because the second asking is what turns an absent into an asserted.

The four scores are not a total. Two of them are gates, so a proposal that scores produced on both gates and asserted on the other two sits ahead of a proposal that scores asserted on a gate and produced everywhere else. Where a compliance regime governs the estate, one signal outranks the rest inside every criterion: ask which control changed a design they shipped. A firm that has delivered under the regime names the control and the decision it forced, such as a residency requirement that ruled out a service or an audit logging requirement that changed a retention model. A firm that has read about the regime answers with the regime’s name.

Certifications and partner designations sit outside the scoring. A Microsoft Partner designation is a procurement fact. It tells you a firm meets a program threshold; it does not tell you who will be on your program or how they behave when an estate turns out to be worse than the assessment said. Treat a designation as a filter for the longlist and never as a score on the shortlist.

The Microsoft-specific clauses a statement of work has to carry

A general consulting statement of work covers scope, term, rate and acceptance. On a Microsoft estate it has to carry five more things, and each one is there because it is what turns ambiguous at the boundary between workloads.

Tenant administrative access, and who holds it. Name the administrative roles the partner will hold, in which tenant, for how long, and what returns them. Standing global administrative access for the length of a program is a decision, and it should be a decision somebody signed, not a convenience nobody recorded.

Licensing responsibility. Say who is accountable when the program changes the licensing position: added seats, a service plan change, a workload that moves users into a different entitlement. The partner can own the recommendation, or the execution, or neither, and all three are workable. What is not workable is the version where the true-up arrives and the answer is that it was assumed.

Workload boundaries, and the order between them. State which workloads are in scope, which are adjacent and out of scope, and which dependency has to be satisfied before the next workload starts. An out-of-scope workload named in the document is worth more than a scope list that names only what is in.

The evidence artifacts, and who writes them. Compliance work produces paperwork somebody has to own. Say whether the client team writes it, the partner writes it, or the document is silent, because silent means it gets written the week of the audit. Name them: the architecture decision records, the control mapping, the test evidence.

Named individuals, with allocation. Roles, allocation percentage and start date, in the statement of work and not in an appendix. A firm that will commit capability but not names is telling you which of the two it can guarantee. Verifying that those names survive contact with the program is the next section.

How to verify the people named in the proposal are the people who arrive

The failure has one shape: senior people at the proposal stage, other people at delivery. Whether or not anyone intended it, it is a scheduling outcome, and it becomes your problem because nothing in the document made it anyone else’s. Across several workloads the check has to be made per workload, because a firm can staff its strongest workload well and cover the rest.

Ask for the names against the workloads, not against the program. A named architect on the program is a name. A named architect on the workload carrying the most dependencies is a commitment.

Establish who can reassign them, and across which accounts. If a delivery manager can move your architect onto another account without telling you, the names in the document are decoration. Ask what notice you get and what you can do about it.

Ask what happens when a named person leaves. People leave programs, and the document is where that is handled. Ask for the replacement standard, an overlap period, and who signs off that the replacement meets it. A firm that runs programs of this size will have an answer ready, and one that does not has just told you something.

Find out whether any part of the team is subcontracted, and to whom. This is a governance question, not an insult. You need to know whose employment relationship sits behind each person who will hold access to your tenant, because that determines who you can escalate to and whose background check applies.

Ask which of the named people has run this workload combination before. Not the firm. The individuals who will be on your program. Portfolio evidence held by somebody who is not assigned to you is not evidence you have bought, and where a compliance regime governs the estate the same question applies to it.

Meet the delivery lead before signing, not the account lead. Ask that person to walk you through the first sixty days: what they would need from you in week one, what they expect to find that the assessment missed, and what would make them raise a flag. An account lead answers that in outcomes. A delivery lead answers it in dependencies.

What the exit clause has to say so the estate runs without them

Exit is the criterion buyers write last and need first. It decides whether the program leaves you with an estate or with a dependency, and it is the cheapest thing to negotiate before signature and the most expensive to negotiate after.

Administrative roles return on a date, not on request. State the date relative to the last delivery milestone, state which roles, and state who confirms the removal. A partner still holding administrative access after the engagement ends is not yet a security finding, but it is an open loop that becomes one.

Each workload leaves a runbook your team can operate from. Not a design document. The operating instructions: what runs on a schedule, what breaks it, what to check first, and who was called last time. Ask for the shape of one from a comparable program.

Licensing ownership transfers explicitly. Whoever held the recommendation during the program hands it back, with the current position written down and the next renewal date on it.

The estate is demonstrated, not described. Ask for a session in which your team performs the routine operations while the partner watches. A demonstration with the roles the other way round tells you nothing. That session is where you find out what the runbook left out, and it belongs before the last invoice rather than after it.

A firm that has planned its own exit into the proposal is telling you it has done this before. A firm that treats the question as premature is telling you something as well.

Where i3solutions is not the right partner

Four kinds of work sit outside what i3solutions does, and it is faster for both sides to say so before a proposal exists than after.

  • Ongoing managed IT operations. Help desk, backup and disaster recovery, managed security operations, and MSP-style packages are not services i3solutions provides. If what you need is a run function and not a delivery function, a managed services provider is the right shape of firm.
  • Non-Microsoft-platform staffing. Python, React and data science staffing sit outside the practice. Integration work that reaches from a Microsoft estate into non-Microsoft systems is a different matter and is squarely in scope; supplying engineers for a non-Microsoft platform is not.
  • Certification assessments and certification-outcome guarantees. i3solutions does not perform certification assessments and does not guarantee a certification outcome.
  • GCC High tenant provisioning. That provisioning is performed by a certified AOS-G supplier. i3solutions works alongside one and not in place of one.

One thing worth stating plainly. Delivery is senior and US-based. Entirely US-based, every employee, every project, every technology, with no practice-by-practice qualification.

Frequently Asked Questions

How do we score Microsoft partner proposals that read alike?

Score each proposal against the four estate-level criteria: portfolio evidence across workloads, licensing and tenant governance, multi-workload sequencing, and exit and handback. Record produced, asserted or absent against each, scoring the artifact produced and not the answer given. Licensing and tenant governance and exit and handback behave as gates, so a produced score on a gate outranks a produced score anywhere else.

What must a Microsoft consulting statement of work contain for a regulated estate?

Five things a general consulting statement of work leaves out: the administrative roles the partner will hold and what returns them, who is accountable for the licensing position when the program changes it, the workload boundaries and the dependency that gates the next workload, the evidence artifacts the compliance regime requires and who writes them, and named individuals with allocation and start date.

Who should hold tenant administrative access during a partner-led program?

Name the roles, the tenant, the duration and the event that returns them, in the statement of work. Standing global administrative access for the length of a program is a decision that should be signed rather than assumed, and the exit clause should return those roles on a date relative to the last delivery milestone, not on request.

How do we verify the named team in a Microsoft proposal is the team that arrives?

Ask for names against workloads, not against the program, ask who can reassign them and across which accounts, ask for the replacement standard and overlap period that applies when someone leaves, ask whether any part of the team is subcontracted and to whom, and ask which of the named individuals has run this workload combination before.

What does a Microsoft engagement exit clause have to say?

That administrative roles return on a date and somebody confirms the removal, that each workload leaves a runbook your team can operate from, that licensing ownership transfers with the current position and the next renewal date written down, and that your team performs the routine operations while the partner watches, before the last invoice rather than after it.

When is a Microsoft delivery partner the wrong choice?

When the need is a run function and not a delivery function, such as help desk, backup and disaster recovery or managed security operations; when the platform is not Microsoft and the requirement is staffing rather than integration; when a certification assessment or a guaranteed certification outcome is what is wanted; or when the task is GCC High tenant provisioning, which a certified AOS-G supplier performs.

Related reading

Talk to a senior architect

Bring the shortlist and the questions you have not been able to get answered. If the decision has stalled on proposals that read alike, that is the conversation to have: Talk to a senior architect.

About the Author

Michael Branson co-founded i3solutions and brings executive, operational, and technical perspective to organizations working in complex, secure, and mission-critical environments. His insights focus on business process consulting, automation, data analytics, collaboration, secure operating models, and the operational discipline required to turn technology investments into practical business systems with measurable value.