30-60-90 day plan for IT support specialists
On this page
An IT support specialist is many employees' only contact with IT. They reset passwords, set up laptops for new hires, fix printers and email, and decide which problems go up to the administrators. Their mistakes are usually small but visible, and a few are serious: an account reset for someone who was not the account owner, or a device handed out without encryption. A 30-60-90 day plan for IT support specialists should give them access in stages, teach the procedures that prevent the serious mistakes first, and end with a queue they own.
This plan is for the IT manager or service desk lead hiring a support specialist, help desk technician or desktop support technician into an internal IT team. The general structure is in the 30-60-90 day plan template for new hires. If you are hiring the manager above them, see the 30-60-90 day plan for IT managers.
Access in stages, with identity checks first
The help desk is a common target for social engineering, because it can reset passwords and multi-factor methods. A caller who sounds like an executive under time pressure is the classic case. Before a new specialist resets anything for a real user, they should be able to follow the organization's identity verification procedure without shortcuts, and know what to do when a caller pushes back on it. Grant access in steps tied to that.
| Stage | Access | Granted when |
|---|---|---|
| Day one | Ticketing system, knowledge base, remote support tool, read access to device management | Account set up |
| Week one or two | Help desk role in the directory: password and MFA resets, group membership for standard users | Identity verification procedure signed off and practiced on test accounts |
| Month one or two | Device enrollment, software deployment, mailbox and license changes | Several reviewed tickets of each type |
| As needed | Broader administrative rights, on a separate privileged account | Only for tasks the role actually performs, with the manager's approval |
The 30-60-90 day plan
30-60-90 day plan — [Name], IT Support Specialist, [company]
Reports to: [IT manager / service desk lead] Start: [date]
Users supported: [N] across [sites / remote]
Tools: [ticketing], [directory], [device management], [remote support]
Ticket volume: [average per week] Hours: [pattern]
DAYS 1-30 — Learn the environment and the procedures
Goals:
- Shadow [example: 30-40] tickets across the main categories
- Sign off on the identity verification procedure for resets,
MFA changes and access requests
- Build and hand over [example: 3-5] devices using the standard
build and checklist, reviewed by a senior technician
- Learn escalation paths: what goes to which team, and how
- Read the top knowledge base articles; flag the outdated ones
Deliverables by day 30:
- Help desk access granted after sign-off
- List of outdated or missing knowledge base articles
Check-in: day 30, with IT manager
DAYS 31-60 — Work the queue with review
Goals:
- Take tickets from the queue in assigned categories
- Handle new hire setups and leaver offboarding with the checklist
- Write or update [example: 3-5] knowledge base articles
- Cover a support shift with a senior technician on call
Deliverables by day 60:
- Weekly review of their resolved and escalated tickets
- First knowledge base articles published
Check-in: day 60
DAYS 61-90 — Own a queue
Goals:
- Own a queue or category (example: onboarding and offboarding,
or one site) with the team's standard measures
- Identify one recurring ticket type and propose a fix
(example: a self-service guide, a script or a setting change)
- Join the after-hours rotation, if the role has one
Deliverables by day 90:
- Owned queue with measures reviewed against team figures
- Recurring-ticket fix proposed or in place
Check-in: day 90 — full reviewWhat to measure
Ticket counts reward closing easy tickets and pushing hard ones away. Use a small set of measures, compare like with like, and read a sample of the tickets behind them each week. The standards below are examples; use your team's own.
| Measure | Why it matters | Example standard (example only) |
|---|---|---|
| Time to first response | Users know someone is working on it | Within the team's service level for each priority |
| Reopened tickets | Shows fixes that did not hold | At or below the team's rate for the same categories |
| Escalations | Avoidable escalations load senior staff; missing ones delay fixes | Reviewed weekly for whether each one was needed |
| Ticket notes quality | The next person can pick it up | Steps taken and outcome recorded on every ticket |
| User comments | Communication and courtesy | Read weekly with the lead |
A filled example
IT support specialist: Danielle Okafor (invented), one year at a managed service provider, joining the internal IT team of a 600-person company with two offices and many remote staff.
Day 30: Shadowed tickets across password, device, email and access categories. Signed off on identity verification after a practice call where the lead played an impatient executive. Built four laptops with the standard checklist; one was missing the encryption check, which the senior technician caught and she added to her personal checklist.
Day 60: Working the queue for accounts and devices. Wrote four knowledge base articles, including a new one on connecting to the second office's printers, the most common ticket from visiting staff.
Day 90: Owned onboarding and offboarding. Found leavers' licenses were often left assigned for weeks because the HR notice came by email; she proposed adding IT to the HR system's termination workflow, which the IT manager took to HR.
What "on track" looks like
| Checkpoint | On track | Worth a direct conversation |
|---|---|---|
| Day 30 | Procedures signed off; reviewed device builds; knowledge gaps listed | Skips verification steps when a caller is in a hurry |
| Day 60 | Working the queue with clear notes; articles written | Thin ticket notes; escalates everything or nothing |
| Day 90 | Owns a queue at team standards; one recurring problem tackled | Reopen rate well above the team's; avoids users with hard problems |
What the IT team owes the new specialist
- Written procedures for verification, device builds, onboarding and offboarding.
- A named senior technician to review tickets and answer questions in the first two months.
- A knowledge base worth reading, or time to fix it.
- Backing when they refuse an unverified reset, including for senior staff.
Common mistakes
| Mistake | Result | Fix |
|---|---|---|
| Full admin rights on day one | Large blast radius for small mistakes | Staged access tied to sign-offs |
| Verification taught informally | Resets for the wrong person | Written procedure and a practice call before any reset |
| Measured on ticket count | Easy tickets closed, hard ones bounced | Reopens, escalation review and notes quality |
| Thrown onto the queue alone in week one | Inconsistent fixes and frustrated users | Shadowing and reviewed tickets first |
Joiners and leavers: the tickets with the most risk
New hire setups and leaver offboarding look routine, but they are where small misses cause real problems. A joiner without the right access loses their first days; a leaver whose accounts stay active keeps access to company data. Give the new specialist a checklist for each and review their first several against it.
- Joiners: account created from the HR record, not an email; group memberships matched to the role, not copied from a colleague; device encrypted, enrolled and patched before handover; MFA set up in person or through the verified process.
- Leavers: sign-in disabled on the agreed date and time; sessions and tokens revoked; mailbox and files handled as the manager and policy require; device recovered and wiped; licenses removed so the company stops paying for them.
Ask the specialist to record exceptions, such as a leaver whose device was never returned, and bring them to the weekly review. Patterns in those exceptions are often the best recurring-ticket project for day 90.
Adapting the plan
- Desktop support on site: add a walk of every floor and site, the equipment storage and asset tagging process, and meeting room and AV support.
- One-person IT: combine this plan with the administrator duties: backups, patching, vendor contacts and the account inventory.
- Managed service provider technicians: add client-specific procedures and the contract scope for each client, and stage client assignments.
If the role is still open, the help desk technician screening questions and the interview guide for IT support roles cover troubleshooting and communication before the offer. For the administrators the specialist escalates to, see the systems administrator screening questions.
Questions people ask
When should a new IT support specialist get admin rights?
In stages. Ticketing and remote support tools on day one, help desk roles in the directory (such as password resets and group changes for standard users) once they have shown they follow the identity verification procedure, and broader administrative rights only for the tasks the role needs, after reviewed practice. Privileged accounts should be separate from the person's everyday account.
What should a new IT support specialist learn first?
The ticketing system and its categories, the identity verification procedure for resets and access requests, the standard device build and the escalation paths. Those four things decide whether their tickets are safe, consistent and routed correctly, which matters more in the first month than speed.
Which metrics fit an IT support specialist's first 90 days?
Time to first response, resolution time for their ticket types, reopened tickets, escalations that were needed versus avoidable, and user satisfaction comments. Track them from the first month but set targets only after the specialist is working their own queue, and compare them with the team's figures for the same ticket types.
How is this plan different from a system administrator's?
A support specialist's plan is built around users and tickets: devices, accounts, access requests and the service desk queue. A system administrator's plan is built around servers, identity infrastructure and change management. In small IT teams one person may do both, and the plan should include the infrastructure goals as well.