Help Desk Best Practices For A Small IT Team

Help desk best practices are the habits that keep a support queue predictable. Every request becomes a ticket, priority follows impact, users hear back on a schedule, and fixes get written down. Below are ten for a small IT team or MSP, each with one step to take this week.

We build SherpaDesk, a helpdesk and PSA (professional services automation) a small IT team can run alone.

• Rewrote our 2023 tips as ten practices.
• Merged our 2022 post on common helpdesk issues into one table.
• Added identity checks before password and MFA resets.

Key takeaways

• Start with the queue. One ticket per request. One Queue
• A reset is a security event. Attackers call helpdesks to get passwords and MFA reset. Identity Checks
• Fix a repeat once. Review recurring tickets monthly. Monthly Review
• Unlogged time can't be billed. Time On The Ticket

Help Desk Best Practices At A Glance

How we chose

1. Runs on a team of one to fifteen. No dedicated manager, no ITSM project.
2. Helps with a problem you can name. Each maps to a common issue.
3. Starts this week. Add one practice a week.

Put Every Request In One Queue

Email, calls, texts, and hallway asks all become tickets in one place. A request that stays in an inbox often has no owner and no deadline.

A one-person school IT department wrote: "People just email me. I usually reply back 'Please submit a ticket,' but they rarely do." Create the ticket for the user and reply with its number.

This week: forward one support address into your helpdesk, and log the next hallway request yourself.

Ask The Right Questions At Intake

Vague tickets cost time before anyone starts fixing. Ask five questions:

1. Is anyone else having the same problem?
2. Has it happened before, and when?
3. What changed just before it started?
4. Does it happen on another device or network?
5. What can't you do right now?

Write the answers in the user's words. Knowledge-Centered Service, from the Consortium for Service Innovation, asks you to capture "the requestor's context - their perception of the issue."

This week: add the five questions to your ticket form and phone script.

Set Priorities And Publish Targets

Set priority from impact and urgency: how many people are affected, and whether work has stopped. Three or four levels keep the choice quick; our guide to ticket priority levels has a grid to copy.

Then publish targets for each level. Response time is how long you take to respond to an issue; resolution time is how long it takes to resolve once logged. Define up front your coverage hours, when each clock starts, and which pauses the resolution clock allows, such as waiting on the user. Count a technician's first reply as the response, not the automatic acknowledgment.

This week: write your levels, coverage hours, and a first-response target for each level. Our SLA template has the clock rules.

Verify Identity Before Any Password Or MFA Reset

CISA and the FBI describe a group, Scattered Spider, that "targets large companies and their contracted information technology (IT) help desks." Its members pose as employees to get passwords reset and MFA moved to a device they control. They also get carriers to move a user's phone number to their SIM.

Write a verification procedure. One r/msp member's first rule: "no credential or MFA reset ever happens on an inbound request alone." A callback to the number on file is one step, not the whole check, because that number can be swapped. For the second check, the technician contacts an approver the client named in advance, on a channel agreed with them, never by replying to an inbound message. If a check fails, escalate and don't reset.

NIST's SP 800-63B requires a notification to the account owner after account recovery. We recommend notifying the user after every password or MFA reset, too.

This week: add the checks, the escalation, and the notice to your reset procedure. Our helpdesk SOP templates include one.

Let Users Fix The Simple Things Themselves

Microsoft Entra self-service password reset lets users reset their password "with no administrator or help desk involvement." It works for users it's enabled for who register the methods your policy requires; passwords managed on-premises also need password writeback.

How-to questions belong in a knowledge base users can search. When someone follows an article and still gets stuck, update the article. Your current reset load:

This week: if you use Microsoft Entra, enable self-service password reset for a pilot group, have them register their methods, and test one reset. Without Entra, write up one recurring how-to and test it with a user.

Write The Fix Down While You Work

Knowledge-Centered Service says to capture a fix "in the moment," while you resolve the request; writing it up after the fact is "expensive, slow." If you search old tickets for the same fix a third time, make it an article.

This week: turn last week's most repeated fix into a short article.

Give Every Ticket An Owner And A Next Update

Each open ticket needs one owner and a next-update time, even when there's no progress to report. When a ticket changes hands, the update duty moves with it. Reply to each new ticket with its number; our support ticket response examples cover the rest.

When something breaks for everyone, tell users before they call. The notice needs three lines: you know about it, what you're doing, and what they can do meanwhile. Send a second note when it's fixed, and link the duplicates to one parent ticket.

This week: give every open ticket an owner and a next-update time, and tell the user that time.

Close With A Cause And Review Repeats Monthly

Close each ticket with one line on the cause. "Driver update broke printing on two laptops" tells you what to prevent; "driver reinstalled" doesn't. If you don't know the cause, write "cause unknown" and the next step.

Then look for patterns. One r/sysadmin member's team does "monthly ticket reviews to find recurring tickets." For each one, they try to remove the cause, then to automate it, and failing both, they write a runbook. For a bug you can't fix yet, keep one internal article with the workaround.

This week: add a cause line to closing, and book 30 minutes on the first Monday of the month.

Log Time On The Ticket As You Work

For an MSP, time on the ticket is what you bill from on hourly work and contract overage. On fixed-fee contracts it shows what each client costs you. Time logged on Friday is rebuilt from memory, and short jobs get missed. Internal IT teams use the same record to show where the hours went.

The billable hours you never captured are the margin you never made.

This week: add a time entry before you close each ticket, billable or not.

How this works in SherpaDesk

The hour you log on the ticket lands on the invoice

You get a helpdesk and PSA a small IT team can run alone. No contract. No implementation project. No dedicated admin.

You forward your support address to a SherpaDesk dropbox, and incoming emails become tickets. Priorities carry SLA response and completion goals. You log time against the ticket, or reply "cmd time 0.25" to the ticket email. Uninvoiced time collects in Ready to Invoice, organized by the client's contract.

First agent free, forever, with ticketing, time tracking, and invoicing included. Base Camp is $45 per agent per month ($40 billed annually). 14 days free, no card.

Time Tracking In SherpaDesk →

Track A Few Numbers, Not Every Number

Pick three numbers and check them every month: first-response time against your targets, reopened tickets, and whether the open queue grows. Compare each with last month and choose one change to make. That's how you see whether your help desk management works. Our guide to helpdesk metrics shows how to calculate each.

After you close a ticket, ask "Is this fixed?" and "What one thing could we do better?" A "no" is a reopen you would otherwise miss.

This week: put this month's three numbers next to last month's, and pick one to improve.

Common Helpdesk Issues And How The Practices Help

FAQ

What are the most common helpdesk issues?

What are the three common levels of ticket priority?

What's the most important helpdesk metric?

How do you stop users going around the ticket system?

Should users set their own ticket priority?