The Eight-Dollar Outage: Why Summit Doesn't Publish SLAs
Last year, a customer site went dark on us for about eight hours.
The fiber feeding that building failed upstream of every piece of equipment we touch. The originating carrier had a problem at their level. There was nothing for our team to fix during the outage itself. We sat with it. We kept the customer informed. We waited for the carrier to bring their network back up.
When the line came back, the real work began.
The customer was upset. As they should have been. Eight hours of darkness in the middle of a business day is real damage, and no amount of "it wasn't on our side" softens that. So we did the only thing we could to deliver them something tangible. We went after the SLA credit.
That meant gymnastics. Our upstream carrier's calculations. Their forms. Their "validated downtime" math. On our side: two executives and a network engineer pulling logs, building the impact case, and stacking it into the claim format the carrier requires. On the customer's side: their executive and their assistant assembling business-impact data and signing escalation paperwork. The combined senior-grade hours spent just trying to translate eight hours of darkness into a number the carrier would accept could have built a small spacecraft.
After all of it, they certified 8.63 hours of impact.
The SLA credit?
Less than eight dollars.
Read that again. We could have ordered a Domino's pizza for what that piece of paper was worth.
Now think about the cost. Five professionals at executive and senior-engineer pay grades spent coordinated hours fighting through a contractual process designed to produce exactly that result. The credit returned would not cover a tank of gas in your office Camry. The math is insulting.
That is the SLA business. That is what we will not sell you.
So we don't publish a Service Level Agreement, and we never will. Not because we are hiding from accountability, but because every published SLA we have studied in two decades is engineered to protect the provider while owing the customer almost nothing of consequence. We deliver accountability a different way: plain-language agreements you can actually read, direct human engagement, public customer feedback as our scorecard, and contracts structured so that if we miss the mark, you can walk away without a fight.
Why Are Service Level Agreements a Pageant?
Here is the open secret about published SLAs. They are not designed to protect you. They are designed to protect the provider from looking bad, while protecting that same provider from owing you anything meaningful.
Look at the numbers. A 99.9% uptime SLA sounds bulletproof. Until you do the arithmetic. 99.9% means up to eight hours and forty-five minutes of downtime per year is "within spec." Try telling that to the customer who was halfway through payroll when the line went dark.
Look at the fine print. Every published SLA I have read in two decades includes some version of the same magic phrase, somewhere around page eleven: the customer acknowledges the realistic limitations of a fixed-price service. Translation: you are signing a piece of paper that says we promise to try, and we guarantee nothing. Your initials right here, please.
This is not me being dramatic. The biggest software vendor selling MSP tools (Kaseya) publishes a sample SLA template they encourage every managed IT provider to hand to customers. It is twenty-seven pages long. Twenty. Seven. Pages.
The introduction states, and I am quoting, that the fundamental premise of the service is "to avoid onsite visits wherever possible, as this drives up the cost of providing support." Their words. The first design priority of the document the customer is about to sign is the provider's cost structure, not the customer's outcome.
Look, we minimize on-site time too. Anybody in this industry who tells you they do not is lying. On-site work is expensive for us, and more importantly it is interrupting for you. Every minute a technician spends at your desk is a minute you cannot do the work you came in to do. So yes, we design our managed IT services packages around remote-first support. The difference is we tell you that on day one, in plain words, before you sign anything. We do not bury it on page five and pretend it is for your benefit. We save cost. You save interruption. The economics are honest in both directions.
Buried on page six is this gem about internet outages: Internet outage is not an emergency priority as it is held with a 3rd party, your ISP, and while we will endeavour to chase this as quickly as possible it is in the end, outside of our control. So if your office goes dark, the contract you just signed politely informs you that it is not an emergency.
Pages fifteen and sixteen cover virus and spyware protection. The promise is identical and worth quoting: while we will make every effort to ensure your machine is safe, we do not guarantee that your machine can not be infected. In plain English: we will try. We guarantee nothing.
You sign that. You initial that. And then you call the help desk when your laptop is melting, and someone reads you the section number where you agreed it might happen.
I am not making any of this up. The template is real. We have seen it in the wild. We will not put one in front of you.
We Are Not the Originator (and Neither Is Anybody Else You're Talking To)
For internet service specifically, there is something nobody tells you outside the industry. Almost nobody is the actual originator of the fiber running into your building.
We are usually the last-mile carrier on top of one of the national fiber providers. Or we are the supporter and aggregator of one of the giant carriers we purchase capacity from. So are most of our competitors. Our customers, by extension, are subject to the SLAs of those upstream providers. And those upstream SLAs really, truly, deeply suck.
So if a local provider shows up with a glossy SLA promising you 99.99% uptime on internet they procured from the same five national carriers everybody else is buying from, they are either misleading you or hoping you will not read the page where they list every act-of-God exclusion that voids the promise. Both are bad answers.
The honest answer is: nobody can promise you better internet than the carrier underneath them. We can promise to chase it faster, escalate harder, and stay on the phone longer than your other vendor would. We will not pretend we are bending the laws of physics.
Why Is Every IT Ticket Ambiguous?
For IT services it is even messier. Every published SLA tries to put every incident into a tidy box: P1, P2, P3, with response targets attached.
Real life does not cooperate.
A user reports "I can't print." That is the ticket. It comes in flagged as a normal-priority printer problem. What is it actually?
- Could be a paper jam.
- Could be a network switch on its last legs.
- Could be a failed hard drive on the laptop.
- Could be ransomware encrypting the print spooler on its way through the network.
Same ticket. Four wildly different responses. If we had committed to a published "all normal-priority tickets get touched within four hours" promise, we just gave ourselves four hours to walk into a cyber attack already in progress.
So here is what we do instead. We publish targeted response times internally. We treat every ticket like it might be the dangerous one until we know better. Our actual measure of success is the experience our customers report after we leave, not a percentage on a quarterly slide.
I know that sounds soft. It is not. It is harder than the alternative, because there is nowhere to hide. We cannot point at a number that says "look, we hit our SLA" and walk away from a customer who is still hurting. The only thing that protects us is making sure the customer is genuinely taken care of. That is the bar.
The way we hold ourselves to that bar is direct. After every interaction with an end user, we ask them to share their experience publicly. Google. LinkedIn. Anywhere visible. We put every customer who leaves us public feedback into a quarterly drawing for an iPad or an Amazon gift card. Why public, and not a private survey we can curate? Because public is the most honest metric there is. Customers who got bad service tell the internet for free. Customers who got remarkable service have to be invited. We invite them, on purpose, and we live and die by what they actually say where everyone can see it. That is a far more brutal accountability standard than any percentage on a contract. It is also the one we actually trust.
We Write in Plain Language Because Your Time Matters
When we say we focus on the human experience with technology, we mean it everywhere, including the paperwork. Every agreement we put in front of you is drafted so a normal human can read it without an IT architect and a lawyer in the room.
There is no scenario in which we are going to slide a twenty-seven page legal document across the table. Your time is not for decoding contracts. Your time is for running your business and making the impact you came here to make.
If we cannot earn your business with plain words and direct commitments, we have not earned your business.
The Real Accountability Mechanism
Here is the part nobody else will tell you. The most important accountability clause in any vendor relationship is how easy it is for you to leave.
We structure our customer agreements, and our agreements with our own vendors, so that if we genuinely miss the mark, it is not painful for you to walk away and find a different technology partner. No hostage contracts. No data ransom. No three-year fine-print prison.
That is not generous. That is honest. If we are not delivering, you should not have to suffer through twenty-three months of mediocrity to escape. The fact that you can leave is precisely what keeps us sharp. That is the accountability that matters. Not the paragraph on page nineteen of a fixed-price service agreement.
Frequently Asked Questions
Why doesn't Summit Technology publish a Service Level Agreement?
Because every published SLA we have read in two decades is a piece of theater designed to protect the provider while owing the customer almost nothing meaningful. The numbers are written to sound bulletproof. The fine print does the work. We refuse to start a customer relationship by handing them a document that feels like a lie before we have done anything for them.
What does Summit promise customers instead of an SLA?
Direct human engagement, plain-language agreements, and accountability based on the experience you actually report after we leave. We measure first response time, time to resolution, and customer satisfaction loops internally. We ask for public feedback after every interaction. And we structure our agreements so that if we miss the mark, you can walk away without a fight.
Are MSP service-level agreements legally enforceable?
Most are technically enforceable but practically toothless. The credit you can claim against a documented outage is almost always smaller than the time you spend filing the claim. We once worked an eight-hour upstream carrier outage through to a properly filed SLA claim and the credit returned was less than eight dollars. The contract was followed. The customer got nothing meaningful out of it.
How can I evaluate an IT provider without comparing SLAs?
Ask four questions. How quickly do you actually respond when something is on fire, not the contractual target but the actual? Can I talk to three of your customers right now? If we want to end the relationship, what does that look like? Show me your agreement: can a normal human read it? If those answers come back vague, defensive, or wrapped in twenty-seven pages of fine print, you have your answer.
What is the Kaseya SLA template?
Kaseya, one of the largest software vendors selling tools to managed IT providers, publishes a sample Service Level Agreement template they encourage every MSP to hand to customers. It is twenty-seven pages long. It states upfront that the design priority of the contract is the provider's cost structure. It guarantees nothing meaningful while requiring the customer to sign acknowledgment of the realistic limitations of a fixed-price service. We do not use it.
What to Ask Your IT Provider Instead
If you are evaluating providers, do not ask "what's your SLA." It is the wrong question. The answer you get back will be a number engineered to make you stop asking.
Ask these instead:
- How quickly do you actually respond when something is on fire? Not the contractual target. The actual.
- What does your customer feedback look like? Can I talk to three of your customers right now?
- If we want to end the relationship, what does that look like? How easy is it to walk away?
- Show me your agreement. Can a normal human read it?
If those answers come back vague, defensive, or wrapped in twenty-seven pages of fine print, you have your answer.
We are happy to take any of those questions. Come ask.
Summit Technology is a Salt Lake City managed technology partner serving startups and growth-stage companies across Utah, building on Microsoft 365, Azure, and an integrated communications stack.