Shopping for a managed DevOps support quote is weirdly like ordering at a restaurant with no menu: everyone promises “coverage”, nobody defines it, and the bill arrives with items you don’t remember agreeing to. The cure isn’t cynicism \u2014 it’s a checklist of what a proper quote must spell out, requested in writing from every contender so the answers line up. Here are the eight things we’d never sign without, plus a note on how to make several vendors reveal them all at once.<\/p>\n
“24\/7 support” is a mood, not a commitment. A quote worth reading states response time and resolution targets per severity level, what starts the clock, and what pauses it. Ask specifically: if production is down at 3 a.m. on Diwali, who answers, in how many minutes, with what authority to act? If the quote can’t answer that in a table, the vendor can’t answer it in an outage.<\/p>\n
The proposal deck shows you the principal engineers; the Tuesday-night incident gets whoever is free. Insist the quote names the delivery team or at least the seniority mix, the escalation ladder, and how much of your retainer buys senior hands versus a shared helpdesk. You’re not being difficult \u2014 you’re pricing the only thing that matters in support, which is who shows up.<\/p>\n
Every support relationship has a line between “included” and “that’s a project, extra”. Good quotes draw it explicitly: patching yes, migrations no; pipeline fixes yes, new pipelines quoted separately. Vague boundaries always resolve in the vendor’s favour later, under deadline pressure, when you have no leverage. A vendor fluent in the core principles that make software delivery actually work<\/a> will have opinions about where this line belongs \u2014 let them show that in writing.<\/p>\n One number per month tells you nothing about what happens when you grow. Require the quote to show the cost drivers: per environment, per on-call rotation, per additional service onboarded. Two bundles that look identical at today’s size can diverge by lakhs a year once you add a second product line \u2014 and only itemised quotes let you see that before signing.<\/p>\n Every support price assumes things about your estate: that monitoring exists, that runbooks exist, that staging resembles production. A trustworthy quote states its assumptions; a dangerous one leaves them for the first invoice dispute. Read this section twice \u2014 it is where the real price lives.<\/p>\n Not logos \u2014 specifics. Which clients ran a comparable stack at comparable scale, and what did the vendor’s engineers hold on their own? Role clarity helps you interrogate this: if you know which responsibilities hide behind each DevOps job title<\/a>, you can ask whether “SRE coverage” means an actual site reliability engineer or a rebadged sysadmin, and the answer will tell you plenty.<\/p>\n How do you leave? Notice period, handover obligations, who owns the runbooks and automation written during the engagement, and what the final month costs. Vendors who document the exit cleanly are paradoxically the ones you’ll keep longest \u2014 clean exits are the mark of a shop that competes on service, not on lock-in.<\/p>\n4. Unit pricing, not just the monthly bundle<\/h2>\n
5. The assumptions paragraph<\/h2>\n
6. Proof they’ve supported your shape of stack<\/h2>\n
7. The exit terms, while everyone’s still friendly<\/h2>\n
8. A price that answers your document, not theirs<\/h2>\n