Teaching and Assessing Soft Skills on a Support Desk

Monday, 08:30, at Oakhill School Trust, which runs IT for six schools from one desk of five. Tomas, the desk lead, is reading the weekend's satisfaction comments before the first bell. Most are fine. One, about a ticket Ben closed on Friday, reads: "Fixed it fast, but made me feel like an idiot for asking." Ben has been on the desk eight weeks. His first-contact resolution is the best on the team, his tickets close faster than anyone's, and his notes are good. Tomas knows exactly what the comment means because he has heard Ben on the phone. Ben is competent and quick. He has the faint sigh of someone who has already solved the problem in his head and is waiting for the user to catch up. Tomas also knows that he has never been taught how to teach this. He knows that "be nicer" is not a coaching plan. Ben, who is good and knows it, will not take kindly to being told he is rude.

Teaching soft skills means turning each one into behaviours a person can see, practise and be shown doing or not doing. Assessing them means looking for those behaviours in real work, in a sample large enough to mean something. The purpose is coaching rather than ranking. The two go together, because a skill that cannot be observed cannot be taught, and a skill that is taught without being observed afterwards is a talk that was given once. This is the last article in our Soft Skills for Technicians series. It depends on the first: why soft skills outrank technical skills at level one made the case that the skills matter most where the fix is already known. This article is about what a desk lead does on Monday morning about the comment.

It starts with why soft skills can be taught and naming the behaviours. Next come role play that is not embarrassing, ticket reviews that read the tone, and satisfaction comments as evidence. Then it covers the coaching conversation, hiring for the skills, and assessing without surveillance. A short war story and the soft-skills review sheet to copy finish the article.

Soft Skills Can Be Taught, Because They Are Behaviours

Soft skills can be taught for the same reason they can be seen. Each one is a small number of specific things a person does or does not do. A thing a person does can be pointed at. "Be more patient" cannot be taught, because it is a description of an inner state and nobody can be coached into a feeling. "Keep the second explanation at the same pace as the first" can be taught. It is a thing Ben either did or did not do on Friday's call. The two of them can listen to the recording or read the chat and see which. Every soft skill in this series breaks down into behaviours like that, and the teaching begins by writing them down.

This is also why the common objection, that people are either good with users or they are not, is wrong in a useful way. It is true that some people arrive with the behaviours already in place, usually because a previous job taught them, and a desk that hires those people saves itself effort. It is not true that the rest cannot learn them. A technician who does not repeat the problem back is not missing a personality trait. They are missing a habit, and habits are built by doing the thing on purpose until it stops needing a purpose. Most technicians acquire a new behaviour in a few weeks of being asked to do it and shown when they did not. Ben's sigh is not his character. It is Friday's habit, and habits can be replaced.

What cannot be taught, or not by a desk lead, is the technician who does not want to deal with people at all. The honest response to that is a different role rather than a longer coaching plan. The second line, infrastructure, scripting and the knowledge base all need people who would rather face a server than a user. Moving a technician there is a promotion for the user, the technician and the desk. Coaching is for the technician who wants to do the job and lacks the behaviours. It is not for changing what somebody wants.

Naming the Behaviours

The first job is a list: each of the four skills, broken into the three or four behaviours that make it up, with a note of where each one can be seen. The list is what the role play practises and what the ticket review looks for. It is what the satisfaction comments are read against, what the coaching conversation names, and what the interview exercise scores. So it is worth getting right once and arguing about as a team. The table below is the list Oakhill's desk settled on. Yours may differ in wording; what matters is that every line is something a reviewer could watch for and say "seen" or "not seen" without reading anybody's mind.

Notice that none of the behaviours is a score and none is a feeling. "Was empathetic" is not on the list because it cannot be observed; "repeated the problem back before acting" is, because it can. The temptation when writing this list is to add the warm words, and the test for each line is whether two reviewers reading the same ticket would agree on it. If they might not, the line is an opinion, and opinions do not coach well. (They argue well. That is a different meeting.)

Role Play That Is Not Embarrassing

