Lessons from the Field: How to Handoff Tickets from One Tech to Another
I sit in a lot of meetings. Many of these meetings have to do with answering questions surrounding how we as an organization can be better. How can we be faster? How can we be more accurate? How can we be leaner? How do we take this thing to the next level? There are always ideas that get tossed around. Usually, most of them are really good, but there is always one that comes up without failure – We need to communicate better. There are libraries of books written on communication as well as all sorts of tools [KS1] for communication. While these can all be helpful I have found a couple of basic principals apply specifically when it comes to handing off tickets from one technician to another. Let’s jump in.
Don’t Assume
When it comes to technicians and engineers, they tend to be very logical thinkers. It is a reason they do what they do and why they are good at it. But have you ever watched two people try to solve the same problem and approach it from very different angles? This happens because oftentimes, not everyone is working with the same set of knowledge, the same set of past experiences, or even the same set of details with the ticket they are working on. Now, this can be useful if all parties involved can work together and leverage each other’s experiences to solve a problem. However, it requires getting on the same page, and that means communicating everything. The moment you start making assumptions about things, you begin running the risk of heading in different directions on a situation.
Ask Questions
There is actually a pretty simple starting point to asking questions in a troubleshooting scenario. Who? What? When? Where? Why?
Who? This is who is impacted by the issue.
- Who is impacted by this issue?
- Number of users
- What type of user is this? How critical is their business function?
What? This is what has taken place so far.
- What is the issue that is happening?
- What steps have been taken to resolve the issue?
When? This get’s your timeline straight.
- When did the issue start?
- When does the user need this taken care of by?
Where? It helps you find how universal an issue is.
- Where is the issue happening? It can be a geographical location or a section of a building. Maybe it only happens at home?
Why? It helps you find out why something is important to a user.
- Are we trying to change desktop wallpaper? Or is this Quickbooks on payroll day
- Does this issue have a major business impact?
I want to stress that all 5 of these questions are important. If you know the what (internet is down) but do not know who (for a PC for the part-time person who works on Fridays) you may move mountains to get to what seems like a priority 1 issue first thing Monday morning. How frustrating is it to find out that the issue could have waited? This happens all the time in our industry and it irks me! If you find out the who is the CFO, you may run straight away to get a problem solved only to find out that the what of their problem is that they don’t like using the trackpad they have been using for 6 months anymore and wants a mouse. You may get to the janitor later to find out that the badge computer is malfunctioning and there are serious security risks happening in your building. Questions are important. Never assume.
Asking questions like these is a great start to staying on the same page because it levels the informational playing field. Getting this information helps get alignment on things like priority, due dates, and severity of an issue but there is one thing missing to make it work.
Document, Document, Document!
Take good notes! You can ask all the best questions in the world, but if you do not document it for yourself to go back to later or for your peers to refer to, it will all be lost in the sands of time. This means you will be putting teammates back in the position of assuming or trying to find out the same stuff over and over again. That is such a waste of time and a major cause of stress. Imagine if you get a ticket where the notes just say “Jan cannot get to payroll online.” What does this mean? What has been tried? How important is it? Who knows – but these kinds of notes happen all the time. Instead, try something like the below:
Ticket: 1245331
Who: Janet Connor in Human Resources
What is the issue: Jan cannot access the tool used to process payroll online
What has been done: Remotely attempted to connect to Jan’s computer but was unable to see it online in the remote monitoring tool. Asked Jan to try and Google flowers, she said it showed that her computer could not connect to the internet. I looked to see if Jan’s machine showed up in DHCP and was unable to find it. Confirmed DHCP is not full. Jan has a rebooted machine and the issue persisted.
When did the issue start?: Jan said it worked for sure yesterday when she left but didn’t use her computer until 9 this morning, at which point it did not work.
Where is this issue occurring?: In Jan’s office. She said no one else around her is having issues.
Why is this issue urgent?: Jan need’s to process payroll by the end of business today for people to get paid.
Issue resolved?: No.
What are the recommended next steps?: Have someone go to Jan’s office to make sure internet cable is plugged in. Continue troubleshooting from there.
Now, put yourself in the shoes of a technician that has to take over this ticket. You have everything you need to begin working to solve the ticket. How neat is that?
In conclusion – we have to work together when helping solve problems for the people we serve. There is no way around it and a key to making that happen is great communication. Asking great questions and documenting the answers are key to achieving smooth communication and efficient problem solving throughout your team!
Worksighted Team
We are a team of over-enthusiastic people, ready to help our clients utilize technology to spur growth! We love technology and come to work every day eager to solve problems and find ways to impact our clients.
