Renaming the Desk Without Reorganizing It

The e-mail went out at 16:40 on a Thursday. "From Monday, the IT Help Desk will be known as the IT Service Desk, reflecting our commitment to a service-oriented partnership with the business." It had a new logo, a line about continuous improvement, and the same phone number. The first reply arrived at 16:43, from Dana in dispatch at Meridian Parts: "Does the password reset still work?" The second came four minutes later, from a manager in sales: "Is this the thing where we have to use a form now?" Nobody on the desk had an answer to the second question. Nobody had thought to ask it.

Renaming a help desk a service desk is the most common change in IT support and the one with the least agreed content. Sometimes the name is catching up with work the desk already does, and the e-mail is a formality. Sometimes the name is the whole change, and the desk that answers the phone on Monday is the same desk with a longer title and a logo. The difference is not visible from the announcement. It is visible from the queue, about a month later.

This article is part of our Helpdesk vs Service Desk series, which sorts out what the three names mean and what each implies. It covers when a name change is enough and when it is theater. Then come the three things to change with the name so that it means something (the door in, the ownership rule, the published scope). We cover how to announce it and keep announcing it, what to leave alone, and how to tell a month later whether it took. We finish with a rename checklist to steal.

When a Name Change Is Enough

A name change is enough when the work already matches the name. The desk may already take requests as well as incidents through one door. It may already own a ticket until the user agrees it is done even when another team did the work. It may already publish what it supports. If all three are true, it has been a service desk for some time under an older name. The rename is a correction, like fixing the label on a cable that was replugged a year ago. Send the e-mail and move on.

The test is three questions, answered by someone who works the queue rather than someone who manages it. Can a user ask for a new starter's account through the same route they use to report a broken one? When a ticket is waiting on facilities or HR, does the desk still chase it and close it, or does it reassign it and forget? Is there a page, anywhere, that says what the desk supports and where to find it? Three yeses and the name is overdue. Three noes and the name is a costume. Why those three are the ones that count is laid out in What a Service Desk Adds to a Helpdesk.

If you are not sure which case you are in, you are in the second. A desk that already does the work tends to know it, because it has been quietly annoyed by the old name for a while. A desk that is not sure has usually been told to become a service desk by someone who read a slide. And the slide did not come with a Monday.

When It Is Theater

The rename is theater when the name changes and the queue does not. The same mailbox receives the same e-mails, and the same two people triage them the same way. Requests still arrive as free text and get bounced between teams. The only operational difference is that the signature block is longer. Users notice within a week. They are polite about it, mostly, and then they stop reading announcements from IT, which is a cost that outlasts the project.

Theater happens for understandable reasons, and none of them are the desk's fault. A framework was adopted and the framework uses the word "service". A new manager wants a visible early win. A product is called a service desk and the department renamed itself to match the login page. In each case the name arrived from above and the work was supposed to follow, and work does not follow names. Names follow work, or they float. What the three names mean when they are used carefully is in Helpdesk, Service Desk, Desktop Support: Three Terms, One Job?

The cost of theater is not the e-mail; it is the next rename. A desk that has been renamed once without changing becomes a desk that users expect to be renamed again. When the real change arrives, with a form and an ownership rule and a scope page, it gets filed with the previous one. I have watched a good change fail because it was the third announcement with the same subject line. The industry renames things the way some people rearrange furniture: often, with conviction, and into the same room.

Change One: One Door for Incidents and Requests

The first real change is the door in. It is one route by which a user reports something broken and asks for something new, with the request path capturing what a request needs. An incident is something that was working and is not. A request is something the user does not have and wants. Users should not have to know which they have, so the form asks, in plain words, "Is something broken, or do you need something?" The request branch asks the questions that let the request be fulfilled without a second conversation. Those are who it is for, by when, who approves, and what exactly.

The door is a form, an address and a phone number. And all three must land in the same queue as the same kind of ticket. It is not a portal project. A single web form with two branches and the existing support address can be paired with one rule. Walk-ups and calls are logged by the technician while the user is still there. That combination is enough for most desks under three hundred users. A requester portal that needs no account and identifies people by e-mail address, as QuerySolv's does, keeps the door low. The lower the door, the fewer the shoulder taps.

If you change the name and not the door, requests keep arriving as free text and the desk keeps spending its first exchange asking for the fields. The rename promised that asking for things would be easier. It was not, and users will decide the whole announcement was decoration.

Change Two: The Desk Owns the Ticket to the End

The second real change is the ownership rule. The desk owns every ticket from the moment it opens until the user agrees it is done, whichever team does the work. When a request needs HR to approve a starter, facilities to find a desk and a specialist to build the account, the ticket does not move to those teams. It waits on them, visibly, with a status that says so, and the desk chases. The user has one number and one place to ask. That single idea is most of what the word "service" is for.

