{"id":5406,"date":"2026-11-11T00:50:00","date_gmt":"2026-11-11T00:50:00","guid":{"rendered":"https:\/\/www.devopssupport.in\/blog\/?p=5406"},"modified":"2026-11-11T00:50:00","modified_gmt":"2026-11-11T00:50:00","slug":"support-desk-tooling-revisits","status":"publish","type":"post","link":"https:\/\/www.devopssupport.in\/blog\/support-desk-tooling-revisits\/","title":{"rendered":"A Support Team, a New Alerting Platform and the Case for Return Visits"},"content":{"rendered":"

Consider a support team at a mid-sized online retailer, six engineers who share responsibility for keeping the storefront and its supporting services running. In spring, the company moves the team to a new alerting and ticketing platform. The vendor runs a full-day onboarding. By the end of it, everyone can acknowledge an alert, attach it to a ticket and escalate it. The team lead files a note that training is complete. What follows is a story about how that conclusion turned out to be premature, and how a handful of short returns to the same material changed the result.<\/p>\n

The quiet slide after onboarding day<\/h2>\n

For the first fortnight nothing looked wrong. Alerts were low in volume, and the engineers who had the freshest memory of the training handled most of them. Then a Saturday night incident hit a payment callback service. The engineer on call had attended the onboarding but had not touched the escalation features since. She remembered that a schedule existed, but not how to override it for a colleague who had swapped shifts. Twenty minutes passed before the right person was paged. The outage itself was minor and quickly resolved, but the review that followed was uncomfortable.<\/p>\n

The review did not blame the engineer, and it did not blame the platform. It asked a more useful question: how much of the onboarding day had the team actually retained? The lead ran a quiet check at the next standup, asking each person to describe from memory how to reroute an alert to a different responder. Only two of the six could do it without opening the tool. That result pointed to the cause. A single day of intensive instruction had produced familiarity, and familiarity had faded.<\/p>\n

What the lead changed<\/h2>\n

Instead of scheduling a second full-day session, the lead set up a lightweight pattern of returns. It was built on a simple idea from learning research: material is retained better when revisited after a pause, and better still when the pauses lengthen. The team agreed on three kinds of return.<\/p>\n

The ten-minute recall at standup<\/h3>\n

Each week, one person drew a card with a task, such as reassigning an open alert or silencing a noisy check during maintenance. They described the steps aloud, then did it in a sandbox project while the others watched. No slides, no notes. If they stumbled, the team wrote the sticking point on a shared board.<\/p>\n

The monthly drill on a rarely used feature<\/h3>\n

Once a month, the team picked a feature that only mattered in unusual circumstances: shift override, escalation chains for a different service, or the way to export a ticket history for an audit. Because these features are seldom needed, they are the ones most likely to be forgotten, and the ones most likely to matter at two in the morning.<\/p>\n

The cold run after any gap<\/h3>\n

Whenever someone returned from leave of a couple of weeks or more, they ran two or three tasks in the sandbox before rejoining the on-call rota. It was not a test. It was a refresher, framed as part of the handback.<\/p>\n

How the results showed up<\/h2>\n

By midsummer, the picture looked different. When another incident arrived, this time a slow database replica that triggered a chain of alerts, the engineer on call re-routed two alerts, attached them to a single ticket and brought in the database specialist within a few minutes. In the review, she mentioned that she had practised exactly that move at a standup a few weeks earlier, and the sandbox drill had stuck because she had done it twice, a fortnight apart.<\/p>\n

The lead tracked a modest set of measures: how many people could complete each drill unaided, how long the escalation took in real incidents, and how many questions the team posted in the help channel. Unaided completion rose, escalation time fell, and the volume of help-channel questions tapered off. None of the numbers was dramatic on its own. Together they told a consistent story.<\/p>\n

The objection from the finance side<\/h2>\n

Not everyone was convinced at first. The operations manager asked whether ten minutes a week across six engineers was a cost worth carrying, given how thin the rota already was. The lead answered with the Saturday incident: twenty minutes of delay in reaching the right person is far more expensive than a year of short drills. A benefit nobody had planned for turned up as well. The weekly card drew out small improvements to the sandbox itself, because every stumble ended up on the board and several of them turned into clearer labels, better default schedules and a shared glossary of alert names. The returns were not only maintaining skills; they were quietly improving the setup the skills depended on.<\/p>\n

Over time the drills also changed the tone of incidents. Engineers who had rehearsed a task recently spoke about it with less hesitation on the call, and newer colleagues felt freer to ask for help because everyone had already admitted, in the weekly session, to forgetting something.<\/p>\n

Lessons the team drew<\/h2>\n