A Buyer’s Runbook for Managed Software Support

Executives comparing managed software support proposals are working without a runbook. Every published resource on the topic is sell-side; business media covers the buyer’s confusion without resolving it, and no independent framework exists for holding vendors to a comparable standard. What follows is the runbook the market lacks, structured around four buyer artifacts that force any proposal into a comparable, defensible format.

The core issue is that “24/7 support” is not a defined term. Across leading managed IT and application support vendors, the same phrase can describe materially different service commitments. One proposal’s fifteen-minute Priority 1 response is another proposal’s “commercially reasonable effort during business hours.” One vendor’s “24/7/365” support may exclude specific holidays or limit access to certain technical resources outside business hours. Neither vendor is necessarily misleading. The challenge for buyers is that these differences are often buried in the SLA language that sits behind the marketing claim.

That lack of standardization becomes even more apparent when evaluating service levels. Vendors frequently promote aggressive response targets because they look impressive on paper, while resolution commitments receive far less attention or remain undefined. For a mid-market organization relying on its Enterprise Resource Planning (ERP) system to support a revenue-generating workflow, the distinction matters. A fifteen-minute response only confirms that a problem has been acknowledged. If operations are not restored until the next business day, the business may spend hours without access to a critical system despite meeting the advertised response metric. Without clear resolution targets, buyers are often left evaluating responsiveness instead of actual business continuity.

Pricing introduces a similar challenge, as most support proposals present a straightforward monthly or annual fee, but the scope behind that number can vary significantly from one vendor to another. Activities such as patching, version upgrades, integration troubleshooting, and third-party Application Programming Interface (API) changes are frequently treated as billable work rather than included services. As a result, two vendors with identical base pricing can produce dramatically different total-cost-of-ownership outcomes over the course of a contract. The determining factor is often not the published fee, but where each provider draws the line between covered support and additional charges.

Taken together, these differences make side-by-side comparisons difficult unless every proposal is evaluated using the same framework. Before entering a renewal or vendor selection process, mid-market organizations should normalize each offering across four areas: scope, SLA commitments, escalation procedures, and price-to-scope calibration.

Artifact 1: A Scope Normalization Worksheet

The worksheet allows you to take whatever the vendor puts on paper and reorganize it into a matrix that lists the specific capabilities a mid-market firm needs. That matrix should cover business applications (ERP, Customer Relationship Management (CRM), collaboration, line-of-business applications), integrations between those applications, custom software or in-house tools, endpoint management, and identity and access management. For every capability, the worksheet asks the same three questions:

• Is this included in the base fee?
• What is the specific unit of work covered (tickets, incidents, hours, changes)?
• What triggers billable overage?

Application support and infrastructure support get bundled inconsistently across vendors, which is the most common source of scope confusion at the mid-market level. One proposal treats endpoint management as part of “managed IT” and prices application support separately. Another bundles both under a single tier. Without the worksheet, the buyer signs a proposal that appears to cost less but excludes half of the coverage they assumed they were buying. With the worksheet, three competing proposals resolve into three columns of the same matrix, and the price differences begin to correspond to real scope differences rather than marketing framing.

The worksheet also exposes the items vendors quietly omit. Onboarding and knowledge transfer are consistently underpriced or missing. The first sixty to ninety days of a managed support engagement determine whether the vendor can resolve incidents on the second call rather than the fifth, and proposals that do not itemize discovery, runbook creation, and knowledge base handoff are pricing a first year that will underperform. Change management for the software estate, including version upgrades, patch cycles, and configuration changes, is another common omission, typically pushed to hourly overage. That decision transfers maintenance risk directly to the buyer at the exact moment the buyer was told the arrangement would deliver predictable costs. The worksheet is where an integrated view of the software estate becomes non-negotiable, which is where the second artifact takes over.

Artifact 2: An SLA Definition Standard

The SLA definition standard separates response from resolution, defines the priority tiers in terms the business can operate against, and specifies what happens when the vendor misses a target. Every managed software support contract should distinguish four priority levels, with defined criteria the buyer controls rather than the vendor. Priority 1 covers a business-critical outage, Priority 2 covers significant degradation with a workaround in place, Priority 3 covers minor degradation without material business impact, and Priority 4 covers a request or minor issue. Each level should have a documented response time, a documented resolution time, and a documented escalation trigger.

