The Desk's Personality and Its Limits: When a Light Touch Works
Friday, 16:20, at Acme. Ravi closes a ticket from Marta in sales, whose mouse had stopped working, with: "New mouse is in your tray. The old one died doing what it loved." Marta replies with a thumbs-up and a "ha", and tells two colleagues that IT are all right. Twenty minutes later Ravi replies to a ticket from the finance director. The payroll export has failed on the afternoon it is due. Ravi writes: "Looks like the export has gone on strike for the weekend! Having a look now." The finance director forwards it to the managing director with one line on top: "Is this how IT treats a payroll failure?" Same technician, same afternoon, same personality. One ticket was a birthday and one was a funeral, and Ravi brought the same hat to both.
Nothing about Ravi's instinct is wrong. People prefer dealing with a person, and a person has a personality. A desk that never sounds like anyone is a desk that requesters avoid when they can. The mouse line made Marta's Friday slightly better at no cost to anyone. The payroll line made a bad afternoon worse for someone who was already frightened. It did so in front of the one reader Ravi would least have chosen. The instinct was fine. The judgement about which room he was in was missing, and judgement is the subject of this article.
A desk's personality is the recognisable warmth and lightness in its voice beyond the bare facts: the small human touches that tell the requester a person wrote this. Formality is how much distance a message keeps: first names or titles, contractions or full forms, "Hi" or "Dear". The forwardable message is any message that will be read by someone other than the person it was written for, which is more of them than you think. This article is part of our Support Tone & Voice series. It is about where the desk's personality is welcome, where it is not, and how to tell the two rooms apart before pressing send.
It starts with why a desk is allowed a personality at all and when a light touch helps. Then come four tests for when it is wrong, formality by audience, and staff versus external customers. Next are the message that will be forwarded, personality without a mascot, and teaching judgement rather than rules. A short war story and the tone-by-situation table to copy finish the article.
A Desk Is Allowed a Personality
The case for personality is practical, not decorative. A requester who feels they are dealing with a person asks sooner, explains more, and forgives more when something goes wrong. A requester who feels they are dealing with a form does the opposite. They wait until the problem is bad, write "it's broken" and nothing else, and read every delay as neglect. The warmth in a reply is what turns the second requester into the first, and it is cheap. Using their name, remembering their last ticket, one line that shows you noticed it is Friday. None of that is a joke. All of it is personality.
The limits exist because personality is in service of the work, and the work is a person with a problem. A light line after the facts, on a good day, about an inanimate object, costs nothing and earns a little. Suppose the same line comes before the facts, on a bad day, about something the requester is frightened of. It costs the desk its credibility with that requester and with everyone they forward it to. Personality is not a brand. It is a judgement made on every message about whether this reader, in this moment, has room for anything besides the answer.
The voice itself, the three to five traits that stay fixed in every message, is decided in what tone and voice mean for a help desk. Nothing in this article changes it. Personality is a feature of tone. It is turned up for Marta's mouse and down to nothing for the finance director's payroll. The voice underneath is the same in both: plain words, a next step, ownership, a colleague's register. Ravi's payroll reply did not fail because it was warm. It failed because it was light in a room with no room for lightness.
When a Light Touch Helps
A light touch helps when four things are true at once. The news is good or neutral. The requester is not upset. The stakes are low: a mouse, a toner cartridge, a meeting-room screen, not money, not data, not anyone's job. And the relationship already exists, or the requester started it, because a joke from a stranger is a different thing from a joke from a colleague. Marta's mouse ticket passed all four. The payroll ticket failed three of them in the first sentence.
Within those limits, the light line has rules of its own. It comes after the facts, never instead of them: "New mouse is in your tray" first, then the line. It is one sentence. It is about the system, the object, the process or the desk itself, and never about the requester, their request, their department or their competence. "The old one died doing what it loved" is about a mouse. "Third mouse this year, what are you doing to them?" is about Marta, and however fondly meant, it is a sentence she might have to explain to someone. The target is always the inanimate. The inanimate does not forward e-mails.
The best light touches are not jokes at all. They are the small evidence that a person read the ticket: "Done, and I have moved the spare to your desk so this does not catch you on a Friday again." "Fixed; your presentation will be fine for Monday." "Reset, and I noticed your account was due to expire next week, so I have pushed that out too." These lines are warm because they are specific, and specific warmth cannot be forwarded as flippancy because there is nothing flippant in it. If the desk's personality lived entirely in sentences like these, this article would be one section long.
When a Light Touch Is Wrong
A joke does not know which room it is in. You have to tell it, and the way to tell it is four questions, asked before the line is typed. Is anything lost or at risk, including time the requester cannot get back? Is the requester upset, frightened, embarrassed or angry, as far as you can tell from the ticket? Does this touch money, pay, patients, customers, legal matters or anyone's employment? Could this message be read by someone who was not there, including a director, an auditor or a customer? One yes, and the light line goes. Four noes, and it may stay.
- Is anything lost, at risk, or already costing the requester time?
- Does the requester sound upset, frightened, embarrassed or angry?
- Does the ticket touch money, pay, patients, customers, legal matters or someone's job?
- Could this message be forwarded to someone who was not part of the conversation?
- Has this requester, or this ticket, already had a bad experience with the desk?
- Would you say the line out loud to this person, in this moment, with their manager listening?
The reason a light line in a bad moment lands so badly is that it reads as not caring. The requester whose payroll export has failed is not in a position to find the export funny. A message that finds it funny tells them the desk has not understood what is at stake. It does not matter that Ravi was already working on it. The first sentence said he thought it was a strike, and the finance director stopped reading there. Never joke about payroll. Not once. Not in the good months. The same goes for anything on the money-pay-patients-customers-legal-jobs list, where a joke is read as evidence in a way it is nowhere else.
The other place lightness is wrong is in an outage. Forty people are reading the notice for one piece of information, the next update time. Anything in the way of that information is in the way. The right tone for an outage is short, factual and the same from the first notice to the all-clear. The content, channels and timing of those messages are the subject of the first notice. I once signed off an outage notice with "hang in there". The finance director, who was reading it in a meeting with the auditors, did not. The all-clear can carry one warm line, because the news is good and the stakes have gone; the notice itself carries none.
Formality by Audience
Formality is a dial set by the organisation first and the audience second. A warehouse operator's desk and a law firm's desk start at different points on the dial. Both are right for where they are. The organisation's own habits set the baseline: how people address each other in the corridor and on the internal mail. The desk should sit at that baseline for its own staff and never below it on a first contact. A desk that is more casual than the organisation around it reads as not taking the organisation seriously. A desk that is one notch more formal than the baseline reads as careful, which is fine. Three notches more formal reads as a legal notice, which is the subject of writing like a person, not a policy.
Above the baseline, adjust for the person. Senior people get one notch more formality than the baseline. So do people you have never dealt with, people writing in a formal register themselves, and people from outside the organisation. The notch is small: "Hello" rather than "Hi", full forms rather than contractions, the surname if the organisation uses surnames. And no light lines until they have used one first. Match the requester's register where you can see it. A requester who writes "Hiya, mouse dead, help" has told you where they are. A requester who writes "Dear IT Department, I am writing to report" has told you too. Reply one notch more formal than they wrote, never less.
Formality is not the same as coldness, and the mistake most desks make when told to be more formal is to become colder instead. A formal reply still names the requester, still says who did what and by when, and still sounds like a person. "Good morning, Mr Osei. I have reset your account and you should be able to sign in now. If it fails, please reply to this message and I will call you." That is formal, warm and short, and it would survive being forwarded to anyone. Formality moves the greeting and the contractions. It does not remove the person.
Staff Versus External Customers
A desk that serves its own staff and a desk that serves external customers are two different rooms, and the difference is not only formality. Staff share context with the desk: they know what the finance system is, they know who Tomas is, they have been in the building. A reply to staff can be brief because the gaps are filled in by shared knowledge. An external customer shares none of that. They do not know Tomas and they do not care about the finance system. The desk is not "IT" to them; it is the organisation, and every message is the organisation speaking. An in-joke to a customer is not an in-joke. It is a joke they were not in on.
For external customers, the baseline is one notch more formal than for staff. The light line is reserved for good news to people who have been warm first. Nothing in the message refers to internal names, systems or processes the customer could not be expected to know. Privacy adds a layer: a customer's message is about their account and their data, and a reply that is casual about either reads as careless with both. The structure of a good reply is the same, facts, next step, name; the register is set for a stranger who is judging the organisation by this paragraph.
The practical way to keep the two rooms apart is to make them two rooms. If the desk serves external customers as well as staff, run them as separate departments with their own mailbox and form. QuerySolv and many other tools let you do this. That way, the formality setting is made by routing rather than by memory. A technician picking up a ticket from the customer queue knows which register to use before reading a word. The templates in that queue are already written for strangers. With both kinds of requester in a single queue, the outcome is predictable. Sooner or later, somebody writes "the old one died doing what it loved" to a customer.
The Message That Will Be Forwarded
Assume every message can be forwarded, because the ones that cause trouble always are. The reply to the finance director was written for the finance director and read by the managing director. The outage notice is written for staff and screenshotted to a customer. The refusal of a request is written for the requester and pasted into a complaint. A message's actual audience is its named reader plus everyone that reader can think of sending it to, and on a bad day that list is long. Write for the second reader. The second reader has no context, no relationship with the desk, and no reason to assume you meant well.
The forwardable message has three properties. It contains the facts and the next step, so a second reader can see the desk was doing its job. It contains nothing the desk would have to explain to a director. That means no light lines about anything on the risk list, no comments about the requester, and no comments about other teams. And it is written in a register that is right for the most senior person who could plausibly read it, not the most junior. A forwardable message needs the facts, the next step, and nothing you would have to explain to a director. Most messages meet this without effort. The ones that do not are the ones that had a line in them that the writer was pleased with.
The forwarding rule applies inside the ticket too. Internal notes are for the desk. The place for the sentence you would not want the requester to see is the note rather than the reply. If you run QuerySolv, a ticket keeps public replies and internal notes apart for exactly this reason. But write even the note as if the requester might one day read it. Tickets get exported, audited, quoted in complaints and shown to new managers. A note that says what the technician really thought of the requester is a note that will eventually be read by the requester. The full list of things that should never be in a ticket at all is in what never to write in a ticket. For tone, the rule is that the note can be blunt about the problem and must be neutral about the person.
Remember: a light touch comes after the facts, is one line, and is about the thing and never the person. It belongs only where nothing is at risk and nobody is upset. No money, pay, patients, customers or jobs can be involved. The message must be safe to forward to a director without explanation. One yes to any of those and the line goes.
Personality Without a Mascot
Somewhere between "the desk should sound like a person" and the next budget meeting is a proposal for a desk name with an exclamation mark in it. It comes with a mascot, a tagline under every message and an emoji policy. Resist all of it. A mascot is a personality bolted on from outside. Requesters can tell the difference between a technician who noticed it was Friday and a cartoon owl that says it is Friday to everyone. The personality that works lives in specific, small, true things in individual messages: the spare moved to the desk, the expiry date pushed out, the name remembered. It cannot be designed by a committee because it is not a design. It is attention.
Taglines are the mascot's quieter cousin and fail the same way. "Here to help!" under every reply is read once, ignored for a month, and noticed again only on the day the desk was not there to help. Then it becomes a small irony forwarded to a manager. Emoji are a question of baseline: fine where the organisation uses them in its own internal mail, and not where it does not. Never to external customers or in anything on the risk list. The desk does not need a style of its own in any of this. It needs to match the building and then be slightly more careful.
Where the desk has a genuine, earned personality, it shows in the replies that requesters forward for the right reasons. "This is what IT should sound like" is the forwarded message you want. It is earned by a hundred plain, warm, specific replies and not by any of them being funny. The warm line is welcome. The desk's reputation is built on the sentence before it.
Teaching Judgement, Not Rules
You cannot write a joke policy. A rule that says "no humour in replies" produces a desk that sounds like a notice, and a rule that says "humour is encouraged" produces Ravi's payroll reply. What you can teach is the four questions, by example, with real messages from the desk's own tickets. Put three replies in front of the team. One where a light line worked. One where it was removed before sending and the reply was better for it. And one where it went out and came back forwarded. Ask which questions each one would have failed. After three or four such sessions the questions become reflex, and reflex is the only form of judgement that works at 16:20 on a Friday.
Make the out-loud test a habit. Before sending anything with a light line in it, say the line aloud as if the requester were standing there with their manager beside them. Most lines that fail the four questions fail this test in the first word. The technician hears it and deletes it, and nothing needs to be said by anyone else. Peer review, described in one voice across five people, catches the rest. A reviewer reading ten replies against "would the requester know this came from our desk" will also notice the one that would not survive being forwarded. The conversation is thirty seconds long.
Protect the technician whose line went wrong. Ravi's instinct, to be a person rather than a form, is the instinct the desk wants. A technician who is told off hard for one misjudged line will remove the personality from everything. That costs the desk more than the line did. The conversation after a bad forward is "which of the four did this fail" and "what would you send now", and nothing else. (The finance director will not need the conversation to be longer. The finance director has already had it with the managing director.)
A Short War Story: The Lie-In at Bluewater Bank
At Bluewater Bank, a branch manager called Dana raised a ticket at 08:55. Every terminal in her branch had locked her and her staff out, with eleven customers already waiting at the door. Owen on the desk was fast, good, and liked by everyone who dealt with him. He replied inside two minutes with "Looks like the system decided you all needed a lie-in! Unlocking now." The branch was open by 09:10. Dana forwarded the reply to the regional director at 09:12 with the words "fourteen minutes of customers at the door and this is the attitude". The regional director forwarded it to compliance. Compliance issued a one-paragraph instruction that all support correspondence must use "formal and professional language" with immediate effect. For the next year every reply from the desk read like a legal notice. Requesters stopped replying to anything that did not need an answer. The desk's satisfaction comments, which had been the best in the bank, fell to the middle. The lie-in line had been fifteen words, sent in good faith by the right person doing the right thing quickly. One light line in the wrong room cost the desk its personality in every room.
The Tone-by-Situation Table
The table is the template for this article, with one row per situation the desk meets. Each row says whether a light touch is allowed and how formal the message should be relative to the desk's baseline. It also gives what the message must contain before anything else and an example of a first line. Copy it into the desk's style guide, set your own baseline in the second column, and add rows for the situations your desk meets that are not here. The example lines are deliberately plain; the light line, where one is allowed, is the technician's own and comes after the facts.
| Situation | Light touch? | Formality | The message must contain first | Example first line |
|---|---|---|---|---|
| Routine request done, low stakes, staff | Yes, one line, after the facts, about the thing | Baseline | What was done, what to check, where to reply | "Hi Marta, the new mouse is in your tray." |
| Waiting on a part or a supplier | Rarely; only if the requester has been light first | Baseline | The date, the next update time, the workaround | "Hi Sam, the part is now due Thursday." |
| A question back to the requester | No | Baseline | The one question, and what happens once answered | "Hi Priya, one question before I can set this up." |
| Anything involving money, pay, patients, customers, legal or jobs | Never | One notch up | What is being done, by whom, next update time | "Hello Farah, I am working on the payroll export now." |
| Requester is upset, frightened or angry | Never | Baseline, warm | The impact named specifically, then the plan | "Hi Jo, I can see the whole team is locked out." |
| Outage notice to many people | Never | One notch up | What is down, who is affected, next update time | "E-mail is down for all staff since 09:40." |
| All-clear after an outage | One warm line is fine at the end | Baseline | What was fixed, what to check, what happens next | "E-mail is back for everyone as of 11:05." |
| Refusing a request | No | Baseline | The impact, the boundary, the reason once, what you can do | "Hi Rosa, I can see the tablets are slow." |
| The desk made a mistake | Never | Baseline, plain | What we did, what it affected, what is fixed, what is next | "That was our error: we removed the wrong group." |
| Senior person, first contact | No | One notch up | Facts and next step, in under eighty words | "Hello Mr Osei, I have reset your account." |
| External customer, any subject | Only good news, only if they were light first | One notch up | Facts, next step, no internal names or systems | "Hello Ms Reyes, thank you for your message." |
| Anything likely to be forwarded | No | Set for the most senior possible reader | Facts, next step, nothing needing explanation | "Hello, here is where this stands as of 14:00." |
Ravi kept the mouse line and lost the payroll line, which is the right trade. The four questions went above his monitor on a sticky note that said only "lost? upset? money? forwarded?". The finance director got a second reply that afternoon: four sentences, formal, with the export restored and a note on what had caused it. The finance director did not forward that one anywhere. Marta is still telling people IT are all right. The managing director has not heard from the desk since, which, for a managing director, is the best review there is.
Frequently Asked Questions
Are emoji acceptable in support replies?
The requester is joking with us. Can we joke back?
How formal should we be with senior managers?
Should external customers ever get a first-name sign-off?
One of our technicians is naturally very dry. Do we suppress that?
One of our replies was forwarded and caused a problem. What now?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.
