Merging service desks is a fairly common practice, especially as organizations make the shift left and join their service desk experts. Some factors for a service desk merge might be for obvious reasons, such as a business merger or even the addition of a new service desk technology to support the agency in ways not currently captured. Nevertheless, binging together teams (multiple service desks have different teams) and creating a successful service desk often means developing a single set of services offered while bringing together disparate processes.
As with most mergers, the process is usually not a walk in the park; neither is combining oil and water, for that matter. In such instances, you are creating cultural change and leading the development of a new internal combustion engine in the organization. As most business leaders understand, when they merge departments, teams or even ventures, the act of doing so can mean the painful combination of two or more groups of people who have different ways of doing things, a variety of responsibilities and skills, conflicting processes, habits and even cultures, so asking them to work together without any problems can be a struggle. To say the least, this process can lead to a great deal of friction and frustration.
Are there any silver bullets for slaying this beast? Nope, not here. You are going to have to find another way to fight the problem. But there are some tricks that can help get the job done, so you can merge away.
One of the most prominent ways of doing so is to create a service catalogue. Why? A collaborative project – like the development of a service catalogue – is one of the most important and quick ways to bring a new team together. Collaboration is king at this point in the process. Putting together a service catalogue forces the new merged service desk to focus on a task and allows you to tackle many of the challenges that arise – upfront – when bringing teams together.
A new service catalogue also allows you to get to the heart of any organizational challenges early on with responses to the questions you are likely to encounter sooner rather than later. If you are contemplating taking my advice for developing a service catalogue to help merge your disparate service desks, there are some things you need to consider along the way.
Services to support
What services will you support? It is a pretty straightforward question, but it needs to be answered. When debating this, determine how you are going to support the latest releases of certain technology. What about tailoring technology? Is that something you are going to offer to your user base? For example, do you provide users with an OS or is that something they get to install themselves?
To manage your customers' expectations, you will need to draw up a new, collective service catalogue and communicate these supports when you are done, of course.
Shared terms and vocab
Getting on the same page means speaking the same language. Services described means you have got to be able to discuss items like ticket management and/or incidents. What are you going to call these specific actions? Are they tickets, incidents, service requests? Are you changing names for the team? Is it a service desk, or helpdesk? What are you calling the self-service portal?
Plain and simple, the merged team means you need to be singing from the same song sheet; ordering from the same menu; being ready to move forward together; traversing the Delaware in George Washington's boat. Creating a shared vocabulary (or coming to consensus on terms that will be used and how to handle terms gets everyone on the service deck in the same boat, so to speak).
A unified service desk means you eliminate your towers of Babel.
Connecting with users at the service desk
When everyone is singing from the same song sheet, it is time to get connected with your users. If users know that multiple service desks are merging, they are going to have a single most pressing question: Where do I need to go when I have a question? Different service desks have different ways of reaching the service desk. One desk might have its own way having users connect with it that invariably gets dropped in the merged desk for one reason or another. Mergers mean people need to educate their users about how to reach them, what they can process from a service perspective.
Merging service desks is the perfect opportunity improve relations with your users and confirm how you would like to work with them and log calls.
What do you need to handle incoming user calls?
The merged service desk is a great time to define shared processes for handling incoming calls. The basics include: Who answers incoming calls or where these calls are deposited. Where will email, chat or whatever other written messages get deposited and who on the service team will answer these messages?
Next, what information do you want from your customers to process the call? This does not have to be difficult; simply map these processes for all parties concerned from both of the best and choose which ones you wish to adopt as part of the new merged desk. Once the processes are selected, communicate, of course, what the new process will be.
You are going to get yourself some off-the-wall requests. You need to decide how you will handle requests for service that you do not support, and even through channels that you do not. For example, if you decide not to support macOS, what are you going to do when the request for such comes? What are you going to do about this request when it comes to a member of the service desk from a user in the hallway while on the way to lunch?
Prioritizing the work
Once you know what services you support, you need to decide on the conditions. For example, how do you prioritize calls? If you have got any agreements in place you may need to honor them depending on existing contracts with users. New contracts will have to align with current contracts.
Roles and responsibilities of the new team
When merging service desks, there is a very good chance that members of your team have duplicate roles. If that is the case, you must determine if you need more than one individual taking on the task. Likewise, a merge usually opens up new possibilities for team members. Use this as an opportunity to chat with service desk staff to discuss their role and responsibilities, as well as their hopes and professional desires for the future.
The importance of team culture
More than anything, merging two teams means merging two team cultures. Two teams with their own values, habits, quirks and preferences. Whether or not the two teams manage to constructively work together, is hugely influential for the success of the merger. Doing a project together with a shared goal, is a nice way for the two teams to get to know each other better. Drafting a service catalogue is the perfect project to start with.
Dividing the stages of transition
Different service desks use different tools and applications. Merging them all overnight is not going to happen. You need to do so in stages. Decide that for a period you will be working with the systems needed to run the desks, but know that ultimately, sooner than later, you will need to bring those functions under one roof, make sure your teams are aware of each stage of the merger so you can avoid confusion along the way.
Establish timelines for phasing out the systems you do not find valuable or useful to your desk and work your plan according to your timelines. Stay on task as closely as possible and set deadlines for doing so. Then work toward that goal.
Is drafting a service catalogue worth the effort?
All of this work should be done in an effort to build a service catalogue for the new, centrally merged service desk. But that is the point. The catalogue and the processes you establish through it will lead to a smoother merge and to a more operational service desk for all parties involved, but most especially the users. Tackling issues as they arise without prior thought as to how they might impact the merger can be careless and can create unneeded interruptions to service for these individuals. While addressing issues as they come at you might seem like the agile way of doing things, instead, knowing you are going to face these issues along the way means tackling those questions early on can save you much time and energy as you progress.