How do you prioritise non-ticket work when everything is “urgent”?

I was having a 1:1 with one of my Service Manager Accelerator folks and we were talking about all those things that seem to just land on your desk. If you manage a Service Desk (or any operational team inside an MSP), you’ll know what I'm on about.

It’s that growing pile of non-ticket tasks; half-formed queries, “can you just…” messages. Some of them are apparently urgent – you deliver and people forgot they’d asked for it or changed their mind, or they don’t about them again for months; while the urgent ones just sit quietly on the bottom of the pile until everything seems to blow up!

The problem isn’t that the work exists. It’s that it arrives without context, without deadlines, and without a shared way to decide what matters most. So you end up either:

• Reacting to the loudest voice

• Saying yes too quickly (then trying to squeeze it in)

• Or quietly carrying a backlog you can’t see your way through

Anyway, we were talking about all the things they didn’t expect to have land on their plate and how they were unsure what and how they needed to prioritise them, and that’s when I surprised myself this week by remembering the name “Eisenhower Matrix” which is an awesome methodology for prioritising the non-ticket tasks Service Desk Managers get asked for.

It’s a simple framework, but it’s one of those that’s easy to forget until you’re drowning in “can you just…” requests.

And it’s not just useful for day-to-day non-ticket work. You can use the same thinking to determine priorities in meetings, projects, or (shameless plug 😁) a Continual Improvement plan - although Oprising does do a first pass at prioritisation for you.

FIRST: LET’S BE CLEAR WHAT I MEAN BY “NON-TICKET WORK”

I’m not talking about ticket prioritisation – although similar and we do end up with four priorities out of the back of it.

I’m talking about the internal work that gets slung over the fence to Service Desk leadership because it’s “important”, “needs sorting”, or “someone should really own it”. Things like:

• Updating service standards (comms, ownership, escalation, handovers)

• Fixing recurring friction in onboarding and offboarding

• Improving documentation and runbooks

• Sorting reporting requests and dashboards

• Chasing down process gaps that keep creating rework

• Coordinating internal changes that affect how the Service Desk operates

• Customer SIP actions and internal improvement actions that never quite get finished
• Battling it out with Finance for additional training budget because the Sales Team have sold off portfolio and you have no-one on your team trained in that technology
• Having a chat with Little Johnny because he microwaved his tuna fish sandwich for the third time this month

This is the work that improves the Desk… but it’s also the work that gets squeezed out when everyone is busy.

THE EISENHOWER MATRIX (AND WHY IT HELPS)

The Eisenhower Matrix is simply:

• Urgent + Important

• Not urgent + Important

• Urgent + Not important

• Not urgent + Not important

The trick is agreeing what “urgent” and “important” mean for your world.

HOW WOULD YOU DEFINE “URGENT” AND “IMPORTANT”?

It’s definitely worth documenting these as well, for consistency, and if you’re wondering where to start, here’s a starting point:

• Urgent: there is a real deadline, a dependency, or a time-bound risk

• Important: it improves service, has an impact on customers, reduces risk, or frees capacity

Once you agree those definitions, you’ll find that you stop miscategorising tasks based on how you’re feeling that day.

WHAT TO DO IN EACH QUADRANT

• Do (Urgent + Important): Do it now. Clear the next step, start it, and drive it through to done.
• Decide / Schedule (Not urgent + Important): Schedule it. Put it in the diary, assign an owner, set a due date, and agree check-in points — this is where most Continual Improvement lives, and it won’t happen unless you protect time for it.
• Delegate (Urgent + Not important): Delegate it (or redesign it). Challenge “status pings” and drive-by requests — fix them with better standards, not more heroics.
• Drop (Not urgent + Not important): Drop it (or park it). If you keep everything, you’re choosing to delay the important work.

THE REAL PROBLEM ISN’T THE WORK. IT’S THE LACK OF A PROCESS.

If you don’t have a consistent way to intake, clarify, prioritise, and deliver these requests, two things happen:

• The loudest request wins (not the most important one)

• You say yes too quickly, then spend weeks trying to “fit it in”

So alongside the matrix, you need a lightweight handling process.

