Every ticket is ready before a tech opens it.

A client replies and the ticket comes off Waiting Client straight away, instead of sitting there until someone notices.

It only uses statuses already on your board, and writes a line saying why it moved. It can't close, cancel, or bill anything. If your system is busy, it waits and tries again.

The internal note is written too. A ticket on its way to a tech arrives with the work note and a time estimate already drafted from the conversation, so your tech edits a note instead of writing one. It never goes to the client.

Disk space, missing updates, warranty: pulled from your RMM and already on the ticket when your tech opens it.

It watches your computers too, and opens tickets before clients notice. If there's a known fix, it offers to run it and names the machine. A tech clicks Run, or nothing happens.

A lot of what reaches the queue is not a request: routine device status messages that open a ticket every night, supplier mail, replies with nothing in them. When your techs dismiss the same sort of message a few times, it stops arriving.

Nobody maintains a list. It compares each new message with the ones your team has already decided on, and only sets one aside when it is confident. On day one it is confident of nothing, so everything goes to a person. Correct it once and it remembers.

Anything that reaches a client, or touches a computer, waits for a person. Approve it and the card becomes a record of who said yes, and when.

Nobody has to sit watching a queue. Every new ticket posts into a channel you pick, already sorted, with everything a tech needs to decide without opening anything else.

On the card. The ticket number and a link straight to it, the client and who asked, the problem in one line, urgency and category, what the client actually wrote, and the handoff your tech would otherwise have to write themselves.

Decided in the same place. The buttons are on the card. Approve a reply, deny it, or merge a duplicate into the ticket it belongs to, and the card rewrites itself into a record of who did it and when.

Microsoft Teams, Slack, and Google Chat. Pick the channel. A quiet desk stays quiet; nothing is posted twice.

Tickets arriving in chat is half of it. The rest of the day's running happens in the same place, so nobody opens the board to find out where things stand.

A briefing before anyone starts. One short write-up of the day: what is close to breaching, today's appointments, what is ready for a tech, what has been escalated, who hasn't replied since last week, and anything your monitoring has turned up. It reads the queue and writes it up. It changes nothing.

Ask it about any ticket. Type the question in the channel and get the answer from the ticket itself. It answers from what is on the ticket and nothing else, and if it doesn't recognise the one you named, it says so rather than guessing.

Pull a ticket up for review. Ask it to review a ticket by number and the approval card comes back, whether or not it was posted the first time round.

Every desk has the same two piles: tickets waiting on a client who has gone quiet, and tickets that are finished but still open because nobody pressed the button.

One nudge, not five. A client who hasn't come back gets a single chase after a set number of hours, written and then held like every other client email, so a person still decides it goes. Longer still and the ticket is parked rather than left rotting in the queue.

Finished tickets close themselves. When a client replies to say the fix worked, the ticket closes, and the reason it closed is on the ticket.

Nothing happens quietly. Both leave a line in the trail, so the answer to "who closed this?" is never "the system, at some point".

It reads your techs' real calendars and looks for the earliest gap long enough to hold the work. Whoever that gap belongs to gets the job. Something urgent takes the next slot on the desk, not the next one someone gets round to.

One time per technician, not two from one diary. Every tech who can take the job offers their soonest opening, so the client picks between people and a client who can't do the morning doesn't cost you a day of emails.

Never a time that misses the deadline. Options that land past the ticket's resolution target aren't offered at all, because booking one would guarantee the breach. If nothing fits, that's a flag for a person, not a slot for the client.

Nothing is offered twice. Every time offered is held the moment it is sent, and the ones the client doesn't take are freed the second they choose. Two tickets drafted a minute apart can't be given the same hour.

Outlook and Google Calendar. Times are shown to the client in their own local time, and the appointment lands on the tech's real calendar once it's agreed. Working hours come from Outlook itself, so a tech sets their hours once, where they already set them, and time off is just what's on their calendar.

The invite is safe to send. The client is an attendee, so what your tech writes internally would land in their calendar. It doesn't: the invite restates only what the client told you. The strategy, the time estimate, the priority flags and anything about other clients stay in the handoff your techs see.

Every client is a little different, and the difference is usually the part a new tech gets wrong. What you know about an account is kept against the account and read on every ticket that comes from it.

