Technical response
The quiet truth about repairs is that the actual fix is often the smallest part. A stop that reads as forty minutes of "repair" is usually a few minutes on the wrench wrapped in a lot of waiting. Technical response is about measuring that waiting, and owning it.
Response, not the wrench
Mean time to repair (MTTR) is treated as a maintenance-skill number, but most of it isn't skill, it's the time before anyone was called, the time until a technician arrived, and the time a repair stalled waiting for a part. Improving MTTR by making repairs faster misses where the minutes actually go. Augos splits the maintenance side of a stop into its parts so you fix the right one.
Assist
Augos Assist connects operators and maintenance teams to remove the grey area in unplanned downtime. When an operator can't clear a stop, Assist is how they call for help through the terminal, the request is logged, routed and timed from the moment it's raised. It turns the murkiest stretch of a stop, the handover between operator and technician, into something with a timestamp and an owner instead of a shrug.
Technician response time
Technician response time is the stretch from the call for help to a technician physically at the machine, ready to work. In many plants it's the single largest phase of an unplanned stop, and it's owned by maintenance and supervision, not the operator. Measuring it separately means a slow response can't hide inside a "long repair", and a genuinely fast repair doesn't get blamed for someone taking twelve minutes to arrive.
Wrench time
The repair itself splits in two:
| Phase | What's happening |
|---|---|
| Active wrench time | Hands-on repair, the actual work. |
| Inactive wrench time | The repair stalled, waiting for a part, a permit, a second pair of hands. |
Pulling inactive wrench out of active is what exposes a spares or process problem masquerading as a slow technician. High inactive wrench points at the storeroom, not the fitter.
MTBF and MTTR
Two numbers describe how a line fails and how it recovers. MTBF, mean time between failures, is reliability: running time divided by the number of failures, so a higher figure means longer runs between stops. MTTR, mean time to repair, is maintainability: total downtime divided by the number of failures, so a lower figure means the line is back sooner. They answer different questions, and confusing them hides the real problem, a line can post a healthy MTBF and a dreadful MTTR, or the reverse, and each points at a different fix.
The catch with MTTR is the one this page opened on: most of it is response and waiting, not the wrench. Augos measures it the way it's actually spent, so a high MTTR resolves into the phase that caused it, response, parts, or the repair itself, rather than one opaque average that invites the wrong conclusion.
Other technician insights
Across stops, the platform surfaces MTBF and MTTR by machine, recurring faults worth a permanent fix, response times by team or shift, and the parts-wait patterns behind inactive wrench time, the maintenance view of the same measured events the operators see.
Common questions
What's the difference between MTBF and MTTR?
MTBF measures how often a line fails (reliability); MTTR measures how long it takes to recover (maintainability). A reliability problem and a response problem need different fixes, so they're read separately, never blended.
Isn't a slow repair just a skills problem?
Rarely. Most of a repair's clock is response and waiting, getting noticed, getting a technician there, waiting on a part, not the hands-on work. Splitting active from inactive wrench shows whether it's a skills issue or a spares-and-logistics one.
Do we need more technicians to cut downtime?
Usually not. On most lines only a fraction of stops need a technician at all, and the biggest recoverable block is the response time before one arri