It is 08:00 on a Tuesday and the early-shift technician opens the queue. Nothing dramatic happened overnight. There are eleven tickets, a disk warning that came in at 06:50, a client contact who wants to know why a laptop was rebuilt, and a leaver whose access has to be gone by the end of the day. This is the day most of the year is made of. It is also where the phrase “linked records” either means something or does not, so we are going to walk it hour by hour, and put the four-tool version beside each step.
Each ticket carries the machine it came from, read live from Guardian RMM at the moment the page loads. Not a hostname string somebody typed, and not a copy from a nightly sync; the monitoring platform’s own record, with its last check time beside it. The technician can see which tickets belong to a host that is still unhealthy and which belong to one that recovered on its own, without opening a second tool.
In the four-tool version the same queue is a list of subjects. To know whether web-03 is still unhappy you open the monitoring console, search for it, and come back. Ten minutes a day per technician goes on exactly this kind of copying and checking, which is the first line of the Stack Seams Score for a reason.
Because the intake rule matched on what the monitor saw, not on the words in an email. Rule conditions include the machine name, the name of the check that failed, the host group the machine belongs to and the exit code the check returned. A root-disk check going critical on a host in the sql-servers group routes to the Database queue with the machine attached. No mailbox was parsed and no one triaged it by hand.
The four-tool version has the monitoring tool send an email to the desk’s mailbox, and a keyword rule that looks for “disk” in the subject. It works until the subject line changes, and it never knows which client the host belongs to. Routing on the check, in full.
By clicking connect on the ticket. The credential for the host is pulled from Guardian Vault and injected into the terminal or desktop session server-side; the plaintext never reaches the browser. The permission the technician holds is “use”, not “reveal”, and if the item is sensitive enough the platform asks for a recent step-up authentication first. The session itself is audit-logged with the operator, the host, the mode, and its start and stop.
Four tools: open the documentation product, find the client, find the credential, reveal it, copy it, paste it into an RDP client or an SSH session. The vault recorded a reveal. Nothing recorded what happened to the password after that. Five minutes and an audit gap, each time.
Into the knowledge base, from the ticket. The technician writes the resolution once and publishes it as themselves, already linked to the client and to the machine it happened on. The next time that host, or that client, raises the same thing, the article is on the ticket. Nothing was retyped and nobody had to remember to document it later.
Their own tickets, contracts, invoices and projects, signed in with their own identity rather than a shared password. Because the modules share a platform, they can also see the devices you look after for them, live, and the documentation you have chosen to share. What each contact may see is switched on one control at a time, so a billing contact and a technical contact need not see the same things, and everything a contact does is recorded against their own name. The question about the rebuilt laptop answers itself: the ticket is in their portal, with the machine on it. What a client should see, and what they should not.
One action. There is one identity provider with multi-factor, so there is one place to add someone and one place to remove them. Deactivate the leaver and every session ends, not eventually but immediately, in monitoring, service desk and vault at once. Permissions are granted by action through your groups, applied identically in every module, so there was never a second place where an old grant could survive.
Add up the lines. Ten minutes per technician per day copying device names into tickets. Five minutes and an audit gap every time a password is looked up to be typed elsewhere. One reconciliation a month for a device list that two products disagree about. And the one that has no minute count: the leaver who still has access to the product somebody forgot, which you find out about when it matters. None of this is dramatic. It is Tuesday, every Tuesday.
They do not import your existing documentation in bulk. The knowledge base fills from tickets one fix at a time and from articles you write, and there is no bulk importer from other documentation tools yet. If you are migrating a large documentation estate, that shapes your timeline more than your decision, and it is worth raising on the first call rather than the third.
Thirty minutes on your own worst ticket, walked through one system. No slides unless you ask for them.