Role play has a bad reputation on technical teams. It was earned by every training day where somebody was made to pretend to be an angry customer in front of twelve colleagues. Role play can be done without any of that. The rules that make it work are few. The lead plays the user first, so that the technician's first experience is of watching rather than performing. The scenario is a real ticket from the desk's own history, with the names changed, so that nobody is acting a situation they have not seen. It runs for two minutes, not twenty. It happens in pairs or threes, never in front of an audience. And nothing is scored in the room; the point is to do the behaviour, not to be graded on it.

The stop-and-rewind is the technique that makes the two minutes useful. The technician reaches the moment the behaviour should happen: the repeat-back, the second explanation, the claim with a time. At that point, either of them can say "stop". They go back ten seconds and do it again with the behaviour in. Nobody has to get it right first time, which is the thing people fear about role play. The rewind turns the exercise from a test into a rehearsal. A technician who has rehearsed "tell me what you see on the screen" three times in a quiet room will say it on the phone. The words are already in their mouth.

The most useful variant is the one where the technician plays the user. Ben plays a teacher who cannot find the new register button while thirty children wait. He discovers what the slowed voice sounds like from the other end. No amount of telling him would have done the same. It is also the variant that technicians find least embarrassing, because the user role carries no expectation of competence. It is the one I would run first with anyone who thinks the whole exercise is beneath them. Fifteen minutes a fortnight, in pairs, on one behaviour at a time, is enough. Most of the value is in the rewind.

Ticket Reviews That Read the Tone

The ticket review is the one the desk probably already does, for the fix, and the change here is to read the same ticket again for the behaviours. Feedback and the ticket review covers how to run a review, how often, and how to give the feedback; this article adds the second reading. Having checked whether the fix was right, read the replies as the user read them, in order, and ask three questions. Is the first line a fact about the user's situation? Would the second explanation have sounded different from the first? Who sent the last message, the desk or the user? Three questions, a minute per ticket, and most of the four skills have been looked at.

Some of the behaviours can be searched for rather than read for, which makes the review faster and fairer. "Just", "simply", "as I said", "as per my previous" and "any inconvenience" can be found with a text search across a technician's replies for the month. The count is a conversation starter rather than a verdict. The same search run across the whole desk tells the lead whether this is one person's habit or the desk's house style. That changes the coaching from an individual conversation to a team one. On most desks it is the house style, picked up by every new technician from the templates and the people around them. No individual is to blame for a template.

The review needs the whole exchange in order, including the internal notes and the handovers, because the behaviours live in the sequence rather than in any single message. A reply that looks curt on its own may be the fourth in a patient exchange; a claim with a time means nothing if the history shows the time was missed. Where the tool keeps a complete event history on every ticket, as QuerySolv does, the reviewer can read the ticket the way the user experienced it. In that case, they can see who wrote each note. Where it does not, the review is harder and the lead should at least read the replies in date order rather than by thread. Sample size matters too: review a handful of tickets per technician per month, chosen at random, not the one the complaint was about. A review built from the complaint teaches the technician that reviews are punishments.

Satisfaction Comments as Evidence

The satisfaction comment is the nearest thing a desk has to a recording of how the user felt. It is evidence about soft skills in a way the satisfaction score is not. A score of two tells the lead something went wrong; "fixed it fast but made me feel like an idiot for asking" tells the lead which behaviour. Read the comments, not the scores, and read them against the behaviour list. There is "explained", "patient", "kept me informed", "knew what to do next" on one side. There is "rushed", "talked down", "nobody told me", "did not know what to do" on the other. The positive comments are evidence too, and the technicians who collect them are the desk's examples for the role play.

Per-technician reading needs care and a rule, and the rule is the one this library applies everywhere. A per-person figure is for coaching, never for ranking. It is not read at all below an agreed minimum of responses. Satisfaction by category, and carefully by agent explains why. The short version is that a handful of comments reflects which tickets a technician happened to get far more than how they handled them. The technician who takes the hardest tickets will collect the sharpest comments. A lead who reads one month's comments as a league table has measured the queue and blamed the people in it.

Used properly, the comments are the before-and-after of coaching. Tomas pulled every comment on Ben's tickets for the eight weeks, read them against the list, and found the pattern. Four comments mentioned speed, three mentioned feeling rushed or talked down, and none mentioned being told what to do next. That is a coaching plan in itself: patience and clear writing, with listening to check. Three months later the same pull is how Tomas knows whether the coaching worked. The reports most help desk tools produce, QuerySolv's included, make the pull a filter on satisfaction by technician rather than a search through old e-mails. The comments were always there. The list is what makes them readable.

