How to connect service management across departments

Each department may have a clear process for handling requests, yet work can still stall when it passes between teams. An update stays in one system, or the next task waits because responsibility for it is unclear. The person who raised the request is left chasing progress.

Connecting service management across departments starts with agreeing what the service must deliver and how teams will hand work over. Those agreements help you decide which systems need to exchange information and when.

Where enterprise service management fits

Enterprise service management (ESM) extends service management practices beyond IT to functions such as HR, Finance and Facilities. It gives internal services a structured way to handle requests and track progress. Our guide to ESM and ITSM explains that distinction in more detail.

Departments can share a service management approach while retaining their own approvals and ways of working. The Service Desk Institute’s ESM guidance makes this an explicit design principle, including the need for different privacy controls across functions.

1. Choose a service with a clear outcome

A recurring service that depends on several teams gives you a manageable place to begin. Employee onboarding is one example; supplier onboarding or an office move may be more relevant to your organisation.

Choose something with a recognisable completion point and people who can help improve it. For onboarding, that might mean the employee has the equipment and approved access needed for their role by the agreed start date. Write that outcome down with the departments involved.

Review a few recent requests together. If colleagues had to chase updates or re-enter information, use those instances to identify where coordination needs attention.

2. Map what happens between departments

Follow a request from its initial trigger to completion, including the work that happens outside the service desk. An approval in an email or a date changed in a spreadsheet may determine whether the next team can proceed.

At each handover, establish what starts the next task, which information it needs and how the receiving team knows it is ready. Check which tasks can run in parallel and which depend on an earlier decision.

Consider an illustrative onboarding request where the employee’s start date changes after IT has scheduled equipment delivery. The process needs a way to pass on the revised date and flag any work affected by it. Simply creating an IT ticket from an HR request leaves that dependency unresolved.

3. Agree ownership and the information teams share

Someone needs responsibility for the service across departmental boundaries, with authority to bring the right people together when work stalls. That role may sit in HR, shared services or another business function. IT’s responsibility for the platform is a separate decision.

Also agree who approves changes to the shared workflow and how conflicting departmental priorities are resolved. Otherwise, a team can change its own process without realising that another team relies on it.

For the shared service view, identify the information each role needs to coordinate work. In an onboarding process, the division could look like this:

Apply access rights to that shared view too. A team may need confirmation that an approval is complete without needing access to the underlying personnel documents.

4. Decide how existing systems will work together

With those agreements in place, you can assess whether to manage the service in one platform or coordinate work across existing departmental systems.

A shared platform can simplify request tracking when its workflows and access controls meet the participating teams’ needs. Keeping specialist systems may be more appropriate where they already support essential departmental work. That choice creates an ongoing responsibility for the integrations between them.

A service management platform can act as a coordination layer over existing systems. Atlassian’s ESM guide describes this model for Jira Service Management, including connections to HR and finance systems. Whether it fits your environment depends on the systems and integration capabilities available.

For each connection, decide which system owns the original information and which updates must travel back. Test what happens when an update fails: can someone see the failure, correct it and retry without creating duplicate requests? Assign responsibility for maintaining the connection as well as building it.

5. Test the whole service and measure the result

Try the process with a limited group of users before extending it. Include a changed start date, missing information and an unavailable approver so you can see how teams handle exceptions. Ask the person requesting the service whether they can understand its status and know whom to contact.

Measure completion across the service, alongside individual team performance. Useful measures for onboarding include readiness on the agreed start date, time spent waiting between teams and requests returned because information is missing.

This follows the broader principle in PeopleCert’s explanation of Value Stream Management: examine how work moves through the organisation and whether it delivers the intended outcome. A completed IT task alone cannot tell you whether a new colleague is ready to work.

How Akuo approached services beyond IT

In Idalko’s work with renewable energy company Akuo, a central aim was to create one help centre for requests across IT, finance and business services. The collaboration developed from a pilot, with workshops to review workflows and build the approach step by step.

The case also describes the education, change management and user feedback needed to help colleagues adopt structured requests. Include that work in the rollout plan, with time for departments to adjust the process based on actual use.

For a broader look at how Idalko connects process decisions with technology, explore our approach to business digital transformation.