A new batch of changes went live in your Salesforce org on a Tuesday.
Scoped, reviewed, staged in a sandbox, and promoted in the appropriate window. An implementation partner did the build, which was the arrangement, and the arrangement was working. Every gate that the changes had to pass, passed. The deployment was a success. No errors fired.
Because nothing was wrong. Not in any sense a check could find.
Then on Thursday, tickets start coming in.
Four different accounts. The same symptom described four different ways, because customers describe what they can see. Your team starts working them. Somebody finds a workaround that will address all four issues. By Friday all tickets are closed, and the closure notes are accurate about what your team did.
No incident was declared. Nobody thought to. There wasn’t an incident. These were tickets, and tickets are what your team handles.
Now pull your MTTR for that week.
It’s fine. Probably better than fine. Nothing in it is false. Every incident it counted, it counted correctly, and it timed each one honestly from the moment somebody knew to the moment it closed.
Tuesday isn’t in that number. It couldn’t be.
MTTR measures incidents. An incident is something a person declared. Declaring one means somebody knew a set of symptoms belonged to a cause. Nobody knew that. So there was no incident to time, and the metric reported faithfully on the definition your company has set.
Your MTTR isn’t lying to you. It’s answering a narrower question than the one you’re asking it.
Here’s the part worth sitting with.
Everything that was reported, reported success. The deployment went in as designed. The checks came back green. ServiceNow can tell you when the change happened and who approved it, and it’s right about both.
Ask any of those systems why tickets started on Thursday.
They have nothing. Not a wrong answer. No answer. It isn’t a question they address.
Monitoring missing nothing and monitoring explaining nothing are two different failures and only one of them gets discussed.
So think about the window between Tuesday and Thursday.
Nothing went undetected because there was nothing to detect. However, your team resolved four tickets without an explanation. The change and the complaints were one event, and nowhere in your stack was there a place that could hold them as one, so they stayed two separate activities.
You’ve probably lived a version of this. The week where everything got handled and the reason for the tickets never surfaced, and it quietly stopped being anyone’s question, because there was nothing open to attach the question to. Most people I talk to describe this before they have a word for it.
If you want a better MTTR, work the incidents you have. That’s straightforward enough and it works.
If you want to know what your operation actually spent their time on last quarter, you need the ones that never became incidents. There is no list. They didn’t fail to get counted; they failed to get connected, and connecting is what counting requires.
Right now, somewhere in your environment, a change is behaving exactly as designed and producing an issue nobody has tied to it. It won’t arrive labeled as a change.
It arrives as tickets.
Teams who can account for every incident on the dashboard, and not for the week where the tickets got handled and nothing ever explained them, are exactly who we’re thinking about.
If that’s your team, we offer a complimentary Investigation Cost Audit. Forty-five minutes. Structured diagnostic across five dimensions. You leave with a scorecard that quantifies what the investigation is actually costing you: in time, in recurrence, and in the answers your team can only produce by hand.