The Coaching Conversation

The coaching conversation is about one behaviour, with one example, one practice and one check date, and it takes about fifteen minutes in private. One behaviour, because a conversation about four things changes none of them. One example, because a real ticket is something the technician can look at, while "users say you can be abrupt" is something they can only defend against. One practice, because the technician leaves with a thing to do rather than a thing to be. And a check date, because a coaching conversation with no follow-up is a complaint delivered gently.

The shape that works is to show the ticket and ask before telling. "Here is Friday's ticket; read your two replies as the user would have. What would you change?" Most technicians find the behaviour themselves when asked that way, and a behaviour a person found is one they own. If they do not find it, name it, specifically and without adjectives: "the second reply is the same steps as the first, slower; the rule is a different route at the same pace." Then agree the practice: "for the next fortnight, when a first explanation does not land, ask what they see before saying anything else". Agree the date you will both look at a few tickets again. Never "be nicer". Never in front of anyone else. Never on the day of the complaint, when both of you are reacting to it.

The technician who disagrees is common and is not a problem, provided the disagreement is about the ticket rather than about whether soft skills matter. Ben's first response was that the teacher had been slow and he had been efficient, which was partly true and entirely beside the point. Tomas's reply was that efficiency the user experiences as contempt costs the desk the next ticket, which the comment proved. The argument that settles most of these is the one from the first article in this series: the fix was known, so the fix was not the difference, so the difference was something else. Technicians who are proud of their technical skill tend to accept that argument, because it does not take the skill away from them. It just says it was not what the comment was about.

Hiring for Them

Hiring for soft skills is the cheapest form of teaching them. It is done with the same list, turned into an exercise that every candidate does and a rubric agreed before the first interview. What to screen for in a support hire makes the case for putting these skills first; Interview exercises that actually predict covers the design of the exercises themselves. The one worth borrowing here is the written reply: give the candidate a short, slightly muddled ticket and twenty minutes, and score the reply against the clear-writing behaviours. Is the first line a fact about the user? Is there one next step with an owner? Is there a time? Is there jargon the user did not use? The candidate who has never worked a desk can still score well, which is the point. The behaviours are not experience, they are habits, and the exercise shows who already has them.

Fairness is the spine of this and it is not optional. Use the same exercise, the same ticket, the same time limit and the same rubric for every candidate. The rubric is written down before anyone is interviewed. More than one person does the scoring. No trick questions, no "how would you handle an angry user" improvisations that reward confidence over skill, and nothing in the rubric that touches anything a fair employer would not ask about. The desk lead owns the craft of the exercise. The organisation's HR function owns the rules around it, and the lead should check the exercise with them before using it. A rubric built from the behaviour list passes that check easily, because every line on it is about what the candidate did in the exercise and nothing else.

Assessing Without Surveillance

Assessment is where a well-meant programme turns into a scoreboard, and the guard against it is to assess behaviours seen in a sample, never scores ranked across people. The difference is the difference between "in the eight tickets I read this month, you repeated the problem back in six and gave a time in all eight" and "you are fourth of five on satisfaction". The first is information a technician can act on and would want to know. The second is a position in a table that depends mostly on which tickets the queue handed them. The article dashboards that motivate instead of surveil explains what happens to a team that is shown the second kind every morning. Nothing good, and not for long.

The rhythm that works for a small desk is a monthly read of a few tickets per person against the behaviour list. The findings are written on the review sheet at the end of this article. A quarterly conversation covers the pattern. The sheet is shared with the technician; it is not shared with the team, and it is not totalled into a number that goes on a wall. The team's standard is the behaviour list, agreed by the team, and the assessment is of each person against the list, by a lead who has read the tickets. That is enough to see improvement, enough to catch a drift, and far too little to rank anyone, which is the right amount.

The honest limit is that the lead's reading is itself a judgement, and two leads might read the same reply differently. The behaviour list reduces the disagreement without removing it, and the fix is the one used in the ticket review. Where a line is in doubt, have a second person read the ticket. Where two readers cannot agree, the line is probably an opinion and should come off the list. Assessment of soft skills will never be as clean as counting closed tickets. It is a great deal more useful, and a desk that only measures what is clean is measuring the smaller half of the job.

