A ticket that knows which rack the broken device is in
Designing an ITSM service desk for a provider maintaining physical estate across hundreds of customer sites — where a ticket carries a location, an asset, a contract and a clock, all on one screen.
GegoSoft designs and builds the interface layer of this platform — the Angular web application and the Android app. Backend services, architecture and product direction belong to the client. What follows describes the interface design and the reasoning behind it.
- CLIENT
- Australian MSP
- DOMAIN
- ITIL-aligned ITSM
- TENANCY
- Multi-organisation
- STACK
- Angular, Android
- OUR SCOPE
- UI/UX, web and mobile
Not a support inbox — a field service operation
Most helpdesk software assumes a ticket is a question. Someone cannot log in, someone needs software installed, someone has a problem with a document. The ticket is text, and resolving it means replying.
This client is a managed services provider. They install and maintain communications and networking estate — intercoms, cameras, network hardware, endpoints, licences — across hotels, hospitals and corporate campuses. Thousands of devices, in hundreds of buildings, belonging to many different customer organisations, under separate service contracts.
For them, a ticket is not a question. It is a physical object in a specific place, belonging to a specific customer, covered by a specific agreement, with a clock already running.
Every design decision on this module follows from that. The ticket form has to carry considerably more structure than a support tool needs, without burying the thing that actually matters: what is broken and how long we have.
Four levels to reach one device
Locating a fault means narrowing from a customer's estate to the exact position of the hardware. The ticket form does that in four dependent steps, each filtering the next, each offering "any" for the cases where the engineer does not yet know.
Cascading selects are unglamorous and consistently underestimated. Four dependent dropdowns have to stay responsive as each choice reloads the next, preserve state when someone changes their mind at level two, and behave sensibly when a caller can only say "somewhere on the third floor". They also sit inside a modal alongside a dozen other fields, so they cannot dominate the form.
The payoff is that the asset picker filters by the location chosen. An engineer does not search a customer's entire device inventory — they see what is actually in that rack. That single dependency removes most of the ambiguity that would otherwise be resolved by a phone call.
The contract decides the clock
A service contract is attached to the ticket, and the SLA travels with it. That is the commercial reality made visible: this customer is entitled to this response time because of what they signed, and the person handling the ticket can see it at the moment they are deciding what to do next.
Counters that run in a list
The ticket list shows elapsed time per row, driven by status. Dozens of independent counters on one paginated screen is a real front-end constraint — they have to stay accurate against server time without each row holding its own timer, and update without the table reflowing while someone is reading it.
Threshold colours are defined by the administrator rather than fixed in the product. Different providers have different ideas of when a ticket becomes alarming, and hard-coding amber at eighty percent would be a guess dressed up as a standard. The urgency language belongs to the business using it.
Two fields that look redundant and are not
Tickets carry both a priority and a criticality, and the difference is deliberate.
Priority
Chosen by whoever raises the ticket, from a list the organisation defines. It is the requester's claim about how urgent this is to them.
Criticality
Set automatically for tickets created by rules, and adjustable by the agent. It is the assessed severity — what the operation actually believes.
Collapsing these into one field creates a familiar problem: everyone selects the highest option, the scale stops discriminating, and the service desk goes back to judging by feel. Keeping the requester's claim and the assessed value separate means both survive — and the gap between them is itself useful information.
Where the service desk meets the contact centre
Every ticket row shows an icon for the channel it arrived on — phone, email, chat, bot. Tickets raised by mail to addresses the administrator defines are created automatically, so a message to a support address becomes a tracked item without anyone rekeying it.
That icon is a small piece of interface doing something structurally important. In most organisations, contact centre and service management are separate products with an integration between them, and the join is where context gets lost. Here a call and a ticket are the same object at different stages of its life, and the interface shows it.
Draft is a first-class ticket state for the same reason. Agents compose tickets while still on a call, and a system that only recognises submitted tickets forces them to choose between listening and recording.
Design decisions
Part of a long-running engagement, delivered as the interface team inside the client's own distributed process.
ITIL terms, on purpose
Service catalogue, incident type, impacted users. The people evaluating and operating this software already think in these words. Inventing friendlier alternatives would only add a translation step.
Sequence over grouping
Fields are ordered the way an agent gathers information on a call, not the way the data model groups them. Those are rarely the same arrangement.
Thresholds belong to the customer
SLA colours, priority values and catalogue entries are administrator-defined. The product supplies structure; the business supplies meaning.
Bulk import as a first-class path
Assets can be added individually or imported in bulk. A provider onboarding a new customer site is entering hundreds of devices, and a form-only path makes adoption a project in itself.
Common questions
Can GegoSoft design and build ITSM or service desk software?
Yes. We design and build the interface layer of an ITIL-aligned service desk covering tickets, assets, service contracts and SLA tracking, in Angular for web and native Android for mobile, working alongside the client's backend and QA teams.
Why should a ticket record a physical location?
For providers maintaining hardware rather than answering questions, a ticket is about a device in a place. Recording site, building, room and rack lets the asset picker filter to what is actually there, which removes most of the back-and-forth needed to identify the right equipment.
Should priority and criticality be separate fields?
Yes, when the requester and the service provider are different parties. Priority is the requester's claim about urgency; criticality is the assessed severity. Merged into one field, everyone selects the highest value and the scale stops being useful.
Should SLA thresholds and colours be configurable?
Yes. Different providers treat different points as alarming, and hard-coding a threshold makes a guess look like a standard. The product should supply the mechanism and let the business define when something becomes urgent.
Should a service desk be integrated with a contact centre or kept separate?
Integrated, where the same team handles both. When they are separate products joined by an integration, context is lost at the join. Recording the originating channel on the ticket and creating tickets automatically from monitored addresses keeps a call and a ticket as one object at different stages.
What makes ticket forms difficult to design?
Density. A service desk ticket may need location, asset, contract, catalogue entry, type, channel, priority and impact together. The form has to hold all of it while keeping the actual problem readable, which is a question of sequencing and disclosure rather than of removing fields.
More from this platform
Service desk software that fights your team?
Tell us what your agents have to record on every ticket and what they end up doing outside the system instead. That gap is usually a form problem, not a process one.
Start a conversation See all case studies