Service Catalogs for Non-IT Departments: Legal, Finance, and Facilities
September 23, 2026
Think about the last time you needed something simple from another department: a contract reviewed, an expense approved, a light fixture in the meeting room replaced. Chances are you ended up filling out a form that asked you to describe the "issue," pick a "priority" level, and choose from a dropdown of categories that made sense for a broken laptop but not for a legal review. So you closed the tab, and you emailed someone instead.
That's not a training problem. It's not that Legal, Finance, or Facilities teams "resist" using the tools IT gives them. It's that the tool they were given was never built for them in the first place.
Most companies that expand their service desk beyond IT do it the same way: they take the portal built to log technical incidents and open it up to everyone else. The logic seems sound. IT already has a functioning ticketing system, a taxonomy of categories, SLAs, and a team that knows how to run it, so why not let Legal and Finance use it too?
In practice, this rarely works the way it's supposed to. The portal asks the wrong questions. A request for an NDA doesn't fit into fields designed for "hardware," "network," or "software issue." Priority levels calibrated for outages don't map to a contract deadline. The categories, the language, even the visual identity of the form all signal one thing to the person filling it out: this is IT's system, not mine.
It's the same dynamic that keeps IT's own ticket backlog growing even inside a single department, now playing out across three or four departments at once, each with its own invisible queue. So people use it once, decide it doesn't fit their world, and quietly go back to what already worked for them: email threads, WhatsApp messages, and shared Excel sheets to track requests by hand. Each department ends up running its own informal, undocumented process for the exact thing a service management platform is supposed to solve. Nobody has a clear count of how many requests are open, who owns them, or how long they've been sitting. A finance manager tracking expense approvals in a spreadsheet, a facilities coordinator juggling maintenance requests over email, a legal team fielding NDA reviews through Slack DMs: none of it is visible, none of it is measured, and all of it is happening in parallel to a service management platform the company already pays for.
The uncomfortable part is that this isn't a resistance-to-technology problem. It's a translation problem. The technology that was handed to these teams simply doesn't speak their language, and no amount of internal communication or "please use the portal" reminders fixes a form that was never designed around how Legal, Finance, or Facilities actually work.
This is exactly the scenario GB Advisors and Halo walked through, live, with real screens and a real ticket, in a 45-minute session built specifically for Legal, Finance, and Facilities leaders, not IT. Watch the full recording here to see the catalog, the demo, and the Q&A in context before reading further.
Enterprise Service Management (ESM), the practice of applying service management principles beyond IT, is not a new idea, and most companies that try it aren't wrong to try. A recent global survey found that two-thirds of organizations (67.6%) already have an ESM strategy in motion, up sharply from a few years ago, and that service catalog and self-service portal capabilities are now present in over half of them. The intent is there. What tends to fail is the execution, and the most common failure mode is treating "give other departments access to the IT tool" as the same thing as "build them a service management experience that fits their work."
This is also why self-service portal adoption stalls at a fraction of what it should be in so many companies: people aren't refusing self-service as a concept, they're refusing a specific portal that wasn't built with their work in mind. The distinction matters because most ESM platforms sell the same underlying pitch: one tool, extended outward from IT. The portal is the same, the ticket types are inherited from IT's taxonomy, and departments are expected to adapt to a structure that was never built with them in mind. It's an understandable default, reusing what already exists is cheaper than building something new, but it puts the burden of adaptation on the people least equipped to absorb it: department leads who didn't choose the software and have no reason to learn its logic.
We take the opposite approach when we design ESM programs for our clients across Legal, Finance, HR, and Facilities: instead of one portal stretched to cover everyone, each department gets its own catalog, built around how that department actually talks about its work, running on a single platform underneath.
This distinction is also where a lot of ESM rollouts quietly lose their momentum. A service catalog built without the department's own input tends to get used exactly once, the first time someone is required to, and then abandoned the moment a faster informal channel is available, which for most non-IT teams is an email or a WhatsApp message to someone they already know. Adoption doesn't fail because people are unwilling to change how they work; it fails because the new system asks them to describe their work in terms that don't match how they actually think about it. Fixing that isn't a training exercise. It's a design decision, made once, at the level of the catalog itself.
Here's the practical difference, and it's a different starting point than the more common approach of trying to unify IT, HR, and other requests behind a single generic front door. With HaloITSM's approach to enterprise service management, Legal sees its own catalog. Finance sees its own catalog. Facilities sees its own catalog. Nobody on those teams needs to know, or care, that there's a single platform powering all three behind the scenes. What they see is a service experience that was designed around their vocabulary, their categories, and their timelines.
For Legal, that catalog might include contract review requests, NDA generation, and compliance questions: categories that reflect actual legal workflows, not adapted IT tickets. For Finance, it's expense approvals, purchase orders, and reimbursement requests, each with fields that make sense to a controller, not a help desk technician. For Facilities, it's maintenance requests, room bookings, and physical asset management, with the option to attach a photo of a leaking pipe directly to the ticket instead of describing it in a paragraph clearly written for someone who will never see it.
None of this is generic. Each department configures the categories, the language, and the response times that correspond to its own business, not a version of IT's categories with the labels swapped out. In practice, the same three catalogs from the walkthrough above break down like this:
Add HR or Procurement later, and the pattern repeats: a new catalog, not a new tool, not a new vendor relationship, and not a new thing for IT to operate.
The forms themselves are built without code, which means Legal or Finance can design exactly the intake screen their process needs without waiting on a developer or an IT ticket of their own (an irony that shows up more often than you'd expect when service catalogs are treated as an engineering project). Approval flows follow the same logic: Finance can configure double approval for expenses above a certain threshold, and a contract that needs sign-off from both Legal and Finance can route through a cross-functional approval chain automatically, instead of being chased down manually over email.
Notifications and SLAs work the same way: each catalog sets its own response and resolution targets, rather than inheriting whatever timelines IT originally configured for hardware incidents. A facilities request for a broken light fixture and a legal request for contract review were never going to share a reasonable SLA, so they don't have to.
None of this removes IT from the picture; it changes what IT is responsible for. IT still owns and administers the platform, the way a facilities team owns a building without personally approving every meeting scheduled inside it. What changes is that IT is no longer the one operating Legal's requests or approving Finance's processes: work that was never really IT's job to begin with, even when it landed on their desk by default because they happened to own the ticketing system. And because each new department runs on its own catalog within the same underlying platform, adding HR or Procurement later doesn't add operational load to IT the way standing up a separate tool for each department would.
It helps to walk through the same request under both models, start to finish.
Under the shared-IT-portal model: someone in Legal needs an NDA reviewed before a vendor call tomorrow. They open the company portal, hit a form built for hardware and network issues, and try to force the request into fields that don't fit: "category: other," "priority: high," a free-text box where they explain, in a paragraph, what a contract review actually involves. They submit it, get an automated confirmation that reads like a network ticket, and have no way to tell whether it landed with the right person. By the afternoon, with no update in sight, they email the general counsel directly instead, and the ticket sits open and untouched, one more entry in a queue nobody on the legal side is checking.
Under the department-catalog model: the same person opens Legal's own request screen, chooses "Contract Review" from a list of categories that already match how Legal talks about its work, attaches the draft NDA, and flags the vendor call deadline in a field built for exactly that. The request routes automatically to the legal ops team responsible for reviews, who gets a suggested first response drawn from Legal's own knowledge base. If the contract also needs Finance sign-off past a certain value, the approval chain routes it there automatically, no separate email required. The requester can check status at any point without asking anyone, because the ticket, not an inbox thread, is the record.
The underlying technology in both cases can be the same platform. What's different is entirely the design of the intake, the categories, and the workflow around it. That is the actual argument for a department catalog over a shared portal: it isn't a bigger tool, it's a better-fitted one.
The gap between "the portal IT gave us" and "a system that fits how we actually work" tends to be wider in organizations operating across multiple countries in the region, for reasons that are specific to how Legal, Finance, and Facilities teams here operate day to day. Legal teams frequently manage contracts and compliance requirements that vary by country, which a generic IT ticket category was never built to capture. Finance teams often run approval chains that involve regional and corporate sign-off across time zones, which is exactly the kind of multi-step approval flow that breaks down fastest in an email thread. And across the region, WhatsApp is often the default channel for anything that needs a fast answer, which is precisely why so many departmental requests end up there instead of in a system anyone can report on later.
Having spent more than 15 years implementing IT and enterprise service management for over 1,600 clients across Latin America and the Caribbean, this is a pattern we see repeat across industries: it's rarely that a company lacks a service management platform. It's that the platform they have was scoped for IT and never extended, in a way that actually fits, to the departments now asking for the same kind of structure IT has had for years.
A platform-wide AI layer changes how requests move once they're submitted, in three concrete ways. First, automatic classification and routing means a request lands with the right team without the person submitting it needing to know who that team is: the system reads the request and sends it to Legal, Finance, or Facilities without a human triage step in between. Second, agents fielding requests get suggested responses drawn from each catalog's own knowledge base, so a Finance agent answering a reimbursement question isn't improvising from memory or digging through old email threads. Third, a virtual agent can resolve common requests from any department directly, from a single entry point, without a ticket ever reaching a human queue.
None of this requires each department to understand AI, prompt anything, or manage a separate tool. It runs underneath the catalog they already use, the same way the platform itself stays invisible to them.
The clearest way to see the difference between a department catalog and a generic IT portal is to watch one get used. In the live walkthrough, a facilities request starts from a simple "How can we help you today?" screen with plain options (Request Something, Report an Issue, My Tickets, Help Articles), nothing that assumes technical knowledge. From there, a Facilities-specific form asks for exactly what a plumbing issue needs: a description and a photo, not a device serial number or a network diagnostic. The resulting ticket, generated automatically as a "Plumbing Request," proves the point: the category itself was written for Facilities, not retrofitted from an IT ticket type.
On the admin side, the same platform shows a full catalog of departments (IT, HR, Facilities, Procurement), each configurable independently, alongside real operational detail: an automatic email notification the moment a ticket is logged, a live agent dashboard tracking open incidents, unassigned tickets, and SLAs approaching their deadline, and a Legal ticket type built specifically around contract review fields, assigned to its own team of agents. Integrations round it out: the platform connects to tools like DocuSign and existing ERP systems rather than replacing them, which matters for Legal and Finance teams who already have document and financial systems they're not looking to abandon.
Every screen described above is shown live in the recording: the facilities ticket with the attached photo, the Legal contract-review catalog, the SLA configuration for Finance, and the full Q&A that followed. Watch the full 45-minute session here if you want to see the mechanics before reading the results below.
The teams that move to a department-specific catalog tend to describe the same short list of changes. They can resolve what they need without learning IT's vocabulary first. Manual follow-up over email, WhatsApp, and spreadsheets drops, because the request itself is now tracked somewhere instead of living in someone's inbox. Leaders get real visibility into what's pending, who owns it, and how long it's been open: visibility that simply doesn't exist when requests are scattered across personal channels. And the team gets time back, because nobody is spending part of their week chasing the status of a request that should have taken five minutes to check.
That last point connects to something borne out well beyond this one platform: research on IT-led automation shows that eliminating repetitive manual tracking at scale can free thousands of hours a year even in a single department, once requests stop depending on someone remembering to follow up. The same logic applies at the scale of a Legal or Finance team, just with smaller numbers and a faster payoff.
It's also worth being honest about why so many ESM efforts stall before they reach this point. Broader research into enterprise service management rollouts has found that a large share of initiatives struggle to deliver expected value, and the most common reason isn't the software: it's treating ESM as a tool deployment instead of an operating-model change that needs real design work around categories, ownership, and approval logic before any platform gets turned on. A department catalog approach sidesteps a lot of that risk by design, because each catalog is built around one team's actual process from the start, rather than a single generic structure stretched to fit five different departments at once.
A few questions tend to come up whenever this model is presented to department leaders outside IT, and they're worth answering directly.
Will it feel like we're using the IT system? No: each catalog can carry its own name and its own visual identity, so the experience reads as "Legal's request form," not "a ticket in IT's tool."
How long does it take to get a catalog running? Because the forms are no-code, a basic department catalog can realistically be active within days, not the months a custom-built tool would take.
Who configures it, us or IT? Both, in practice. The department defines what it needs, and a partner or IT can support the design so the catalog reflects how the team actually works rather than a generic template.
Do we pay per employee who submits a request? No: licensing is based on the agents resolving requests, not on every employee who might ever submit one, which changes the economics considerably for departments with a small handling team and a large user base.
Does this compete with tools like DocuSign or our ERP? No: it's designed to integrate with the systems Legal and Finance already run, not replace them.
What actually separates this from other ESM platforms? Less the underlying technology and more the experience of the person requesting the service: most platforms differentiate on backend capability; this one differentiates on whether the person filling out the form feels like the form was built for them.
Does IT lose control of the platform once other departments get their own catalogs? No: IT keeps administrative ownership of the underlying platform, the same way a building manager owns a building without approving every meeting booked inside it. What changes is operational, not administrative: IT stops being the team that fields Legal's contract questions or approves Finance's expense chains, work that was rarely a good use of an IT team's time to begin with.
What happens to the requests that are already sitting in email and spreadsheets today? They don't need to be migrated in bulk before starting. Most teams begin with new requests going through the catalog from day one, while whatever is already in flight in the old channels gets closed out the way it always has. The backlog doesn't block the switch; it just stops growing.
None of this starts with buying software. It starts with mapping what a real catalog for your team would actually look like: the categories, the forms, the approval chain, the SLAs that make sense for how Legal, Finance, or Facilities actually operates day to day. That mapping conversation is worth having before any platform decision gets made, because a catalog built around a real process holds up; one built around a generic template doesn't.
If the scenario described here (the portal that asks the wrong questions, the quiet return to email and spreadsheets, the requests nobody can account for) sounds familiar, GB Advisors' 15+ years implementing ESM across Latin America and the Caribbean means we've mapped this exact conversation for legal, finance, and facilities teams before, not just IT departments. Talk to us about mapping your department's catalog, and we'll walk through what it would look like for your team specifically, not a generic demo.
