Guides
21 guides on service operations. Practical writing from the team building Atlas, useful whether or not you buy anything.
A major incident is one whose impact is large enough that the normal process cannot handle it. It calls for a different level of organisation, set up before it is needed.
A team of five has the same kinds of work as a team of five hundred: requests, outages, problems and changes. It needs the habits, not the apparatus.
Triage turns a pile of requests into an ordered queue with owners. It is quick when the rules are written down and slow when every request is a negotiation.
A service level agreement is a promise. Make it one you can keep, measure it honestly, and report misses without defensiveness.
A service desk is the single point of contact between the people who provide a service and the people who use it. Good ones make requests easy, answers fast and patterns visible.
Most ITSM purchases go wrong by starting from a feature matrix. Start from the practices you will run, then check which requirements they impose.
IT service management is how an organisation designs, delivers and improves the IT services that other people rely on. It is a set of habits before it is a tool.
A known error database holds the failures you already understand and how to get around them. Its value is measured at three in the morning, by whoever is on call.
Incident management restores service. Problem management removes the reasons the incidents keep coming. Without it, a team can respond brilliantly and still be woken by the same failure every month.
When most pages need no action, people learn to ignore pages, including the one that matters. Alert fatigue is a reliability risk and a retention risk at once.
Schedules assume that everyone is available. They are not. A clear, simple swap policy keeps the pager covered without leaving the schedule disagreeing with reality.
Most on-call surprises are handover failures: something the last person knew and the next person did not. A short written handover removes most of them.
There is no single best on-call schedule. There are patterns that suit particular team sizes, locations and paging volumes. Here are five, with the trade-offs of each.
On-call management decides who answers when something breaks, what happens if they do not, and how to ask people to carry that duty without wearing them out.
A review is worth writing only if something changes because of it. This guide gives a structure that leads from facts to owned actions, and a way to keep those actions from being forgotten.
An incident response plan is only useful if it is short enough to be read at the start of an incident. This guide sets out what belongs in it and what belongs elsewhere.
MTTR, MTTA and MTTD are the most quoted incident metrics and the most often confused. Fix the definitions first, then use the numbers as a signal about the system.
People forgive outages more readily than silence. Good incident communication is timely, specific about what is known, honest about what is not, and regular.
The incident commander coordinates the response so that everyone else can concentrate on their part of it. The role is about decisions and focus, not technical brilliance.
A severity scale decides how loudly to respond. Defined well, it removes argument during an incident. Defined badly, it is either ignored or abused.
Incident management is how a team detects a problem, responds in an organised way, tells the people affected and learns enough to prevent a repeat. This guide covers the whole process.
Ready when you are
Atlas brings tasks, projects, CRM, contracts, e-signature, PDF tools, and analytics into one workspace. Start free.