Smart ESM: How to unify IT, HR, and other requests
August 6, 2026
Employees don't care how many systems run behind the scenes at their company. They care that they can submit one request, in one place, and have it go somewhere useful, whether that request is a new laptop, a facilities repair, a payroll question, or an approval from finance. The gap between that expectation and reality is usually a half-dozen disconnected portals, each with its own login, its own form, and its own black box of a status field that never quite says what's actually happening.
The instinct when this gap becomes painful enough is to propose replacing everything with one system. That's rarely realistic, and it's rarely necessary. ERP, HR information systems, and facilities management tools exist for good reasons, often tied to compliance or vendor contracts that can't be unwound quickly. The more practical path is building a single front door that routes requests into whichever backend system already owns that process, without asking the employee to know or care which system that is.
The phrase gets used loosely enough that it's worth being precise about it. A single pane of glass is not one database replacing five others, and it's not a dashboard that just displays data pulled from other tools. It's a consistent front-end experience where the request, the routing logic, and the status tracking live in one place, even when the actual fulfillment happens in a system the employee never sees.
This distinction matters because leadership often greenlights "unification" projects expecting a full system replacement, and then the project stalls when it becomes clear that finance isn't giving up its ERP or HR isn't giving up its HRIS. Setting the right expectation upfront, that this is about the interface layer and the orchestration layer, not a wholesale system migration, is what keeps the project scoped to something that can actually ship.
A well-built service catalog is the mechanism that makes this work in practice. Instead of an employee needing to know that a laptop request goes to IT, a badge request goes to facilities, and a title change goes to HR, the catalog presents categories in language employees actually use and routes the request behind the scenes.
Each of these categories can point to a completely different backend system, and the employee never needs to know that, or even needs to know that the system exists in the first place. What they experience is one form, one submission, and one place to check status, regardless of how many systems are actually involved in fulfilling it behind the scenes. That consistency is what earns trust in the catalog over time, since employees stop needing to guess whether a request "worked" or vanished into an inbox somewhere.
The harder engineering problem sits just behind the catalog: once a request is submitted, something has to actually move it into the system that owns that process, and then bring status updates back. This is typically handled through a mix of native integrations, webhooks, and middleware, depending on how modern the backend system's API is.
Older or more rigid backend systems are the common bottleneck here. A modern HRIS with a well-documented API can sync status in near real time; a legacy facilities system might only support a nightly batch sync or, in the worst case, an email-based workflow that has to be built around manually. Mapping which systems fall into which category before starting the project prevents a lot of mid-project surprises about what's actually achievable on a given timeline.
Onboarding and offboarding are the clearest example of why this orchestration layer matters, because a single new hire genuinely does touch IT, HR, facilities, and sometimes finance within the same week. Handling that manually means five separate people remembering to do their piece on time, which is exactly how new hires end up without laptop access on day one.
Structured employee lifecycle automation triggers every downstream task from a single event, a start date being entered, instead of relying on each department to notice independently that a new hire is coming. The unified front end doesn't replace HR's system of record; it just makes sure the tasks living in IT, facilities, and access management fire on schedule without a human having to chase them down manually.
Visibility over what the company actually owns and where it lives is the other half of the single-pane promise, and it's just as easy to get wrong. Asset and configuration data often exists redundantly across procurement systems, IT inventory tools, and spreadsheets that nobody officially owns but everyone quietly relies on.
Maintaining a unified asset inventory that pulls from discovery tools and reconciles against procurement records gives IT one place to check what exists, who's using it, and when it's due for renewal, without forcing every team that touches an asset to log into the same system. That reconciliation step is usually the difference between a CMDB that's trusted and one that's quietly ignored because everyone knows it's out of date.
Once the routing and catalog layers exist for IT requests, extending them to other departments is largely a configuration exercise rather than a new build. The same infrastructure that routes a laptop request can just as easily route a facilities ticket or an HR question, each landing in the queue that already owns that kind of work.
This is where a platform built for enterprise service management earns its cost: a service beyond IT rollout means facilities, HR, and finance each get their own queue, their own approval rules, and their own reporting, all sitting on the same catalog and routing engine the IT team already built and tested. Departments get a modern service desk experience without each one needing to evaluate, buy, and implement a separate tool.
Trying to unify every department's workflow at once is how these projects lose momentum. The sequence that tends to hold up is: build the catalog and routing layer for IT first, since that's the use case with the most existing tooling and the clearest ownership, then extend the same catalog to one adjacent department, typically facilities or HR, and use that rollout to prove the integration pattern before expanding further.
Skipping straight to a company-wide rollout before the integration pattern is proven with one department tends to surface every edge case at once, across every backend system simultaneously, which is a difficult position to debug from. Proving the pattern once, with one well-chosen department, makes every subsequent rollout faster rather than harder.
Freshservice is built to sit in exactly this orchestration role: a catalog and routing layer that connects to the systems already in place across IT, HR, facilities, and finance, without requiring any of them to be replaced first. Departments keep the systems of record they've already invested in, while employees interact with a single consistent front end regardless of which backend actually resolves the request.
If your team is trying to figure out what a realistic version of this deployment would look like with the systems you already have, at GB Advisors we can map your integration points across IT, HR, facilities, and finance, identify which backend systems will be quick wins versus which will require slower syncs, and map out a sequenced plan together that doesn't require ripping out anything that already works. Book a free consultation with our experts.
