Setting Boundaries That Hold: The Desk's Behaviour Standard
Monday, 11:30, at Harbourview Clinic. Nadia, who runs the three-person desk, is reading a pattern log with four entries in it. All are about Patrick, who manages the outpatient reception. Entry one: raised his voice at the desk window until the waiting room could hear. Entry two: referred to Ben, the newest technician, as "the work experience lad" in an e-mail copied to the clinic director. Entry three: rang the on-call number at nine on a Sunday evening about a printer that was needed on Tuesday. Entry four, from Friday: told Ben that "Sol always just does it for me" about a change Sol had refused the week before. Ben, who did not know that, did it. Nadia reads the four entries twice. She realises that in the two years the desk has existed, nobody has ever told Patrick, or anyone, what the desk will not accept. The desk has standards. It has simply never said them aloud.
A boundary, at a help desk, is a stated limit on how the desk is treated, with a stated consequence for crossing it. And the stating is the part most desks skip. It is not a limit on what the desk does for a person; that is scope, and it lives in Scope Boundaries. A boundary is about conduct: how people speak to technicians, which routes are for what, and what happens when the line is crossed. It has three parts, the standard, the saying and the consequence, and a boundary missing any one of them is a preference. This article is part of our De-escalation & Difficult Users series. It is about writing the standard, saying it once, and making it hold across everyone who answers the phone.
It covers what a boundary is and is not, then the behaviour standard in plain words. Next come saying it once, in writing, and who says it, followed by a consequence that is real. We cover consistency across every technician, so that nobody can shop around, then boundaries upward. A table of boundaries, crossings and consequences follows, then what holding the line costs and buys. A short war story and the behaviour standard to copy finish the article, in that order.
What a Boundary Is, and Is Not
A boundary is a sentence the desk can say to a person's face, in writing, with the consequence attached. And that test rules out most of what desks privately call their boundaries. "We don't like being shouted at" is a feeling. "We won't be shouted at; if it happens the call ends and continues by e-mail" is a boundary. "People shouldn't go to the IT manager directly" is a wish. "Requests that go to the IT manager are put in the queue with a ticket number and handled in turn" is a boundary. The difference is that the second form in each pair describes a behaviour and names what the desk does in response. It could be sent to the person without embarrassment. If a boundary cannot be written down and sent, it is not one yet.
Boundaries are also not about the service, and a desk that confuses the two will end up punishing people with slow tickets. The ticket about Patrick's printer is handled at the same speed, with the same priority and the same care. That holds whether or not Patrick has crossed every line the desk has. The boundary changes how the desk talks to him, who talks to him and through which channel. It never changes what he gets. That separation keeps the desk defensible when Patrick's director asks, and honest with itself. A desk that quietly deprioritises difficult people has not set a boundary. It has started a feud, and feuds are measured in reopened tickets.
The three parts belong to different people. The standard is written by the desk lead and agreed with the IT manager. The saying is done by the lead or the IT manager, never by the technician, who should not carry the conversation. The consequence is applied by whoever the standard says, which is usually the lead for the first step and the IT manager after that. The technician's part is to know the standard. They apply the in-the-moment line that the frustrated-users series already describes, and write the factual note. The rest is management, which is what managers are for.
The Behaviour Standard in Plain Words
The behaviour standard is half a page that says what the desk will not accept and what the desk promises in return. It says what happens when the line is crossed. It is written as behaviours a person could recognise in themselves. Four or five lines cover nearly every desk. They cover personal remarks about technicians, and shouting or swearing at a person rather than about a situation. They cover contacting technicians outside the desk's channels for non-urgent work, which includes the on-call number and personal phones. They cover going around the desk to a manager before the desk has had its chance. And they cover telling one technician that another agreed to something, when they did not. Each line describes an act. None describes a feeling, a character, or an attitude. After all, "disrespectful" is an argument waiting to happen and "called the technician a name" is not.
The standard says what the desk promises in return, because a standard that only lists what others must do reads as a complaint. The desk's side is short and should already be true. It promises a reply within its stated target, an update before anyone needs to chase, and a named person on every ticket. It promises the same treatment for everyone regardless of how they behave. The last promise is the one that gives the standard its moral weight. "We'll fix your printer just as fast either way; this is only about how we talk to each other" is a sentence a person can accept without losing face. Losing face is what most people are defending when they argue with a boundary.
The standard is agreed with the IT manager before it is used, and HR sees it. The IT manager's agreement is what makes the consequence real, because the consequence will be tested. The lead needs to know in advance that the manager will not undo it on the phone. HR's role is to say whether the standard fits the organisation's own rules of conduct, which it almost always does. Most organisations already have a rule about how colleagues treat each other. HR owns the rules; the desk is not writing new ones, only saying where its own line sits inside them. Keep the standard free of anything that sounds like a legal document, because it is not one. Reading like one invites a person to argue it like one. Half a page, plain words, the desk lead's name at the bottom.
Said Once, in Writing, by the Lead
The standard is sent to a person once, in writing, by the desk lead or the IT manager. It is sent after the pattern log shows a pattern. It is also sent only after the second-time measures of a named owner and a written summary have had a fair chance. It is sent in its own message, never on a ticket about a fault. A conduct conversation attached to a printer ticket reads as retaliation and the person will reply about the printer. It is sent to the person alone, never copied to their manager at this stage. The first conversation about conduct belongs to the two of them, and a copy line turns it into a complaint. And it is sent once. A desk that sends the standard every time the person crosses it has turned a boundary into a template, and templates are ignored.
The message has five parts, and the order is the kindness. First, what the desk has noticed, with dates and in plain words: "on the fourth you raised your voice at the window; on the twelfth you called Ben 'the work experience lad' in an e-mail to Dr Adeyemi; on Sunday the nineteenth you rang the on-call number about a printer needed on Tuesday". Second, the standard, attached or quoted. Third, what the desk promises, including the same service either way. Fourth, what happens if it continues, in one sentence, naming the consequence from the standard. Fifth, an invitation to reply or to talk, with the lead's name. No adjectives, no "we feel", no "unacceptable", because the facts carry the weight and the word "unacceptable" has never once calmed anybody.
Expect a reply, and expect it to be one of three. Some people apologise, often with a reason, and the lead accepts the apology in one line and moves on. This is the commonest outcome and the desk should let it be the end. Some people dispute the facts, and the lead replies with the record, once, and does not argue further. Some people escalate, to their own manager or the IT manager. The lead's message is already written in a way the lead would be happy to have read aloud. That is the whole reason it was written that way. An in-person conversation first is better where the lead can do it calmly. And the message still goes afterwards, because the conversation is not the record. Where tools separate public replies from internal notes as QuerySolv does, keep the standard as a public reply on its own ticket. That way, the sending and any reply sit in a history the lead can find in a year. The log stays in internal notes, where it belongs.
Remember: the behaviour standard is sent once, in writing, by the lead or the IT manager, in its own message. It comes after the facts with dates and before the consequence. It never travels on a ticket about a fault and it never changes the speed of the service.
A Consequence That Is Real
A consequence is real if the desk can apply it alone, on the day, without asking anyone. Most of the consequences desks imagine fail that test. "We'll report you to HR" is not the desk's to apply. "We'll stop supporting you" is not allowed, and should not be. "We'll tell your manager" is real but is the second step, not the first. The consequences a desk actually owns are smaller and sharper. A call that becomes personal ends and continues by e-mail. A person's contacts go through the desk lead only, for a stated period, rather than through whichever technician answers. Requests made outside the desk's channels are logged and handled in turn, not on the spot. And a standard crossed after it has been sent goes to the IT manager, who speaks to the person. Each of these the desk can do on a Tuesday afternoon with nobody's permission. That is what makes them hold.
The consequence written in the standard is the one that is applied, exactly, the first time the line is crossed after the standard was sent. And that sentence is the entire difference between a boundary and a bluff. Suppose a standard says "contacts will go through the desk lead". Three more weeks of the person phoning technicians directly follow, because the lead was busy or felt awkward. That has taught the person that the standard is decorative. If the lead is not willing to apply the consequence, the standard should say a smaller consequence the lead is willing to apply. A small consequence applied is worth more than a large one described.
Some things are never consequences, and the standard should say so, because technicians under pressure will reach for them. The ticket does not slow down. The priority does not drop. The reply does not get shorter, cooler or sarcastic. The person is not discussed in the team chat beyond the factual log. The on-call technician who was rung on Sunday about a Tuesday printer still fixes the printer on Tuesday, with the same care. And the Sunday call goes in the log and nowhere else. The desk's power in this situation is the record and its own consistency. Any consequence that touches the service hands that power to the person, who will have a legitimate complaint by Wednesday. (They will also, in my experience, have the e-mail addresses of everyone who needs to hear it.)
Consistency Across Every Technician
Shopping around is what a person does when one technician holds a line and another does not. They go to the second one, and the line moves. It is not usually calculated. A person who has been told no by Sol simply asks Ben, because Ben is there and Ben is new. Ben does the thing because he does not know it was refused. The person has now learned that the desk's position depends on who answers, which means the desk has no position. That means every future boundary will be tested against each technician in turn until the softest one is found. The softest one is usually the newest or the kindest, and the desk should protect both of them from being that.
Consistency is built from four things, and none of them is a longer policy. The pattern log is readable by every technician, so that a name rings a bell before the call is answered. Each person with a log has a named owner, so that most contacts never reach a second technician at all. Every technician has a one-sentence brief for each open log: "Patrick's contacts go through Nadia until the end of the month; if he reaches you, take the details and tell him Nadia will be in touch today." The team has agreed the standard in advance, in a meeting, in the way A No the Whole Team Can Stand Behind describes for any refusal. That way, Ben holding the line is the desk holding the line and not Ben being difficult. A new technician gets the brief in their first week. The desk's standards are not a thing a person should discover by being shouted at.
The side doors need naming, because that is where shopping goes when the front desk is consistent. The on-call number is for things that cannot wait until the morning. A call that could have waited is logged, handled in the morning, and goes in the pattern log. The on-call technician may say "this will be handled on Tuesday" without apology. Personal phones and direct chat messages to a technician are routed back to the ticket with "let me log that so it's in the queue". The walk-in to a technician's desk is handled as in Redirecting Without Alienating People, warmly and every time. Where every channel lands in the same queue anyway, the routing costs nothing; the point is that the answer is the same through every door.
One exception undoes all of it, and the exception usually comes from above. Consider the IT manager who, once, tells the technician to "just do it this time, he's got the director on his back". The manager has told the person that the standard has a price and the price is the director. Consider the technician who, once, does the refused thing because the person was upset. The technician has told the person the standard has a price and the price is tears. Neither meant to teach anything, but boundaries are taught by exception, not by rule. A person learns the one exception far faster than the twenty times the line held. The standard should be applied slightly more consistently than feels polite, because the alternative is applying it again from the start.
Boundaries Upward
The standard applies to everyone, and the person it is hardest to apply to is the one with a title. That is exactly why the IT manager, and not the lead, carries it upward. A director who shouts at a technician has crossed the same line as a receptionist who does. And the technician's in-the-moment response is the same. What changes is who has the follow-up conversation: the IT manager, with the director, directly, that week. The desk lead sending a behaviour standard to a director is a lead being brave in a way the organisation may not support. The IT manager having a quiet word with a peer is a normal Tuesday. Route it that way on purpose. The wider question of what senior people are entitled to from the desk is in No Shadow SLA. The way a technician declines a senior person's request without refusing the person is in Saying No Upward. The behaviour standard sits beside both and changes neither.
Some organisations will not back the desk against a senior person, and the honest lead finds that out before sending anything. Ask the IT manager, in advance and in plain words, whether the standard applies to the leadership team. Ask what the IT manager will do when it is crossed by one of them. If the answer is a pause, the desk has learned something useful about the limits of its boundary. In that case, it should write a standard that stops where the backing stops rather than one that will be publicly overruled. A boundary the organisation will not hold is worse than none, because the technicians will watch it fail. Better to know the ceiling than to hit it with a junior technician's name on the e-mail.
Boundaries, Crossings and Consequences
The table below is a worked standard for a desk like Nadia's. It shows each boundary as a behaviour, what crossing it looks like in practice, the consequence the desk applies on its own, and who applies it. The consequences are deliberately modest. They are the ones a three-person desk can carry out on the day. They climb to the IT manager only at the point where the standard has already been sent and crossed again. That is the subject of When to Involve Managers, and Which Ones. Abuse is a different thing from a crossed boundary, handled outside this table, and is the subject of the next article.
| The boundary | Crossing it looks like | The desk's consequence | Who applies it |
|---|---|---|---|
| Nobody is spoken to personally | Remarks about a technician's competence, age, background or worth; names | One calm sentence naming it; if it continues, the call ends and the ticket continues by e-mail; factual note | The technician on the call; the lead reads the note that day |
| Shouting is about situations, not at people | Raised voice at a person, at the desk window or on the phone, after a calm request to stop | Conversation moves to writing; contacts through the lead for a stated period | The lead |
| Non-urgent work comes through the desk's channels | On-call number, personal phone or direct message used for something that could wait | Logged, handled in turn in business hours, no on-the-spot fix; entry in the log | The technician contacted; the lead if repeated |
| Requests go to the desk before anyone's manager | Ticket raised by walking into the IT manager's office or through a director | Routed back to the queue with a ticket number, no special speed, kindly, every time | The IT manager |
| One technician's answer is the desk's answer | "Sol always does it for me" to a technician who did not know Sol refused | The named owner answers instead; the refusal stands; the team brief updated | The lead; every technician holds it |
| A standard sent and crossed again | Any line above, after the written standard was received | The consequence named in the standard, applied the first time; the IT manager speaks to the person | The IT manager |
What Holding the Line Costs and Buys
Holding a boundary costs the desk a complaint in the short term, nearly always, and the lead should budget for it rather than be surprised. The person who receives a behaviour standard will often tell their manager. And the manager will often ask the IT manager what on earth the desk thinks it is doing. And the IT manager will need to have agreed the standard in advance and be ready to say "I agreed it, and here is the log". That conversation takes an hour and is uncomfortable. It happens once per person, and it happens far less often after the first two. The organisation learns that the desk writes things down and that its IT manager backs it.
What it buys is technicians who stay, and nothing else the desk does buys that as cheaply. The quiet cost of a desk with no boundaries is not the shouting itself, which is a few minutes a month. It is the flinch when a name appears and the private rota for avoiding it. It is the newest technician learning that the job includes being called names. It is the eventual resignation letter that cites "the environment" and means one person in outpatient reception. The pressures that wear a desk down are the subject of the Helpdesk Burnout series. And a desk that has never said what it will not accept is supplying one of them on purpose. A written standard, sent once, applied consistently, is the cheapest retention measure in the building. It is also free, which is rare for retention measures.
A Short War Story: The Standard That Was Sent Once and Applied Never at Stonebridge Insurance
At Stonebridge Insurance, a claims supervisor called Yvonne had a pattern log with six entries. They were mostly for two things. She rang technicians on their desk phones to bypass the queue. She told each one in turn that the previous one had agreed to prioritise her team. The desk lead, Tom, wrote a careful behaviour standard, agreed it with the IT manager, and sent it to her with the dates. She crossed it the following week by ringing Lucy, the junior technician, directly about a non-urgent report. Lucy, who had read the standard, logged it and said Tom would be in touch. Yvonne rang the IT manager instead, who was in a budget meeting with her director. He told Lucy afterwards to "just sort it this once, it's not worth the noise". Lucy did. Yvonne rang Lucy directly eleven more times over the next two months, and Tom's standard was never mentioned again, including by Tom. Lucy resigned at the end of the quarter, and her exit note said she had been "the person Yvonne phones". That cost the desk a technician it had spent nine months training and the IT manager a recruitment he had not budgeted for. A consequence overruled once by the person who agreed it is not a boundary that failed. It is a boundary that was never there, and everyone on the desk knew it before the manager did.
The Behaviour Standard
The standard below is the half-page the desk lead writes once, agrees with the IT manager, shows to HR, and briefs the team on. The lead sends it to a person when the pattern log says it is time. The first block is the standard itself, written as behaviours and promises so that it can be sent as it stands. The second block is the covering message that goes with it the one time it is sent, with the facts and dates filled in. The third block is the team brief, which is one line per open log and is read by every technician. Keep all three plain; the standard is at its strongest when there is nothing in it to argue with.
THE BEHAVIOUR STANDARD — HALF A PAGE
Desk: ______________ Written by: ______________ (desk lead) Agreed by: ______________ (IT manager)
Seen by HR on: ________ Briefed to the team on: ________ Reviewed: ________
WHAT THE DESK PROMISES EVERYONE
A reply within ______ for every ticket, and an update before you need to chase.
A named person on every ticket, who stays with it until it is done.
The same speed and the same care for everyone, whatever has gone before.
WHAT THE DESK WILL NOT ACCEPT
1. Personal remarks about a technician: their competence, age, background or worth.
2. Shouting or swearing at a person, as opposed to about a situation, after a calm request to stop.
3. Non-urgent requests by on-call number, personal phone or direct message to a technician.
4. Taking a request to a manager before the desk has had the chance to handle it.
5. Telling one technician that another agreed to something they did not.
WHAT HAPPENS IF A LINE IS CROSSED
First: the technician says so, once, calmly, and keeps helping.
If it continues on a call: the call ends and the work continues by e-mail at the same speed.
Afterwards: contacts come through the desk lead, ______________, for ______ weeks.
If it continues after this standard has been sent: the IT manager, ______________, will speak with you.
At no point does your ticket slow down, drop in priority or receive less care.
THE COVERING MESSAGE — SENT ONCE, BY THE LEAD, IN ITS OWN TICKET, TO THE PERSON ONLY
______, I'm writing separately from any open ticket, because this is not about a fault.
Over the last ______ I've noted the following:
on ______, ______________________________________;
on ______, ______________________________________;
on ______, ______________________________________.
I've attached the desk's behaviour standard, which applies to everyone we support.
Your tickets will be handled at the same speed and with the same care as anyone's.
If any of the lines in it are crossed again, ______________ (consequence from the standard).
I'd rather talk than write about this; I'm free ______ and ______, or reply here.
______ (desk lead)
THE TEAM BRIEF — ONE LINE PER OPEN LOG, READ BY EVERY TECHNICIAN
______ (person): contacts through ______ until ______. If they reach you:
take the details, say ______ will be in touch today, log it, do not act on
"______ already agreed" without checking the ticket. Standard sent on: ______.
Nadia wrote the standard on the Monday afternoon and had the IT manager's agreement by Tuesday and HR's nod by Thursday. She briefed Ben and Sol in ten minutes on Friday. She sent it to Patrick the following Monday with the four dates. He replied within the hour disputing the Sunday call, which she answered with the on-call log entry and nothing else. He did not reply again. He rang the on-call number once more, three weeks later, about something genuinely urgent. The on-call technician fixed it and logged it as exactly that. The standard was never sent again, because it did not need to be. Boundaries that hold are quiet, and the loudest thing about this one was the afternoon it took to write.
Frequently Asked Questions
Should the behaviour standard be published to everyone, or only sent to people who cross it?
Can a technician send the standard themselves if the lead is away?
The person says the standard is insulting and demands an apology. What now?
What if a technician keeps making exceptions out of kindness?
How long should contacts go through the lead after a crossing?
Does any of this need HR's approval?
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.