Put the rule in the ticket system as a status and in the desk's head as a habit. The status is "waiting on another team", which the desk still owns and reviews every day. The team's name and the date sent are written on the ticket. The habit is that a ticket in that status gets chased at a fixed interval. The desk closes it with the user rather than letting the other team mark it done and walk away. A tool can reopen a resolved ticket when the requester replies, by any route, and count the reopen (QuerySolv does). Such a tool makes the end of the ticket the user's decision rather than the desk's, which is the honest place for it.

Without the ownership rule the rename makes things worse, because the desk now promises an end-to-end service it cannot see. The new-starter request goes to HR, then facilities, then the specialist, and the desk's ticket closed on day one with "forwarded". On day nine the user asks the desk where the account is, and the desk, with its new name, does not know. That is the failure the service desk idea exists to prevent. And a desk that renames without fixing it has bought the sign and not the shop.

Change Three: Publish the Scope

The third real change is a published scope: one page that says what the desk supports, what it does not, and where to find it. It lists the systems and kinds of request the desk will take, and the ones it will route elsewhere and to whom. It also lists the ones it will not touch (personal devices, the sales team's own tool, the thing somebody bought on a card). It is dated, it is linked from the form and the announcement, and it is one page. The full treatment of the catalog and its boundaries lives in the scope pillar; the rename needs only the page.

The scope page is the change users can see without opening a ticket, which is why it belongs in the announcement. A name tells them nothing about what changed. A page can say "we now take requests for accounts, equipment and software through this form, and here is what we do not support". That tells them what the new name is for. It also tells the desk, which matters more. The desk is about to be asked for things that were never in scope on the strength of the word "service".

Without the page, scope is negotiated per ticket, by the most junior person on the desk, with whoever is most insistent. That negotiation always goes the same way. The published page is the desk's way of saying no in advance, politely, to things that were decided in a calmer hour.

Communicating the Change

Announce the change as what users can now do, not as what the desk is now called. The message has four parts. First comes the one thing that is different for them (here is the one place to report problems and ask for things). Then come the name, in passing, where to find the scope page, and the date it starts. Keep it under a hundred and fifty words and send it from a person rather than a mailbox. Resist the words "partnership", "journey" and "excellence", which users have learned to read as "nothing changed". The announcement below is a template.

Subject: One place to report problems and ask for things, from Monday

From Monday (date), the IT help desk becomes the IT service desk.
The name is the small part. Here is what changes for you:

  - One form for everything: something broken, or something you need.
    https://support.example.com/   (also still: support@example.com, ext. 4100)
  - One ticket number and one place to ask how it is going, even when
    another team is doing the work. We chase; you do not have to.
  - What we support, and what we do not, is now written down:
    https://support.example.com/scope   (one page, dated)

Nothing you use today stops working. Password resets, printers, the
phone number: all the same. The walk-up desk stays open 09:00 to 17:00;
we will log what you bring us before we start on it.

Questions: reply to this message, or ask anyone on the desk.
Priya, for the service desk

The timing is a week of warning, a start date, and thirty days of reminders, because one e-mail changes nobody's habits. The reminders are small and in the places people already look. They include a line in the desk's e-mail signature and a card on the walk-up counter. There is also a sentence at the end of every resolution reply for a month. The walk-up redirect is the most important and the hardest. When someone walks up, the technician logs it on the spot and says where it would have gone, every time, kindly, for thirty days. After that the habit is either formed or it is not, and more e-mail will not form it.

If the announcement is the whole communication, the change has roughly the lifespan of the e-mail, which is until it scrolls off the screen. The desk will spend the next quarter explaining the rename to people who did not read it. It will spend the next year explaining it to people who did.

What to Leave Alone

Leave the categories, the tool and the people alone, because the rename is not the moment to change any of them. The categories exist so that history can be compared; rename them now and the numbers before and after stop lining up. In that case, you lose the one measurement that would tell you whether the rename took. The tool exists and everyone knows where it is. A tool migration in the same month as a rename means every complaint about either lands on both. The people are the desk, and a rename that comes with a restructure teaches them that the next name will too. If the reporting line really is wrong, that is a separate decision, covered in Org Design and Reporting Lines for Support.

The temptation to bundle is strong, because a rename feels like a fresh start and a fresh start wants a new everything. Resist it in the order above. If the categories are really wrong, fix them a quarter later, when the rename's numbers are in. If the tool is really wrong, that is a separate project with its own announcement. Some of this is enforced for you: in QuerySolv the five priorities and ten statuses are fixed and cannot be renamed. That has saved at least one rename project from redefining "Resolved".

Leaving things alone is the cheapest part of the change and the one most likely to be overruled. I have sat in the meeting where "while we are at it" added a new tool, new categories and a new shift roster to a rename. The rename was the only part that shipped on time. It was also the only part that did not matter.

Measuring Whether the Change Took

Three numbers, read thirty days after the start date and compared with the thirty days before, tell you whether the rename changed anything. They are requests logged as tickets, time to first response, and walk-ups per week. Requests logged as tickets is the count that came in through the request branch of the form. Before the change there was no branch. So the comparison is against the requests you can find in free text in the old tickets. Time to first response is the gap between a ticket opening and a human reply. Walk-ups per week is a tally on the counter, kept honestly for the full sixty days.

Take Acme, two hundred and forty users, which renamed its desk on a Monday after a week's warning. In the thirty days before, the desk had logged four hundred and twelve tickets. A search for "need", "new starter" and "access" found about ninety of those were requests in free text. Median first response was fifty-two minutes. Walk-ups ran at about thirty a week on a tally sheet nobody trusted. In the thirty days after, there were four hundred and thirty-eight tickets, a hundred and thirty-one through the request branch. Median first response was forty-four minutes, and walk-ups were down to eleven a week by the fourth week. The desk read those numbers as the change taking. Nobody needed a maturity assessment to see it, and the one person who asked for one was shown the tally sheet.

If the numbers do not move, the name moved and the work did not. In that case, the honest response is to say so inside IT and fix the part that stalled. Usually it is the walk-up redirect, because it is the part that requires the desk to say the same thing a hundred times with the same patience. Sometimes it is the ownership rule, because "waiting on another team" turned out to be a place to leave tickets rather than a place to chase them from. The numbers will tell you which. The announcement will not.

A Short War Story: Meridian Parts Renamed Its Desk Twice

Meridian Parts renamed its help desk a service desk twice within three years. The first time came with a new logo, an announcement about partnership with the business, and nothing else. The queue, the form and the ownership of a stalled request were exactly as before. Within a month users had stopped using the new name, including, quietly, the desk. The second time, under a new desk lead, Sam, the announcement was one paragraph and the work was three changes. There was a form with a request branch and four fields. There was a "waiting on another team" status the desk reviewed every morning, and a one-page scope list linked from both. The walk-up redirect was run for thirty days by everyone on the desk, with a tally on the counter. Requests through the form went from none to about a hundred and twenty a month, and the second name stuck, mostly because nobody had to remember it. The first rename had not been a failure of effort. It had been a rename.

The Rename Checklist

The checklist below is the whole project on one page. The three real changes are at the top because they are the project. The name, the announcement and the reminders are below them because they are an afternoon. Work it in order. If the first three lines cannot be ticked, do not send the e-mail yet.

RENAME CHECKLIST: help desk to service desk
Desk: _______________   Lead: _______________   Start date: __________

THE THREE REAL CHANGES (do these first; they are the project)
[ ] 1. ONE DOOR IN
       [ ] One form with two branches: something broken / something needed
       [ ] Request branch asks: for whom, by when, who approves, what exactly
       [ ] Form, address and phone all land in one queue as the same ticket
       [ ] Walk-ups and calls are logged by the technician on the spot
[ ] 2. THE DESK OWNS THE TICKET TO THE END
       [ ] A "waiting on another team" status that the desk still owns
       [ ] Team name and date sent recorded on the ticket when it waits
       [ ] Daily review of everything waiting; chase interval written down
       [ ] The desk closes with the user; the other team does not
[ ] 3. PUBLISHED SCOPE
       [ ] One page: what we support, what we route and to whom, what we do not
       [ ] Dated, linked from the form and the announcement
       [ ] Read by everyone on the desk before the start date

THE NAME (an afternoon)
[ ] Announcement: what users can now do, the name in passing, the scope
    link, the date; under 150 words; sent by a person; one week before
[ ] Signature blocks, the form title, the walk-up sign, the phone greeting
[ ] Thirty days of reminders: signature line, counter card, resolution footer
[ ] Walk-up redirect: log it, say where it would have gone, every time, kindly

LEAVE ALONE (for at least a quarter)
[ ] Categories     [ ] The tool     [ ] The people and the roster

MEASURE (thirty days before against thirty days after)
    Requests logged as tickets:     before ______   after ______
    Median time to first response:  before ______   after ______
    Walk-ups per week (tally):      before ______   after ______
    Verdict: [ ] took    [ ] name moved, work did not; fix: _______________

Back at Meridian Parts, Dana's question about the password reset got an answer within the hour, which was yes. The manager's question about the form got a better answer the second time round, which was also yes, with a link. The second announcement was shorter than the first and had no logo. It is the only one anyone remembers, and they remember it by what it let them do.

Frequently Asked Questions