A SIMPLE PROCESS FOR HANDLING INTERNAL REQUESTS (SO YOU STOP ACCEPTING CHAOS)

When someone slings something over the fence, your first job is to turn it into a workable request.

CLARIFY WHAT’S BEING ASKED (AND WHAT “DONE” MEANS)

Ask:

• What do you want to be different when this is finished?

• What does “done” look like?

• Who needs to be involved (and who needs to approve it)?

If you want to reduce rework, introduce a playback habit:

• “Can you play back what you’ve heard you’re asking for, and what you think the outcome is?”

• “What are the first two steps you’d take?”

• “What might block you?”

Playback feels slightly awkward the first few times. Then it becomes the thing that saves you hours.

ALWAYS ASK FOR A DUE DATE (AND WHAT’S DRIVING IT)

If there’s no due date, it’s not urgent. It might still be important, but it’s not urgent.

Ask:

• When do you need this by?

• What happens if it’s not done by then?

This is where you separate “I’d like it soon” from “there’s a real deadline”.

HOW TO HANDLE ASAP REQUESTS AND SET EXPECTATIONS

A useful phrase to normalise:

• “I can do that by [date]. If you need it earlier, we’ll need to drop or pause something else - what should move?”

This is not being difficult. It’s being honest about capacity.

WHEN THERE ARE BLOCKERS, ASK FOR HELP CHOOSING WHAT TO DROP

If your team is blocked, the answer isn’t “work later” or “work faster”. The answer is a trade-off conversation.

• “I can’t progress this until [blocker] is resolved. Who can help remove it?”

• “Here are the three things I’m holding. Which one should I pause to make room for this?”

That one question stops a lot of quiet resentment and invisible overload.

DELEGATION: DON’T ACCEPT “HERE’S A PROBLEM” WITHOUT OPTIONS

One of the fastest ways to reduce the “slinging” behaviour is to set a simple standard:

• “Don’t bring me just the problem - bring me two options and your recommendation.”

It doesn’t need to be a big business case. A quick format works:

• The problem (one sentence)

• The impact (what it breaks / wastes / risks)

• Two options (with rough effort)

• Your recommendation

This builds decision-making in the team and stops you becoming the bottleneck.

BUT WE’VE GOT TONS OF TASKS IN THE DO CATEGORY!

If you’ve got multiple Urgent + Important items, the trick is to stop treating that quadrant like a to-do list and start treating it like a triage queue. “Do” can only mean “do now” for a very small number of things at once — everything else needs a conscious decision about order, ownership, and what gets paused.

A practical way to handle it:

• Cap WIP (work in progress): pick a hard limit (e.g., 1–2 “Do now” items per person). Anything beyond the cap gets temporarily treated as Decide/Schedule until capacity frees up.
• Rank the urgents: sort by impact + deadline + risk. In MSP/Service Desk terms: customer down / revenue risk / security risk / contractual breach tends to outrank internal “needs an answer” work.
• Make trade-offs explicit: when a new urgent arrives, ask “what are we stopping?” If nothing stops, you’re not prioritising — you’re just adding pressure and extending time-to-fix on everything.

If you want a simple rule set you can say out loud in the presentation, use: “Only a couple of things can be ‘Do’ at once. Everything else is ‘Decide/Schedule’ until we’ve freed capacity — and every new urgent forces a swap.”

WHERE THIS FITS IN A PROJECT PLAN (AND A CONTINUAL IMPROVEMENT PLAN)

If you run projects, the matrix helps you stop the plan becoming a list of “everything we should do”. It forces the conversation:

• What must be done by when?

• What matters most to outcomes?

• What can wait?

• What can we drop?

And if you’re running Continual Improvement properly, it’s the same idea - except you’re applying it to improvement actions, not just project tasks.

IF YOU WANT A HAND WITH THIS, BOOK A CALL

If you’ve got a pile of internal improvement work that keeps getting slung over the fence, and you’re not sure what to tackle first (or how to stop everything becoming “urgent”), book a call with me.

Whether you’ve got a challenge you can’t quite figure out, you want a fresh pair of eyes, or you want a structured way to manage improvement and optimisation, I’m happy to jump on a call and talk it through.