"I can no longer work on the software." For an IT support technician, this sentence opens a very concrete investigation. Which software? Which task? Since when? Has a workstation stopped, is an access missing or has a function changed? Before proposing a solution, an imprecise report must be turned into a request that the team can understand and follow. This is a skill you can demonstrate right from your application, even without having managed an IT fleet on your own.
This guide from the Jawb editorial team is aimed at candidates for user support in Morocco. It offers an entirely fictional case in a small company in Rabat: an employee can no longer produce the document she needs for her work. We follow the request from the first exchange to the user's feedback. The goal is not to provide a universal repair procedure, but to prepare a credible explanation of your method, your questions and your relationship with users.
Read the missions behind the IT support job title
On-site support, remote assistance, helpdesk, application support: the job titles do not all describe the same day. Look at whether the advertisement concerns workstations, business software, access or the intake of requests. Also check the languages used, the working hours, travel and the level of autonomy. One role may involve qualifying and forwarding tickets; another also expects supervised technical interventions. Preparing a useful application starts with this difference.
PeopleCert presents the service desk in its ITIL framework as a point of contact between the service provider and users. This position explains the importance of clear communication. A person asking for help needs to know that their problem has been understood, who is following it and what information will be requested from them next.
To choose the skills to highlight, distinguish the knowledge you have practised from the knowledge you have only studied. An introduction to an operating system is not equivalent to administering all its components. However, an exercise in which you gathered a problem, identified what was missing and presented your reasoning can demonstrate a relevant ability for an entry-level position. Describe the training context and the supervision received, without attributing production experience to it.
Reread the advertisement with a simple question: what should the user be able to do after my intervention? For application support, the answer may be to complete a specific operation. For an equipment request, it may be to have a workstation that meets the intended need. This expected result helps to understand the mission. It does not remove the need to follow the company's technical procedures and authorisations, but it prevents reducing the role to a collection of technical actions.
Have the task clarified before looking for the fault
In our fictional scenario, the employee says her software no longer works. You ask her what she wanted to do and what she gets instead. She explains that she can open the application, but that the expected document does not appear after an operation. This information changes the scope: the application is not entirely inaccessible. You have a more precise symptom, without yet being able to deduce the cause from it.
Then ask short questions, in an order the person can follow. When did she last succeed at this task? Does the problem occur on all her documents or only on this one? Does a message appear? Has she already taken any action since the problem began? Each answer must serve a verification. A long series of questions without explanation gives the impression of an interrogation and risks losing important information.
Reformulate what you have understood. You can state that opening works, that the operation to produce the document remains blocked and that you are now checking whether the problem is limited to this example. This reformulation allows the user to correct a mistake immediately. It also avoids copying a general expression such as "software broken" into the ticket, which does not tell your colleague where to start.
The language of the exchange deserves the same attention as the technical information. Depending on the position in Morocco, you may be required to speak French, Arabic or another language requested in the advertisement. Simple vocabulary makes it possible to check understanding without assuming that the user knows your terms. Do not present it as a weakness when a person describes a screen in their own words. Your job is precisely to make the link between their activity and the elements the support team can use.
Write a ticket that genuinely helps the next person
The ticket must preserve the problem and the state of the work. For our case, a useful title indicates the application concerned and the operation that does not produce the expected result. The body describes the desired task, the observed behaviour, the time of the report and the available information. You can add what has already been checked, clearly separating a user's answer from an observation made by support. The document must make it possible to take up the case again without repeating the entire first interview.
Record the result of a check, not just its name. "Test carried out" does not explain what you learned. In the exercise, you can indicate that a comparable operation on a demonstration example produced a document, while the reported case remains blocked. This comparison does not automatically identify the cause. It narrows the question and makes the limit of your conclusion visible. The next person knows what still deserves investigation.
A screenshot can be useful if it shows a message or behaviour that is difficult to describe. Before attaching it, look at the other information it contains: open documents, client names, private exchanges or data unrelated to the problem. For your application file, recreate the example with fictional data. You can then explain why a screenshot helps, without disclosing a company's content or making it seem that the exercise represents a real intervention.
A ticket does not need to be long to be complete. Avoid copying an entire discussion history when a few organised facts are enough. Keep the details that change the understanding of the problem, then the actions and their results. If information is not available, say what remains to be asked. A field filled in with an assumption creates more work than a clearly identified gap, because it can send the team down the wrong track.
Assess the impact without promising an invented deadline
The person calling often wants an immediate answer. To understand the urgency, ask which activity is blocked and by when the result is needed. In our scenario, the employee must send her document to a colleague to continue a case. This dependency matters. It does not authorise you to announce that everything will be resolved in a few minutes. Priority must be determined according to the rules and commitments of the service concerned.
Also look for the extent of the problem. Is only one person experiencing it? Are other users still performing the same task? Is there a way to continue part of the work in the meantime, authorised by the company? These questions make it possible to explain the impact without confusing the worried tone of the call with an objective measure of the situation. A calmly expressed request may concern several teams; a very urgent request may remain limited to an individual need.
Present a concrete next step rather than a promise of resolution. You can explain that you are forwarding the elements to the relevant team and specify when you will give an update, if you are able to keep that commitment. If you do not yet know who will handle it, say that you are checking. Accurate information, even partial, allows the user to organise themselves. An improvised deadline mainly creates a new expectation that you will then have to correct.
To prepare for the interview, vary the scenario. Imagine that several people are now affected, or that the deadline changes, or that a temporary solution makes it possible to continue the work. Explain which piece of data would change your handling and whom you would ask to confirm the priority. This exercise shows your understanding of the service provided. It does not require inventing a universal grid of urgency levels valid for all companies.
Maintain a relationship of trust during assistance
An intervention may require observing the workstation or remote access provided for by the company. Explain what you want to see and use the authorised channel. The person must be able to understand why they are receiving a request for assistance and how to identify who they are speaking to. Holding a technical job title does not give a general right to consult their files. For a candidate, knowing how to set this limit is part of a serious presentation of their work.
Microsoft describes in its guide against technical support scams approaches in which a fake technician seeks to obtain credentials or access to the computer. This risk highlights the value of an identifiable support channel. In your exercise, use demonstration accounts and do not collect any password or login code in a ticket.
Keep the user informed of what you are doing. If a check risks interrupting their task, announce this consequence before starting and follow the applicable procedure. Avoid successive changes that no one keeps track of. Your note must make it possible to understand what was attempted and why. If you do not know the effect of an action, ask for the planned support rather than using the person's workstation as a testing ground.
A good relationship does not require resolving every situation alone. When the problem falls outside your scope, prepare a handover with the symptom, the impact, the checks carried out and the question that is still open. Do not promise that the colleague will necessarily fix the problem. You can, however, pass on clear, organised information and inform the user of this step. This continuity prevents a person from feeling that they are starting their story over with each new contact.
Verify that work has resumed, then prepare your application
After an intervention, a screen that opens is not always enough. Return to the initial task. In our fictional case, ask the user to verify that she can produce the expected document, with the appropriate example and within the planned framework. If she regains only part of the functions, keep this limitation in the follow-up. The verification must concern the need that prompted the request, not only an indicator that has become normal.
Closure and any follow-up rules depend on the organisation. Do not turn an absence of response into personal confirmation that everything works. Record the announced correction, the verification carried out and the feedback received, according to the service's procedures. If the same symptom reappears, the record must help to recognise the case and continue the analysis. A well-finished ticket provides useful information, rather than a simple administrative status.
For your application, prepare a short version of the scenario: first report, chosen questions, written ticket, possible handover and verified result. Add an explanation of what would make you change priority. You then have an example to comment on, even when your experience is mainly educational. The Jawb guide to writing a CV in Morocco helps you place this project in the right section, with your actual contribution.
In an interview, the recruiter may ask you why you asked one question rather than another. Answer by linking that question to a decision. Checking whether other people are affected helps to understand the extent; asking for the exact message helps to qualify the symptom; returning to the initial task helps to check the result. The interview preparation guide helps you organise these explanations without reciting a list of qualities.
Finally, ask the employer about the daily work: which users will you be supporting, which requests fall under the role, what supervision is available and how are tickets handed over between teams? These answers make it possible to compare the advertisement with your current level. To send a coherent application, the Jawb application guide complements this preparation. Above all, your example must show that you know how to listen to a need, produce a usable record and verify the service provided.
