4.1 Carrying out technical assistance
Technical assistance is the support an application technician gives to users so that they can keep working with the software they depend on. It covers receiving a request, understanding the problem, guiding or fixing it, and confirming that the user is satisfied. Good technical assistance depends on technical skill and on the way the technician treats the person being helped. Example: in a county revenue office, a clerk who cannot print a rate payment receipt is helped quickly and politely, so that the queue of waiting residents does not grow.
4.1.1 Customer relation practices
Customer relation practices are the habits and behaviours a technician uses to build trust, communicate clearly and keep users confident in the support service. A user who is frustrated by a failed application will judge the whole ICT service by how the first contact goes, so the manner of the response matters as much as the fix. Example: when a SACCO member cannot log in to the mobile banking application, a technician who listens, explains what is happening and gives a realistic time for the fix keeps the member's confidence, even if the repair takes an hour.
Principles of good customer relations
- Respect: Treat every user as a valued person whatever their position or level of computer knowledge. Avoid sounding impatient or suggesting that the problem is the user's fault.
- Responsiveness: Acknowledge each request quickly, even if the full solution will take time. A short acknowledgement tells the user that the request has been received and is being handled.
- Honesty: Say plainly what you know, what you do not know and what you will do next. Never promise a fix time that you cannot keep.
- Empathy: Recognise the effect of the problem on the user's work, for example a nurse who cannot open patient records. Showing that you understand the urgency calms the user and focuses the conversation on the solution.
- Confidentiality: Users often share passwords, personal data or business records during support. Use this information only for solving the problem and never discuss it with others.
- Ownership: Take responsibility for a request until it is resolved or properly handed over. The user should never have to repeat the problem to several people.
- Professionalism: Keep a neat appearance, a calm tone and a respectful vocabulary in person, on the phone and in writing.
Communication skills in technical assistance
- Active listening: Let the user describe the problem fully before you respond. Note the key details such as error messages, what the user was doing and when the problem began.
- Asking clear questions: Use short, open questions such as "What happened when you clicked Save?" followed by closed questions to confirm facts. This avoids guesswork and saves time.
- Plain language: Avoid technical jargon with non-technical users. Say "the program has stopped responding" instead of "the process has hung".
- Confirming understanding: Repeat the problem in your own words and ask the user to confirm it. This prevents solving the wrong problem.
- Positive tone and body language: Smile, keep eye contact and speak calmly when working face to face. On the phone, a steady and friendly voice has the same effect.
- Written communication: Emails and messages should be short, polite and structured, with the problem, the action taken and the next step clearly stated.
The way a statement is worded changes how the user receives it, as the table shows.
| Poor response |
Better response |
| "That is not my department." |
"I will find out who can help and make sure your request reaches them." |
| "You must have done something wrong." |
"Let us go through the steps together to see where the problem starts." |
| "It will be fixed soon." |
"I expect to finish by 3 pm and I will call you if that changes." |
| "I do not know." |
"I am not sure yet, but I will check and get back to you today." |
Handling difficult or frustrated customers
- Stay calm: Do not respond to anger with anger. A calm voice and steady pace often reduces the user's tension.
- Let the user speak: Allow the user to explain the frustration without interruption. People calm down once they feel heard.
- Apologise for the inconvenience: Apologise for the disruption without blaming colleagues or the user. This shows care and moves the discussion forward.
- Focus on the solution: Move from the complaint to what can be done, and offer a clear next step with a time.
- Move to a private place: When a user is upset in a busy office, invite them to talk away from the crowd. This spares them embarrassment and stops the tension from spreading to other people.
Providing technical assistance step by step
A consistent procedure makes sure that no request is lost and that every user receives the same standard of service. Following the same steps each time also makes it easier to hand a case to a colleague. Example: in a hotel, a receptionist reports that the booking application will not save new reservations, and the technician follows the steps below.
- Receive and acknowledge the request: Greet the user, confirm that help is on the way and open an entry for the request (the details to record are listed under "Documenting and following up customer requests"). This starts the relationship on a positive note.
- Gather information: Ask whether anyone else is affected and request a screenshot, which is often more accurate than a verbal description, then check it against the details noted while listening.
- Reproduce and diagnose the problem: Try to repeat the problem on the user's computer or a test setup, and check obvious causes first such as network connection, login details and input errors. Work from the simplest cause to the most complex.
- Explain the plan to the user: Tell the user what you are about to do and how long it should take. Warn them before any action that could affect their data, such as restarting the application.
- Apply the solution or guide the user: Fix the problem, or talk the user through the fix so that they learn how to handle it next time. Make only the changes that are needed.
- Test and confirm resolution: Ask the user to repeat the task that failed and check that it now works. Do not close the case until the user agrees that it is resolved.
- Escalate when necessary: If the problem or a complaint needs higher skills, access or authority than you have, say so politely and pass it to the right person, such as a supervisor, with notes of what has already been tried. Tell the user who is now handling it.
- Close the request: Inform the user that the case is closed and complete the record as described under "Documenting and following up customer requests".
Documenting and following up customer requests
Records of technical assistance protect both the user and the technician. They show what was reported, what was done and how long it took, and they help the team to recognise problems that keep returning. Example: a school bursar's office that logs every fee-system complaint can see that most issues arise after term opening, when many parents access the portal at once.
- Request details: Record the date, time, user name, department, contact and the application involved. This allows anyone on the team to trace the request later.
- Problem description: Write the issue in the user's own words so that any colleague reading the record understands what went wrong without asking again.
- Actions taken: List each step tried, including those that failed. Colleagues then do not waste time repeating them.
- Resolution and cause: State what finally solved the problem, what caused it and the time taken. These notes become a knowledge base for future similar cases.
- Status and priority: Mark each request as open, in progress, escalated or closed, and give it a priority based on the number of users affected and the effect on work. This guides the order in which requests are handled.
- Follow-up and feedback: After closing a request, contact the user to check that all is well and ask for brief feedback on the service. This often turns a bad experience into a positive one, and the comments help to improve how support is given.
The rest of this chapter
🔒Create a free account to open more of this chapter.
Free: practical guides, quick cards, workplace scenarios and more.
Create a free account 🔒4.2 Monitoring & reporting on application Performance
Application performance monitoring is the routine practice of measuring how an application behaves while real users work with it, and then communicating the findings to the people who must act on them. A slow or failing application costs an organisation time,…
🔒4.3 Performing application optimization
Application optimisation is the planned process of changing an application, its data and the environment it runs in so that it responds faster, uses fewer resources and serves more users without failing. It follows from performance monitoring: once slow pages,…
🔒4.4 Performing security Application updates
Applications are exposed to new threats every day, because attackers keep finding weaknesses in code, libraries and the platforms underneath them. A security application update is a controlled change that closes those weaknesses or strengthens the protection a…
🔒4.5 Perform routine system maintenance
Routine system maintenance is the planned, repeated care of servers, workstations, networks and the software running on them so that faults are prevented rather than repaired after they cause downtime. A technician who checks backups, clears full disks, review…
🔒4.6 Performing system updates
A system update is a planned change that brings an operating system, drivers, firmware or supporting software to a newer, corrected or improved version. Performing updates well keeps computers stable, compatible with new software and supported by their vendors…