IT service desk software: requests, incidents and the parts that get skipped

IT service desk software serves your own colleagues rather than your customers, and that changes the design. The volume is predictable, the users cannot go elsewhere, and most of what arrives is a request for something standard rather than a fault. We do not sell one, so this is a buying and setup guide: the category is mature, and an IT team past a certain size will get more from a cheap service desk than from a shared mailbox and goodwill.

What IT service desk software has to separate

• Requests from incidents. A new laptop is a request with a fulfilment path; email being down is an incident with an impact assessment. Mixing them makes both sets of numbers meaningless.
• A service catalogue, so common requests arrive with the right fields instead of as free text.
• Approval routing for anything that costs money or grants access.
• Priority derived from impact and urgency rather than from who shouted.
• Assignment groups that match how the team actually works, not the org chart.
• Links to the asset record, so the agent can see what the person is using.
• A change route, because most self-inflicted incidents start as an unreviewed change.
• Reporting that distinguishes backlog age from volume — the first is the problem.

What gets bought and never used

Three modules, reliably. A configuration database nobody updates, which then misleads everyone who trusts it. A knowledge base with twelve articles written during implementation and none since. And self-service portals that colleagues bypass because asking in chat is faster — the portal only wins when the catalogue genuinely saves them typing. Before paying for any of them, name the owner and the weekly half-hour that keeps it current; without that, the licence buys an empty room.

Measure first-contact resolution and backlog age, not tickets closed. A team can close a great many tickets by resolving easy ones and letting the hard ones rot, and the monthly volume chart will look excellent while trust quietly collapses.

Setting one up without a project

1. Write the ten most common requests and build a catalogue entry for each with the fields you always have to chase.
2. Define priority as a small grid of impact against urgency, and publish it.
3. Route everything through one intake path, including walk-ups logged after the fact.
4. Set the response and resolution targets you can actually meet, then report against them honestly.
5. Only enable asset and configuration features once somebody owns keeping them accurate.
6. Review the top five recurring requests quarterly and remove the cause of one of them.

Ettex Forms covers the intake end for small teams: one request form per catalogue entry, landing structured rather than as email, with the queue held alongside as owner, state and promised date. It is deliberately not a service desk platform — once request volume, approvals or change control need real workflow, buy the category product and keep the forms as the front door.