Jill in accounting kicks off her month-end close export before she goes to lunch. Not because that's the ideal time to run it. Because the last three times she ran it at her desk at 2pm, it timed out, and she lost an hour rebuilding what she'd done. The network was up every single time. The server was healthy. The application was technically available. IT's dashboard showed green across the board — and Jill had quietly built a workaround into her daily life that the IT team doesn't know about and will never measure.
The IT team declared victory. Jill stopped expecting them to know.
What "the network is up" actually measures
Uptime is infrastructure health. It tells you whether the thing you built is still standing. It says nothing — genuinely nothing — about whether anyone is getting their job done because of it. These are different questions, and conflating them is how IT organizations end up technically excellent and organizationally invisible.
I've walked into organizations where the IT team was proud of their SLA record. 99.9% uptime over rolling twelve months. Patch compliance above target. Ticket closure rates trending in the right direction. And the business had, in the meantime, built a small industry of shadow systems, manual workarounds, and informal tribal knowledge to compensate for everything the IT team wasn't measuring. The gap between "the infrastructure is healthy" and "people can do their work" was enormous, and nobody on the IT side had thought to look.
The ticket closure metric is the most insidious version of this. A ticket closed is not a problem solved — it's an interaction concluded. Those are different things. The ticket gets closed when IT says it's closed. Whether Jill's export now runs reliably at 2pm is a different data point entirely, and most IT teams aren't collecting it.
The service definition nobody wrote down
The root of this isn't laziness or indifference — it's that most IT organizations were never explicitly asked to define what service means in terms of business outcomes. They were asked to keep things running. They got good at keeping things running. They built measurement systems around keeping things running. And at no point in that sequence did anyone force the question: running well enough for whom to do what?
That question requires context that's genuinely hard to acquire. You have to understand what the finance team is doing at month-end. You have to know that the warehouse runs a batch process at 6am that nobody told IT about and that the ERP vendor doesn't support well. You have to understand that the sales team's CRM performance matters most on Friday afternoons when everyone is trying to close before the weekend. None of this is in the ticket system. None of it shows up in uptime dashboards. It lives in the daily habits of people who long ago stopped expecting IT to know about it.
This is the investment most IT teams skip. Not because they don't care — but because learning the organization feels like overhead, and there's always a real incident to respond to. The result is an IT function that is operationally reactive and strategically irrelevant, keeping the lights on for business processes it doesn't fully understand.
The infrastructure is healthy. The organization has quietly worked around it for two years. Both things are true simultaneously, and only one of them shows up in the monthly report.
What changes when you ask the right question
Reorienting around service — actual service, defined as the people depending on IT being able to do their jobs without compensating for IT's limitations — changes what you measure, what you prioritize, and what you talk about in business reviews.
It means the right metric for Jill's situation isn't application availability. It's whether the month-end close runs reliably inside the window she needs it to. Those metrics are correlated but they're not the same, and optimizing for one while ignoring the other is how you end up with a healthy dashboard and a finance team that doesn't trust you.
It means incident severity gets defined by business impact, not by technical scope. A single degraded application that blocks month-end close is more severe than a redundant link failure that IT resolved in eleven minutes with zero user impact. Most IT organizations have this backwards in their escalation matrices, because the escalation matrix was written by engineers thinking about infrastructure, not by someone who understood what the business was actually doing.
And it means the conversation IT has with business leadership changes. Not "here's our uptime for the quarter" — but "here's what we learned about where you're losing time to technology friction, and here's what we're doing about it." That's a different meeting. It requires IT to have gone and learned things. Most IT teams haven't had it.
The question worth asking before the next business review
Find three people outside IT — preferably in functions that run on tight operational cycles, finance, operations, sales — and ask them one question: What do you do differently because of how IT works? Not what problems they've logged. Not what tickets they've submitted. What have they built into their day to work around the constraints IT has imposed on them?
The answers will be more honest than any dashboard you're running. Jill will tell you about the 11:45am export. Someone in operations will describe the spreadsheet they maintain because the ERP report takes twenty minutes to run. Someone in sales will mention that they stopped using the CRM on mobile because it was too slow and now they batch-enter everything Sunday night.
The network was up during all of it. That's the problem.