4.1 Carrying out technical assistance

Technical assistance is the support an application technician gives to users so that they can install, configure, operate and recover their software with confidence. It covers answering questions, diagnosing faults, guiding users through tasks and recording what was done. The quality of this support depends as much on how the technician treats the customer as on technical skill, because a user who feels respected and informed will cooperate in solving the problem and will keep using the system.

4.1.1 Customer relation practices

Customer relation practices are the behaviours, communication habits and procedures a technician uses to build and keep the trust of the people who depend on an application. In technical support the customer may be an external client or a colleague in the same organisation. Example: a SACCO's loan officers report that the member-statement module closes unexpectedly. A technician who greets them politely, listens to the full description, explains what will be checked and gives a realistic time for feedback keeps the officers calm and productive, even before the fault is fixed.

Principles of good customer relations

• Courtesy and respect: Greet every customer politely, use their name and treat every question as valid, however basic it seems. Users who fear being judged stop reporting problems early.
• Active listening: Let the customer finish describing the problem without interrupting, then repeat it back in your own words to confirm understanding. This avoids solving the wrong problem.
• Clear, plain language: Explain causes and instructions without unnecessary jargon. Say "the program cannot reach the database on the server" rather than "the connection string is failing authentication".
• Empathy: Acknowledge the effect of the problem on the customer's work, for example a clinic receptionist who cannot register patients. Showing that you understand the urgency builds cooperation.
• Ownership and reliability: Take responsibility for the request until it is resolved or properly handed over. Do only what you promise and keep your promises on time.
• Honesty: Admit when you do not yet know the cause and give a realistic time to find out. Never promise a fix you cannot guarantee.
• Confidentiality: Treat customer data, passwords and business information seen during support as private. Do not discuss them with unauthorised people or leave screens open to onlookers.
• Professional appearance and conduct: Dress and behave appropriately for the customer's workplace and avoid personal phone use or casual comments during a support visit.

Communication skills in technical support

Good support communication is deliberate and structured. The skills below are used in face-to-face visits, telephone calls and written messages.

• Open and closed questions: Start with open questions such as "What were you doing when the error appeared?" and then use closed questions such as "Did the error message mention a file name?" to narrow the cause.
• Tone of voice and body language: Speak calmly and at a steady pace. When on site, face the customer, keep eye contact and sit beside them at the screen rather than taking over the keyboard.
• Written clarity: In emails and chat, use short sentences, numbered instructions and the exact wording of menu options. Attach screenshots where they help.
• Checking understanding: After explaining a step, ask the customer to try it and describe what they see. This confirms that the instruction was understood, not just heard.
• Language choice: Use English, Kiswahili or another language the customer is comfortable with, as long as technical terms are explained consistently.

Handling a customer request step by step

1. Greet and identify: Welcome the customer, state your name and role, and confirm the customer's name, department and contact details. Example: at a county revenue office, the technician records which office, which terminal and which user is affected.
2. Listen and record: Let the customer describe the problem fully and note the key facts: what they were doing, the exact error message, when it began and how many users are affected.
3. Clarify and reproduce: Ask follow-up questions and, where possible, ask the customer to repeat the action while you watch. A problem that can be reproduced can be diagnosed much faster.
4. Diagnose and explain: Check the likely causes from simplest to most complex, such as user input, network connection, settings and recent changes. Tell the customer what you are checking and why, so that the waiting time does not feel like inactivity.
5. Resolve or escalate: Apply the fix and test it with the customer. If it is beyond your authority or skill, pass it on through the agreed escalation route and tell the customer who now has the matter and when to expect feedback.
6. Confirm satisfaction: Ask the customer to perform their normal task and confirm that it now works. Do not close the request until the customer agrees that it is solved.
7. Educate the user: Briefly show how to avoid the problem in future, for example saving work before closing the application or using the correct date format.
8. Record and follow up: Write down the cause, the action taken and the time spent, then contact the customer after an agreed period to check that the problem has not returned.

Handling difficult customers

Frustrated customers are common when an application stops working at a critical moment, and how a technician responds often decides whether the relationship survives.

• Stay calm: Do not respond to anger with anger. Lower your voice, slow your speech and focus on the problem rather than the tone.
• Let the customer vent: Allow a short time to express frustration without interruption, then acknowledge it with a statement such as "I understand that this is delaying your work."
• Apologise for the inconvenience: A sincere apology for the disruption does not admit fault for the cause, but shows that you take the effect seriously.
• Offer options: Give the customer a workable choice, for example a temporary manual procedure at a hotel front desk while the booking system is repaired. Having a choice restores a sense of control.
• Set clear limits politely: If a customer is abusive or demands something outside policy, explain what you can do and involve your supervisor when necessary.
• Follow through: Do exactly what you said, in the time you said. Missed promises turn a difficult customer into a lost one.

Service commitments and professional boundaries

Many support arrangements are written down as a service level agreement that states response and resolution times. Example: a private school pays Ksh 15,000 per month for support and the agreement requires a first response within 4 working hours. The technician must know such commitments, communicate them to the customer and plan work so they are met.

Boundaries protect both parties. A technician should not accept gifts that influence service, should not install unlicensed software at a customer's request, should not access data unrelated to the fault and should refer requests outside the agreement to the supervisor.

Support channels and their use

Customers reach a technician through different channels, and each suits some problems better than others. Choosing the right channel saves time and keeps the customer informed. Example: a pharmacy chain whose point-of-sale application shows an error may first use the telephone for a quick fix, then switch to remote access if the call cannot solve it.

When using remote access, always ask permission before connecting, explain what you will do and disconnect when finished.

Documenting and escalating support requests

Every support request should leave a written trail. Documentation shows what was done, helps colleagues who handle a repeat problem and gives evidence of whether service commitments were met.

A complete support record contains:

• Ticket number and date: A unique reference lets the customer and technician refer to the same case.
• Customer details: Name, department, location and contact number.
• Problem description: The symptoms in the customer's words, including any exact error message.
• Priority: A level such as low, medium or high based on how many users are affected and how critical the function is.
• Actions taken: Each step attempted and its result, in order.
• Resolution and closing details: The final cause, the fix, the time closed and the customer's confirmation.

Escalation means passing a request to a more experienced person or a higher support level when it cannot be solved within the agreed time or the technician's authority. Typically, first-line support handles common user problems, second-line support handles configuration and technical faults, and the developer or vendor handles defects in the application itself. When escalating, pass on the full record so the customer is not asked to repeat the story, and tell the customer who now owns the case.

Measuring customer satisfaction

Customer relations improve only when they are measured. Simple measures show whether users are getting timely, effective help and where the service needs attention.

• Feedback forms: A short form after each visit or ticket asks the customer to rate courtesy, clarity and result, with space for comments.
• Response time: The time between the customer reporting a problem and the first reply from support, compared with the service agreement.
• Resolution time: The time from the report to confirmed solution, which shows how efficiently problems are closed.
• First-contact resolution rate: The share of requests solved without needing a second contact or escalation.
• Repeat complaints: Cases where the same problem returns suggest that the root cause was not fixed or the user was not properly taught.

First-contact resolution rate = (requests resolved at first contact ÷ total requests) × 100

Example: a hospital's records office logged 60 requests in a month, and 45 were solved at the first contact.

Rate = (45 ÷ 60) × 100

Rate = 0.75 × 100

Rate = 75%

Review these measures regularly with the support team and act on recurring complaints, for example by writing a short user guide for a task that generates many calls.