A Short War Story: The Leaderboard at Bluewater Bank

At Bluewater Bank a desk lead called Felix decided to improve his team's soft skills. He published a weekly table of satisfaction scores by technician on the wall screen. For one quarter the bottom of the table was occupied, most weeks, by a technician called Grace. Her average over eleven responses was the lowest on the desk. Grace was also the technician the branches asked for when a till was down. She took most of the escalated tickets the others could not finish and wrote the replies the rest of the team quietly copied. Her eleven responses came from eleven of the hardest tickets of the quarter. The comments under the scores, which nobody had read, said things like "took ages but Grace was the only one who explained it". Grace resigned at the end of the quarter for a desk across the road. The following two months' comments across the whole team got sharper, because the hard tickets now went to people who did not want them. Felix spent three months and a hiring process replacing a technician the bank had been lucky to have. The review afterwards found that the table had measured which tickets each person had been given and ranked the people for it. It had taught the team that the way to score well was to avoid the hard ones. The wall screen now shows the queue. The comments are read on Mondays, against a list, by Felix, and the list is the only thing that goes on paper.

The Soft-Skills Review Sheet

The sheet below is filled in monthly by the lead for each technician from a small random sample of their tickets, read in order. It is shared with the technician and nobody else. The behaviours are the list from earlier in this article; a desk should replace them with its own agreed list if the wording differs. Each line is marked seen or not seen per ticket, and the pattern is written in one sentence. The sheet ends with the single behaviour to practise and the date it will be looked at again. It is deliberately not totalled. A total is a score, a score becomes a rank, and this sheet is for the conversation, not the wall.

SOFT-SKILLS REVIEW SHEET — ONE TECHNICIAN, ONE MONTH
Technician: ______________   Reviewer: ______________   Month: ________
Tickets read (random, in date order): #______ #______ #______ #______ #______ #______
Satisfaction comments read this month: ____   (per-person figures are read only above ____ responses)

For each behaviour, mark seen (S) or not seen (N) per ticket, or dash if the ticket gave no occasion.

LISTENING                                                  T1  T2  T3  T4  T5  T6
  Repeated the problem back before acting                  __  __  __  __  __  __
  Asked what the user was trying to do                     __  __  __  __  __  __
  Real problem recorded, not only the request              __  __  __  __  __  __

PATIENCE
  Second explanation: different route, same pace           __  __  __  __  __  __
  No "just", "simply", "as I said", "again"                __  __  __  __  __  __
  Asked what the user sees before describing the screen    __  __  __  __  __  __

OWNERSHIP
  Claimed by name with a time                              __  __  __  __  __  __
  Updated before the user had to ask                       __  __  __  __  __  __
  Handover had a named acceptance                          __  __  __  __  __  __
  Followed up after the fix                                __  __  __  __  __  __

CLEAR WRITING
  First line is a fact about the user's situation          __  __  __  __  __  __
  One next step, with an owner                             __  __  __  __  __  __
  A time of day, not "soon"                                __  __  __  __  __  __
  No unexplained jargon                                    __  __  __  __  __  __

WHAT THE COMMENTS SAID (words, not scores): ______________________________________

THE PATTERN (one sentence): ______________________________________________________

STRENGTH TO KEEP: ______________________   ONE BEHAVIOUR TO PRACTISE: ______________________
PRACTICE AGREED: _________________________________________   LOOK AGAIN ON: ____________

This sheet is shared with the technician only. It is not totalled, ranked or displayed.

Tomas and Ben met on the Tuesday, not the Monday, with Friday's ticket and five others chosen at random. Ben found the slowed second explanation himself on the second ticket he read. They agreed one practice, "what do you see?" before any second explanation, for a fortnight, and a date. The sheet went in a folder. Three months later the comments on Ben's tickets had changed, not from "rushed" to "patient" but from "rushed" to nothing in particular. That is what good soft skills look like in a comment box. The user says the printer works and does not mention the technician at all. Ben's first-contact resolution did not move. It had never been the problem.

Frequently Asked Questions