Response times without resolution times are the failure mode. A “fifteen-minute response for P1” that resolves to “we will engage until resolved” with no target is a promise the vendor cannot be held to. The standard the buyer runbook should require is an explicit resolution target for each priority level, expressed in hours for Priority 1 and business days for Priority 3 and 4, along with a defined process for missed targets that includes root cause reporting and a service credit. The reporting is what matters more than the service credits, because a vendor that will not report on SLA attainment monthly will not treat SLA attainment as a business obligation.

Coverage windows deserve the same explicit treatment. “24/7/365” needs to be verified against a holiday exclusion schedule, weekend on-call staffing, and the geographic location of the responding engineers. For businesses that operate on federal holidays, including e-commerce, healthcare, and logistics, a holiday exclusion in the SLA schedule is a material misrepresentation of the tier the buyer thought they were buying. This is also the section where reporting cadence should be codified, because a monthly or quarterly business review that surfaces ticket volume, resolution time, SLA attainment, root cause trends, and roadmap recommendations is what distinguishes a strategic support partner from a ticket queue.

Security incident response is the item most frequently missing from managed software support tiers. A Priority 1 security event may route to a separate incident response retainer at a different rate, which the buyer often does not discover until an event occurs. The SLA standard should explicitly state whether security incident response is included, what the response and resolution targets are, and how coordination with the buyer’s security team or Managed Security Service Provider is handled. Once response, resolution, and coverage are defined, the next question is what happens when the ticket needs to move.

Artifact 3: An Escalation Path Benchmark

Escalation paths are the layer of the contract that fails first in production and gets audited last. Most managed support contracts say “escalation to senior engineer” without defining what triggers the escalation, how quickly it must occur, who owns the handoff, and how the buyer is informed. Mid-market buyers routinely discover during a 2 a.m. Priority 1 incident that the escalation path is a shared inbox monitored during business hours.

The escalation path benchmark specifies four things for each priority level: the trigger condition (time elapsed, business impact, complexity threshold), the timing of the escalation (must occur within X minutes or hours), the named role or team receiving the handoff (not a shared inbox), and the communication the buyer receives when the escalation occurs. For a Priority 1 incident, that specificity is not optional. If the first-tier engineer cannot resolve the issue within a defined window, the runbook should require that a named senior engineer or engineering manager take ownership of the ticket, that the buyer receive direct notification, and that the escalation chain continue to a documented executive contact if the incident extends beyond a second threshold.

Third-party vendor coordination is where escalation paths fail most often, and where most contracts hedge. When a Salesforce integration breaks because HubSpot pushes an API change, or when an ERP data sync fails because the vendor’s cloud provider is degraded, the managed support vendor’s contractual responsibility often ends at “we will notify the third party.” That is not a resolution, which is why the buyer runbook needs to define who owns third-party coordination, to what SLA, and how the coordinated resolution is tracked back to the buyer’s ticket, all of which is what integrated systems support delivers.

The escalation benchmark also has to define the change management path, because version upgrades, configuration changes, and integration modifications each require a documented change window, a pre-change review, and a rollback plan. Without those controls in place, a vendor push that breaks something in production triggers an escalation that happens too late. Once scope, SLA, and escalation are defined, the buyer can finally have a real conversation about price.