What it holds. Working hours and when you may not touch anything, what counts as an emergency there, the line-of-business software and how its vendor is contacted, how remote access is allowed to work, who signs off on licences, and whatever else your techs have learned the hard way.

It changes the answer, not just the notes. The same request from two clients can come out with a different urgency, a different time offered, and a different reply, because their rules are different.

You can read every word of it. It is written down against the client and edited by your techs, not learned in the dark. A whole client can also be flagged priority, so nobody there waits behind a busy queue.

A practice with no computers should not be offered the same three o'clock everyone else is offered. When the desk is booked solid, the only way to see an outage sooner is to move something, and moving something means telling a client. That is a decision with a person's name on it, so it is put to one.

It only asks when it is worth asking. A bump is proposed when it gets the emergency seen meaningfully sooner than the next free gap: an hour or more by default. If waiting costs ten minutes, nobody is moved.

Most of the time nobody is moved. Moving a client is the last resort, not the trick. First it tries to hand the routine job to a front-line tech at the same hour. Same time, same day, different name on the calendar, so there is nothing to apologise for. Then a front-line tech who can do it sooner. Only when neither exists does anyone's appointment shift.

Seniority is a thing it knows. Mark each tech front-line through to most senior. Emergencies go to the most senior available; routine work goes to the front line wherever it can, so the bench you need in a crisis is already free before the crisis arrives.

Pushing back never eats the SLA. If a job has to move later rather than sideways, it moves to the latest time that still clears its resolution target with the warning margin intact, and the client is told the new time, not asked to start again.

What it will never touch. Another emergency. Anything starting within the next couple of hours, because that client can't react in time. And anything on your tech's calendar that Triage IT didn't book. Their dentist appointment is not a slot to be won.

The client who was moved is somebody's job. Their ticket goes back into the channel with the team tagged, so nobody assumes it was handled. The apology is written (urgent incident, no other client named, what times suit you) and it waits for a tech to send it like every other client email. From the same card a tech can offer a new time, or claim the client and pick the phone up instead.

1. 01Work out who it is from Matches the sender to a client and a contact.
2. 02Read anything attached Screenshots, a forwarded thread. The wording lands on the ticket.
3. 03Work out the problem and how urgent One line saying what is wrong, and a priority you can argue with. Plain rules run alongside the judgement, so someone who has clearly had enough is escalated the same way every time, whatever the model makes of the wording.
4. 04Check your own fix notes Searches what your techs wrote up last time this happened, and the tickets they already solved that look like this one.
5. 05Look up the computer in your RMM Disk space, updates and warranty for the machine they named. If the telemetry already explains it, it stops there rather than thinking harder about a question the machine has answered.
6. 06Spot the deadline "Tomorrow between 11 and 3" becomes a real slot on the ticket.
7. 07Join up duplicates Four people, one outage, one ticket.
8. 08Book the call Reads your techs' real calendars and offers the soonest gap long enough for the job, whoever it belongs to. Something urgent gets the next slot there is, not the next one someone gets round to.

Every step is written down, so you can see what it did.

Watching. Opens tickets before clients notice, heads-up already written.

Screenshots. A client photographs the error. The exact wording lands on the ticket.

Duplicates. Reports of one problem join into one ticket.

Notes. Solved a ticket? The fix is written up to keep or bin.

Starters and leavers. Collects the whole checklist up front.

Calendars. Looks across every tech's real calendar, offers the soonest free gap that fits the work and a second time as a fallback, and holds both so the same slot is never offered twice.

Reporting. How many tickets it handled, and the hours that saved. Each client also gets a monthly write-up you can send them, every figure in it measured from your own ticket timestamps and audit trail rather than estimated. A tech reads it before it goes anywhere.

On a hardware ticket it reads the machine's make, model, serial and cover date from your RMM, checks the cover by serial number, then writes out every route open on that machine: claim it, replace the part, swap the unit, refurbished, new, or fold it into a refresh.

It chooses none of them and it never quotes a price. The full set goes to your sales team, who decide what to put to the client.

Machines long out of cover are marked as refresh work rather than support time, so they stop quietly eating hours. There's a list of them by client.