If your organization uses TOPdesk but has incidents or changes without prefixes, it will eventually run into problems. These can range all the way from being unable to include external numbers in email subject lines to accidentally importing information into the wrong incident or change. But changing the prefix can lead to its own problems, too—like no longer being able to refer to old incidents within the request/action fields. So how did we tackle this problem here at TOPdesk? And why did we wait so long to do it?
The importance of prefixes
Prefixes are a must for any organization that uses TOPdesk to handle a large number of incidents and changes. Besides preventing information from potentially ending up in the wrong place, it also has its own benefits. By choosing a unique enough prefix, you can add other customers’ incident numbers in an email’s subject line—thereby allowing mail import to import it correctly (without needing to create any new incidents, for example).
Why changing your prefix is tricky
However, changing your prefix is an entirely different matter. It’s a complicated problem to fix, which is why so many organizations postpone its implementation—and it’s why we waited so long to pick this up, too. But why is changing your prefix so tricky?
First, you need to pick a prefix that everyone agrees on. Then, you need to make sure the mail import will still import emails with your ‘old style’ incident/change numbers into the correct incidents and changes. And you need to somehow make sure that old incident/change references in action/request fields still work. Needless to say, this is quite a daunting task—so we waited until we started running into some real problems that could frankly no longer be ignored.
Our biggest prefix problem: importing emails
There was one major problem that we needed to solve first and foremost. Due to the way we numbered incidents and changes, we were at risk of accidentally importing a reply to a change into an incident.
The situation was this: we had no prefix for incidents, but we did have a prefix for changes (CH) and change activities (CA). We also had mail imports running for both incidents and changes. For those of you who don’t know, the mail import first checks for any numbers that look like incidents, then for changes and change activities. Our changes and change activities were numbered yy mm xxxx and our incidents yy mm xxx.
Everything was going fine until our change activities started to go beyond 999 a month (so they no longer started with a 0). Suddenly, the numbering looked an awful lot like an incident number and the mail import could have imported responses to a change activity into an existing incident. This was obviously a security risk, so it was enough of a pain for us to finally invest the time and energy required to change our prefixes for good.
How we fixed it
The act of changing a prefix in TOPdesk is simple enough: dive into the settings and make the necessary adjustments. But as mentioned in the beginning, changing the prefix comes with its own bundle of problems. This meant that we had to properly prepare and plan in order to ensure that it impacted our users (both customers and colleagues) as little as possible.
The first point of order was to decide what our new prefix was going to be. After some research into our customers’ most used prefixes, we decided on TDR (TOPdesk Reference). Reference starts with the same letter in most languages, and if tasks and workflows take off, we’ll already be ready to eliminate things like ‘incidents’ or ‘changes’.
The next question was: when should we implement the change? Given that the numbering would start again at 001 after we made the change, we wanted to do it as close to midnight on the last day of the month as possible—so we chose the 31st of August. This meant the new numbering would come into effect on the 1st September, when incident numbering was due to start at 001 anyway.
Solving the problem of the old vs new prefix
But there was another problem—what should we do with old incident numbers? This problem is multifaceted.
First, we have our friend the mail import. What would happen if customers reply to an email which features the old incident number in the header? We fixed this by adding the new prefixes to all our email actions a month before we made the actual change and removing it again afterwards. Because we just added letters in front of the existing numbers/change prefix, this did not affect the mail import in any way. After the change, if a customer responded to an ‘old’ email, the mail import would recognize the new prefix and import it correctly.
One of our technical application managers wrote a beautiful query to ensure that old incidents would still be found and that all the references within the request/action fields would still work properly. If you’re interested in checking it out, contact your customer success team—they’ll be glad to share it with you.
How we flipped the switch and nothing broke
The only thing left was to ensure that our customers and colleagues alike were made aware of the upcoming change. Therefore, we decided to publish a news item detailing what would be changing, and why, and we also communicated this internally on our TOPdesk intranet.
The first hurdle came at the beginning of August when we changed the subject lines to all our outgoing emails before publishing this upcoming change to customers and colleagues. There were a few questions and queries, but by and large, everyone seemed to grasp what was about to change. By the time that August 31st arrived, all we had to do was ‘flip the switch’ as close to midnight as possible—everything went so smoothly that nobody even ended up noticing the change!
Do you consider changing your prefixes?
Wondering if you need a new prefix? Alternatively, do you already know that you need one but you’re not sure where to start? Our expert consultants here at TOPdesk can help you plan and execute your desired changes with minimal impact to your end-users. Contact your customer success team to see how TOPdesk can help you change your prefixes for good.
