Solo service desk manager with no agents in a niche technical environment — where do I start?
Posted by yellow_accomplice@reddit | sysadmin | View on Reddit | 13 comments
Hi all, looking for advice on structuring my approach to this role better.
I'm about 2 months into my first service desk manager role and honestly feeling a bit lost. Background is customer support with a brief research internship — total experience maybe 2-3 years — so I'm fairly early careers and this is my first management role.
It's a solo function with no agents, using Jira Service Management. The environment is fairly niche and technical, and the people who resolve tickets are colleagues from other teams rather than people I manage directly. I'm the first point of contact and responsible for the processes, but technical resolution sits with others. The service desk supports users of a digital platform rather than handling hardware or infrastructure issues — think software access, user onboarding, data requests and general platform queries.
My line manager is on the technical side so there isn't much specific guidance on the service desk management side of things. The function itself is also relatively new, so while the basic ticketing workflows, request types and forms are in place, there isn't much else established beyond that. A lot of what good looks like still needs to be defined.
I've done some process building and documentation but mostly when instructed to rather than proactively identifying what needed to be done myself. That's part of the problem — I don't have a strong enough grasp of what the role should look like to know what to work on without being told.
I'm planning to start ITIL 4 Foundation but wanted to ask — for those who've run solo or small service desks in non-traditional environments, particularly early in your career, what would you prioritise? What helped you develop the intuition for what you should be doing?
Thanks in advance.
OneSeaworthiness7768@reddit
We are sysadmins, not help desk managers.
jspears357@reddit
The guy we had doing this basically proactively identified languishing tickets and acted as a customer rep to get attention for them. Do some reporting on tickets over time to track what normal resolution times are by customer, service, and support team. Look for areas that need some change to provide better outcomes, then suggest the changes.
yellow_accomplice@reddit (OP)
Thank you, this is really helpful!
jspears357@reddit
As an influencer not really a manager don’t make demands and expect people to jump. Make process, training, staffing type suggestions, if your ideas don’t stick just carry on tracking, having stats available or published, and make different suggestions. You may even just be prodding sections to come up with their own solutions. Talk to the sections that are doing well and try to learn from their success. Talk to the sections that are struggling and they may show you what their real problems are and what they would do to fix them if they could. Make sure you highlight successes by the support teams, not just harping on pain points.
dhardyuk@reddit
Make the basic data capture your essential and basic requirement.
If the who, what, where, when and why is not captured in the ticket the next pair of hands is going to send it back to you.
If you get walk ups, capture their issue in a ticket and show them that you need a full narrative to be able to move it along. Training the users to provide the useful details every time makes it easier for everyone.
This also means your metrics can be captured to provide useful reports.
ibteea@reddit
mixduptransistor@reddit
You're way too deep in the weeds to be trying to implement ITIL. That is something that will need buy-in from the whole department
tensorfish@reddit
Start with three boring things: request categories that actually mean something, a named owner/handoff path for each one, and a weekly review of backlog age, reopen rate, and ownership by category. Until mystery work stops, ITIL is mostly decorative.
yellow_accomplice@reddit (OP)
This is helpful, thank you! The request categories are already in place — I've been refining them as new request types emerge. What does the weekly review look like in practice for you? Do you track that in a spreadsheet, a dashboard, or just pull it from your ticketing system directly?
yellow_accomplice@reddit (OP)
Thank you!
SlickAstley_@reddit
It seems bonkers that the whole system rides on (what sounds suspiciously like "favours") from these colleagues in other departments to get things fixed.
If I were you, I would push to get a Team and start building a Knowledge base on who knows what about each product/service & how they fix it.
Id be telling my direct report that since there's no groundwork for any official support, you're basically just going to have to see what comes out of the woodwork.. and build processes and knowledge as you go.
yellow_accomplice@reddit (OP)
That's fair, and it does sometimes feel that way! To add some context — it's a fairly specialised platform so the technical resolution genuinely does sit with the engineers and data managers who built and run it. It's less about favours and more that the service desk function is designed to be the front door/ first line of support or resolved less technical issues while technical teams own more complicated resolutions.
The knowledge base point is well taken though — that's something I'm actively building as I learn more. Did you build anything specific early on that helped give you a framework for what to prioritise?
gethelptdavid@reddit
Streamline the inbound support channels so that you can really see the trends.