Loading
Support documentation usually explains the settings screen. The settings are not where support goes wrong; it goes wrong in the targets somebody agreed to and the reply library nobody owns.
These start from those, and several of them recommend doing less: fewer queues, fewer saved replies, fewer metrics.
Sequenced, not alphabetised. Each one ends with something configured.
The theme running through these is that support measures what is easy and gets what it measures. Throughput metrics produce fast shallow answers and customers who come back, which the same report counts as more closures.
Designing SLAs and support reporting are the two that matter most, because both are about promising and measuring things you can actually deliver.
The escalation guide is the one with a join in it: a linked task rather than a forwarded email is the difference between answering when and apologising.
Every guide is written to be finished rather than to be impressive: the screen each decision happens on, and the thing that goes wrong if you skip it.
Desk tools →If you are setting Desk up, read designing SLAs first. Almost every later argument with a customer traces back to a target agreed without the arithmetic.
If you are already running it, read support reporting that helps. It is the one that changes what the team optimises for.
No. They are written to be useful against whatever you run today. Several describe decisions that apply to any desk-shaped system, not just ours.
Each has an owner and a review date. Where something has changed, the guide is updated rather than supplemented, so there is one current version rather than a thread of corrections.
Because the limits are the useful part. A guide that recommends everything is a brochure, and the decisions worth taking care over are usually the ones with a real cost either way.
Half an hour with your own data usually saves reading three of these. The guides will still be here afterwards.