Triage rules that work: prioritising tickets in help desk software Australia

The triage problem most Australian SMEs ignore

Your help desk software Australia team uses receives 40 tickets by 10 am. The MD's password reset sits next to a printer jam. A client can't log in. Someone's monitor won't wake up. Without a clear triage rule, your team either: (a) context-switches to death, (b) lets the squeaky wheel get the grease, or (c) works longest-job-first and disappoints everyone.

This post gives you a framework that actually sticks. No gut feel. No email shouting. Just a two-axis system you can teach new staff in five minutes and implement in your help desk software today.

The impact-effort matrix: where triage lives

Plot every ticket on two axes:

• Impact: How many people are blocked, and for how long? Does the business actually stop?
• Effort: How long will it take to fix? One minute or one day?

This gives you four buckets. Your triage rule is: work in this order.

Bucket 1: High impact, low effort (do now)

The MD's password reset. A client can't log in to your service. Five staff can't access the shared drive. These hurt the business immediately and take under 30 minutes. These go to the top of the queue every single time. Your SLA for these should be under one hour. No exceptions.

Example: A client reports their email is down (affects their whole team, 10 minutes to reset their IMAP settings). High impact, low effort. Someone stops what they're doing and fixes it.

Bucket 2: High impact, high effort (schedule urgently)

A client's entire network is unstable. Your invoicing system has a genuine bug. The EFTPOS machine won't connect. These block serious work, but they'll take a full day to diagnose and fix.

Your rule: don't jump on these immediately if you're mid-task. But slot them into the next available 4-hour block. If it's 3 pm and it'll take all day, start it at 8 am tomorrow. Communicate the ETA to the client in the first 30 minutes.

Example: A client's file server is running at 95% capacity and slowing everything down (affects the whole office, but you need four hours to identify what's hogging space, archive files, and defrag). High impact, high effort. You start it tomorrow morning and let them know by 4 pm today.

Bucket 3: Low impact, low effort (batch and do)

Password resets for new staff. A monitor that won't wake up. A request for a software install. These take 5–15 minutes and only affect one or two people, or not at all (the work just can't start).

Your rule: don't do these one-off. Batch them. Set aside 30 minutes each afternoon (or three times a week) and knock out 8–12 of them in one go. Your SLA for these is 24–48 hours, not one hour.

Example: A new staff member needs Slack, Monday.com, and Adobe installed. A separate person wants a second monitor. These are low-friction jobs that can wait until your daily 3 pm admin block.

Bucket 4: Low impact, high effort (schedule or defer)

A request to rebuild someone's laptop from scratch. A proposal to redesign the backup strategy. A suggestion to audit all password complexity. These take days and don't block immediate work.

Your rule: put these on a backlog. Review them monthly. Do them when Buckets 1–3 are quiet (rare), or roll them into a planned maintenance window. If the client is screaming, move them to Bucket 2.

Example: A client wants to migrate from one cloud storage provider to another because the old one is "getting slow." It's not actually down. Plan it for next quarter, not next week.

How to apply this without overthinking it

When a ticket lands, ask yourself two quick questions:

• Is the business losing money, or is someone unable to work at all? Yes = high impact. No = low impact.
• Can I fix this in 30 minutes or less? Yes = low effort. No = high effort.

Tag or label the ticket in your help desk software with the bucket name. Your queue should sort by bucket first, then by time submitted within each bucket.

The danger of "urgent"

Never let a client call something urgent. They will. Almost everything sounds urgent to them. Your job is to triage by actual impact, not by how loudly they ask. A client saying "this is urgent" + low impact + high effort should still sit in Bucket 4. Explain why: "We'll schedule this for next week because it won't block your work, and we need a full day to do it properly."

A worked example

9 am. Your queue has:

• Ticket 1: Client's server is throwing database errors (5 people can't process orders) — high impact, probably high effort. Bucket 2. ETA 4 pm today.
• Ticket 2: Someone's Outlook password needs a reset — high impact (they can't email), low effort. Bucket 1. Do now.
• Ticket 3: A request to set up a new printer — low impact (it's a nice-to-have), low effort. Bucket 3. Add to today's 3 pm batch.
• Ticket 4: A request to redesign the entire backup strategy — low impact (current backups work), high effort. Bucket 4. Backlog. Review in two months.

Your team's day: Fix Ticket 2 now (10 minutes). Start investigating Ticket 1 immediately (it's Bucket 2, so it needs a clear ETA fast). At 3 pm, batch Ticket 3 with others. Ticket 4 never interrupts anyone.

No context-switching chaos. No missed deadlines. No clients wondering why their critical issue is invisible.

Making it stick

Write these four buckets on a card and pin it above your desk. Better: add them as workflow stages or labels in your help desk software Australia team uses daily. When someone asks "why isn't this done?", you can point to the triage rule and explain exactly why the Bucket 3 job is waiting.

New staff learn it in their first week. Clients learn it when you explain your SLAs. Your team learns it stops them from saying yes to everything.

This framework works whether you're managing tickets in a spreadsheet or in proper help desk software. The principle is the same: impact and effort decide priority, not volume or panic.