The change management path we described in AI-Assisted Development Changed the Build vs. Buy Math (https://kyledavidgroup.com/insights/), specifically the sustainment discipline that captures 60% to 80% of total cost of ownership across a five-year window, is the same discipline that determines whether a managed support engagement produces a stable software estate or a slow accumulation of technical debt.

Artifact 4: A Price-to-Scope Calibration Table

The price-to-scope calibration table maps typical mid-market application footprints to defensible annual price ranges. It is the artifact that converts “3x to 5x variance” from a market observation into a negotiating position.

A standard mid-market footprint (an ERP system, a CRM system, a collaboration platform, three to six line-of-business applications, and endpoint coverage for 100 to 400 users) should generally land under $150K annually for a well-scoped managed software support engagement that includes credible 24/7 Priority 1 response, defined escalation paths, third-party coordination, application coverage, monthly business reviews, and onboarding. Quotes materially above that line are typically bundling infrastructure services, security incident response, or professional services hours that may or may not be needed. Quotes materially below that line are typically pushing high-frequency work into hourly overage, which will produce a variable cost line that undermines the predictable-cost business case.

The buyer runbook should present the vendor with a three-column view that reflects calibration as a scope-adjusted number: the application footprint the vendor is being asked to support, the defensible annual price range for that footprint at the specified SLA level, and the top three scope inclusions that make the range real (24/7 P1 response, defined escalation, third-party coordination). If the vendor’s proposal is outside that range, the scope is the story and the price is the symptom.

The calibration table is also the artifact that gives the CFO benchmarking authority, and it produces the same defensibility posture we’ve outlined for 90-day AI stack audits. Managed software support hasn’t been benchmarkable for the mid-market buyer for the last decade because no third party publishes normalized ranges. A CFO who arrives at the renewal conversation with a scope-adjusted range for a comparable footprint has a defensible number tied to scope, not to a vendor’s marketing tier.

A mid-market e-commerce operation running an ERP, a CRM, a marketing automation platform, and roughly 180 endpoints receives three proposals ranging from $42K to $185K annually, all labeled “24/7 support.” Without a scope worksheet, the CIO recommends the cheapest option and the CFO approves it. Six months later, a Priority 2 incident interrupts checkout for a full business day because the SLA schedule buried in the appendix defines Priority 2 as “next business day resolution,” and the tier the buyer signed excludes third-party coordination. The financial impact results in lost order volume, refund-driven charge-backs, and a support renewal negotiation the CFO cannot defend against the board. The better approach would have normalized scope, forced all three vendors into the same worksheet, and either raised the low bid into a defensible range or exposed the omissions that made it look competitive.

A logistics firm running an ERP with three integrated line-of-business applications signs a five-year managed support contract with a fixed monthly fee that appears predictable. In year two, the ERP vendor issues a major version upgrade that requires configuration and integration work. The managed support vendor invoices the entire upgrade at hourly overage, adding six figures to the annual cost. The contract technically allows the billing because change management was excluded from the base fee. The better approach would have required change management for the software estate to be included at the SLA level, or explicitly priced as a defined annual budget with a documented review process.

A healthcare operation running a CRM, an ERP, and a patient-facing scheduling application discovers during a Priority 1 incident that the escalation path listed as “senior engineer within one hour” is a shared inbox monitored during business hours only. The incident spans a Sunday. The vendor eventually resolves the issue, but the operational cost, the Health Insurance Portability and Accountability Act (HIPAA) exposure, and the internal executive escalation could have been avoided by an escalation path benchmark that named a specific role, specified a triggered notification, and defined an executive contact at the second threshold. The better approach would have made escalation an artifact the buyer controlled, not a phrase the buyer inherited.

The buyer runbook is most valuable in the sixty to ninety days before contract renewal, which is where vendor leverage sits. Business media coverage of managed services renewal dynamics consistently reports that vendors concede on scope, SLA definitions, and price only when the buyer arrives with a normalized runbook and a defined walk-away point.

The recommendation is to convene a joint CIO, COO, and CFO working session ninety days before the current contract renews, walk the existing agreement through the four artifacts, and identify every clause where the current SLA schedule conflicts with the tier name, where scope is undefined or pushed to overage, where escalation is undocumented or ineffective, and where the price sits outside the defensible range for the application footprint. That single working session, run against the current contract, is typically the highest-leverage exercise a mid-market IT leader can perform in the entire renewal cycle. If the internal capacity to run the session cleanly does not exist, and for many mid-market teams it does not because the operational load is high and the specialized normalization work is unfamiliar, the outside expertise required is not a full engagement but a focused, artifact-driven review. That is the specific use case a mid-market team should consider partnering on.

KDG helps mid-market organizations normalize scope, SLAs, escalation paths, and price against actual business impact rather than a vendor’s marketing tier. The four artifacts described in this article are the starting point, applied to the client’s current contract or the proposals they are evaluating.

The engagement usually opens with a joint working session across the client’s IT, finance, and operations leadership, run against either the incumbent contract or the shortlist under evaluation. That session produces the artifacts, the negotiation position, and the walk-away point. From there, our managed accounting, technology strategy, and software integration capabilities work together to keep the runbook connected to the CFO’s spend defensibility, the CIO’s SLA enforcement, and the operational roadmap the support contract has to sit inside.

Clients who run this process move from a support contract they inherited into a support contract they defined. The CFO can defend the spend. The CIO can enforce the SLA. The COO can trust that a Priority 2 incident will not resolve to “next business day.”

Mid-market leaders looking at a managed software support renewal in 2026 are looking for more than a better tier. They need the confidence to sign a multi-year commitment that the CFO can defend against benchmarks, the CIO can enforce during a Priority 1 incident, and the COO can trust to protect business continuity through the exceptions the previous contract never anticipated. That confidence comes from a runbook that treats scope, SLA, escalation, and price as buyer-controlled artifacts rather than vendor-controlled tiers, and from a support relationship built to operate at that level from the first ticket forward.