Algeria AgencyIT consulting & support
IT support: the reported fault is not the fault
Nobody rings to describe a defect. People ring to say what they can no longer do, and all the work starts with that translation.
The article on the support family sets the rule about the clock and the problem with hourly billing. This page goes one level down: it describes what actually happens during a call, because that is where half the billed time is won or lost.
The first thing to know is that a fault is never reported as it is. Nobody rings to say "the print service will not start": they ring to say "I cannot get my delivery notes out any more", which is not the same sentence.
The second is that half a year’s calls are the same call. That is not a defect in the people: it is a defect in a service that repairs without ever leaving anything behind.
This article handles both of those, the question of who is allowed to say yes, and a rule we apply without exception: we never ask for a password, and the reason is not politeness.
The reported fault is not the fault
A support call always starts with a story. The person describes what they can no longer do, in the words of their own trade, and those words describe a consequence rather than a cause.
"The internet is down" means, half the time, an application that no longer opens while the connection is perfect. "The printer is broken" often means a machine that lost its print queue, the printer being in fine health and used by three other people.
That gap is not imprecision. It is the normal way a human being describes a tool: by what it lets them do. A technician treating the story as a diagnosis looks in the wrong place, and it is the commonest cause of a visit lasting three times too long.
The translation is done with three questions and no more: what exactly were you trying to do, what did you see on screen, and can anybody else do it right now. The third is the most useful of the three because it instantly separates the machine from the service.
A support desk asking those three before taking control cuts the average length of a visit without buying anything. It is the only free improvement on this page, and it sits in a habit rather than in a tool.
The first ten minutes decide the rest
What follows in a visit is almost entirely determined by what gets established at the start: is it the machine, the network, the server, or the remote service. A wrong branch in the first minute is paid for in hours.
The separation is done by comparison rather than by measurement. Does the problem exist on another machine? On the same machine under another account? On the same account from a phone? Three two-minute tests that eliminate three quarters of the hypotheses.
That method has a counter-intuitive consequence: the fastest technician is not the one who knows the most solutions, it is the one who eliminates fastest. Knowledge serves afterwards, and it serves little if the branch is wrong.
The classic trap is premature modification. Reinstalling a driver, clearing a cache, restarting a service before narrowing things down: it sometimes makes the symptom disappear, which is worse than doing nothing — the problem will come back and nobody will know what set it off.
The rule we apply: no modification before the branch is established, and every modification is noted before it is made. Those two sentences cost nothing, and they are what separates a visit from a series of attempts.
The same call, forty times a year
Look at any twelve months of visit history and group the calls by real cause rather than by date. What you will see is always the same: a handful of causes producing half the calls.
The network share that disconnects at startup. The document that opens read-only because somebody left it open. The password that expires and the message that appears at the wrong moment. The mail signature that disappears. The full disk.
Each of those causes gets settled once and for all, often in under an hour. They do not get settled because support is called on a symptom, resolves the symptom, and hangs up: the mechanism is intact and it will reproduce the symptom next week.
That is what the structure of hourly billing encourages without anybody deciding it, as the family article explains. It is not an accusation: it is the absence of a moment where somebody groups the calls by cause, and that moment only happens if it is written into the contract.
The countermeasure is a half-hour quarterly sort: classify the quarter’s calls by cause, take the top three, and handle them at the root. That exercise alone usually removes a third of the following year’s volume.
The machine, the person, and the learned workaround
A share of the problems we find are no longer reported because they have been learned. The person found a path that works, they have been taking it for months, and as far as they are concerned the matter is closed.
The forms are always the same: opening a file from another package to dodge a crash, printing from a neighbouring machine, saving to the desktop and copying by hand, restarting every morning because otherwise "it drags".
Those workarounds are efficient at the scale of one person and ruinous at the scale of a company, because they cost a few minutes a day multiplied by the number of working days. And above all they leave the scope of support permanently: nobody will ever report them.
They also have an underrated side effect: they get passed on. A new employee learns the workaround along with the job, without knowing it is one, and will defend it if anybody tries to change it.
The only way to find them is to ask, and the asking has to use the right words. Do not ask "are you having any problems" — the answer is no. Ask "what do you do every day that annoys you". The phrasing completely changes the answers you get.
Who is allowed to say yes
A ticket rarely stalls on a technical problem. It stalls because a decision is needed and the person on the phone is not allowed to take it.
The cases are mundane: a part has to be bought, a machine replaced, a change affecting everybody authorised, or an hour’s interruption accepted. The technician waits, the person who called waits for an answer from management, and the ticket stays open in a state nobody measures.
That is an organisational problem rather than a competence one, and it gets settled in writing before the first incident. Two things have to be named: who can authorise spending below a certain amount, and who can authorise an interruption of service.
Those two people are not necessarily the same, and neither is necessarily the director. A company that delegates a small sum and an interruption window to a manager who is on site shortens half its incidents without changing anything else.
The corollary is a requirement on the supplier: it has to state clearly, in its report, when a ticket is waiting on a decision at your end rather than at theirs. Without that distinction, every delay is attributed to support, including the delay that belongs to you.
What a support desk should not be allowed to do
Support access is powerful, and the limits of that power should be written rather than assumed. It is not a question of trust: it is a question of traceability, and it protects both sides.
First limit: no change affecting several people without prior agreement and a written note. Changing a mail setting to solve one person’s problem can break twelve others’, and nobody will make the connection the next day.
Second limit: no access to contents. A technician repairing a mailbox has no business reading messages, and a technician solving a sharing problem has no business opening documents. When a check requires opening a file, it happens with the person, on their screen, and it gets said out loud.
Third limit: no permanent administrator account used for daily work. A technician browsing and reading mail from a high-privilege account turns the slightest incident into a major one, and that holds at the supplier as much as at your premises.
Fourth limit, the forgotten one: nothing irreversible without a trace. Every structural change — a firewall rule, an access right, a deletion — leaves a dated line saying what, why, and how to go back.
Remote access, and what it sees
Taking control of a machine is the most effective tool on this page, and it is also the most intrusive. It deserves three rules almost nobody writes down, because they look obvious until the day they are not.
The first is visible consent. The person has to see a session start, know when it ends, and be able to end it. A tool allowing a silent connection exists and has legitimate uses on a server; on an employee’s machine it has none.
The second is that an employee’s machine holds their life. Personal messages, photographs, a private folder, a browser search. That is not a hypothesis, it is the norm, and a technician browsing a desktop looking for a file will see part of it.
The third is prior notice, given by you rather than by us: staff have to know that support can take control, under what conditions, and at whose request. A company that never said so creates an unpleasant surprise at the first incident, and the surprise rebounds onto the tool.
Those three rules have a practical benefit on top of the rest: somebody who is not afraid of the tool calls sooner. A dreaded support desk is one called at the last moment, which is to say once the fault has become expensive.
The slow machine, the worst-handled case
It is the commonest request and the one that gets the market’s worst answer: "it needs replacing". In most cases we see that is false, and replacing leaves the problem intact because the cause follows the data.
Four real causes, in order of frequency. A saturated disk, which makes a machine slow long before it is full. A mechanical disk where the rest of the estate has solid-state. Too many programs starting at boot. And a security package duplicating the system’s own, both scanning the same files at the same time.
All four are handled in an afternoon and without a purchase, except the second, which needs an inexpensive part and completely transforms a five-year-old machine. It is by far the best ratio of spending to felt effect in this whole pillar.
When replacement is the right answer has to be said honestly: when the machine no longer receives security fixes, when a part costs more than a third of a replacement, or when the business package has requirements the machine can no longer meet. Three criteria, not an impression.
The check you can run yourself in thirty seconds: look at the free space on the main disk. Under ten per cent, you have found the cause, and it is fixed without calling anybody.
Support must never ask for a password
It is the shortest rule on this page and the one with the most effect, because it does not protect against support: it protects against everybody who rings afterwards claiming to be support.
The mechanism is simple. An employee whose password support has asked for three times has learned that this is a normal request. Six months later somebody rings, says they are from support, and gets the password in thirty seconds. The habit was installed by the legitimate service.
There is no situation where it is necessary. A technician needing to act on an account uses their own administrative rights; a technician needing to see the person’s screen takes control while that person types their own password; a forgotten password gets reset, not requested.
The rule has a counterpart on your side and it matters just as much: tell your people. One sentence in an internal message — "nobody, including our supplier, will ever ask you for your password" — is worth more than any product sold in the security family.
And a third consequence, less obvious: it gives you a simple test for evaluating any supplier. If they ask for a user password on the first call, you already know how they work, and you know it before signing.
What to record at every incident
An intervention history is only worth something if it allows grouping by cause, and that takes four fields. Three of them are missing from most tools we see.
The first is the symptom in the person’s own words, as it was told. It looks useless and it is not: it is what allows the same problem, reported differently by two people, to be recognised.
The second is the real cause, written afterwards and in one sentence. It is the field most often missing, and the only one that makes section 2’s quarterly sort possible. Without it, a history is a list of dates.
The third is what was changed, exactly, with the time. It serves twice: for going back, and for the next unexplained incident three days later on the same machine.
The fourth is waiting time on the client’s side, kept distinct from intervention time. It is section 4’s field, and it is the only one that allows an honest conversation about delays — without it, every delay looks like the supplier’s.
When support becomes teaching
A share of calls are not faults. They are questions: how do I do this, why has that changed, where has this button gone. They reach support because there is nowhere else to ask them.
Treating them as faults is an economic mistake. A question answered on the phone gets asked again next week by somebody else; the same question answered by a three-line note posted where the work happens does not get asked again.
The format that works is short and local: a sheet on the wall beside the printer, a note in the shared folder, a sentence pinned in the team’s message thread. A forty-page manual does not get read, and it has never prevented a single call.
There is a second effect, more important than the saving: somebody who knows how does not wait. The real cost of a question is not the technician’s ten minutes, it is the time during which the person does nothing while waiting for the answer.
The rule we apply: from the third time the same question is asked, the answer is no longer a call, it is a written note placed at the site of the problem. That note is a deliverable, and it should appear in the report on the same footing as a repair.
What we do, and what we will refuse to do
What we will refuse: asking for a user’s password, under any circumstances. It is a rule with no exceptions, and it holds for the cases where it would be quicker too — precisely the ones that install the habit.
We will refuse to take control of an employee’s machine without their seeing it and being able to end it, and to bill a visit whose real cause is not written in the report. A history with no causes allows no sorting, therefore no improvement.
We will refuse to recommend replacing a slow machine before having looked at disk space, disk type, programs starting at boot and duplicated security packages. It is the market’s most profitable recommendation and the least often justified.
What we do: the three translating questions before taking any control; elimination by comparison rather than premature modification; the quarterly sort by cause with the top three handled at the root; the written distinction between waiting at your end and waiting at ours; and a three-line note, placed at the site of the problem, from the third occurrence of the same question.
And what you can do this week without us: take your last twelve tickets and try to group them by real cause. If you cannot, that is not you — it is that the field was never filled in, and it is the first thing to ask your current supplier for.
Frequently asked questions
Why does a visit take longer than expected?
Most often because the branch was chosen wrongly at the start. A fault is reported by its consequence rather than its cause, and a technician treating the story as a diagnosis looks in the wrong place. Three questions at the outset remove most of that risk.
How do we reduce the number of calls?
By grouping the quarter’s calls by real cause and handling the top three at the root. A handful of causes produces half the calls, and each is usually settled in under an hour once identified.
Can support ask for our password?
No, and never. A technician acts with their own rights or takes control while the person types their own password. A service that asks installs the habit the next caller will exploit.
Should a machine that has become slow be replaced?
Rarely. Look first at free disk space, disk type, programs starting at boot and duplicated security packages. Replace if there are no more security fixes, if a part costs more than a third of a new one, or if the business package no longer runs.
Can support see our personal files?
It can technically, which is exactly why the rules have to be written: a visible session, the person able to end it, no browsing folders without them. And your people have to know in advance that remote control exists.
Why do our tickets stay open so long?
Often because they are waiting on a decision at your end: a purchase, an interruption, a replacement. Name who can authorise a small purchase and who can authorise an interruption, and require the report to distinguish the two waits.
Where we come in
Twelve tickets grouped by cause rather than by date almost always reduce to three causes. What the grouping does not say is what each costs per month.
- We put each cause into hours lost before proposing any fix at all.
- We look at disk space and disk age before discussing a replacement.
- We take control in front of the user, never in their absence.
We will never ask you for an employee’s password, under any circumstance: a supplier who asks is telling you something about themselves.
Read next
The person everybody asks: the internal relay
In every business somebody who is not in IT absorbs half the problems. What the role costs them, what to give them, and its three limits.Support and maintenance: what you buy when you buy time
It is the only family in the pillar sold by time. Everything turns on a sentence nobody asks for: the moment the clock starts.The quarterly review: holding a provider to what they signed
Between signing and leaving there are two years nobody writes about. Four numbers measured from your side, and a thirty-minute meeting.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.