AfterDesk
EN
Apply

The toolkit

Customer support and help desk

Front-line support is judgement under time pressure: sorting a queue by real impact, writing a first reply that tells the truth about what you know, and staying calm without giving away things the business never agreed to. This course takes you from a cold queue to a clean escalation, a published help article, and numbers about your own work that mean what they say.

9
lessons
~64
minutes
12
exam questions

Free · No paid tier · No certificate fee

After this course

Everything, and what is in it.

The front line, honestly

~7 min

What the job actually is

Front-line support means you are the first person a customer reaches when something is wrong, confusing, or slower than they expected. You are not there to be liked. You are there to give a correct answer, or an honest account of when a correct answer is coming. Most tickets are not dramatic. Someone forgot a password, an invoice has the wrong address, a file will not upload. A small number are serious: money lost, data missing, a business stopped. Good support is mostly the boring work done reliably, plus the judgement to recognise the small number that are not boring and treat them differently. That mix is the skill. Speed alone is not the skill, and neither is politeness alone.

You are the company's voice

To the person writing in, you are the company. They will not distinguish between you, the developer who shipped the bug, and the policy someone wrote three years ago. That is uncomfortable and it is also useful, because it means your reply can repair a bad experience by itself. It also means you carry a limit: you can only speak for what the business has actually decided. When you write we, you commit the whole business. Say we will refund that and somebody must refund it. This is why the strongest habit in support is separating what you know, what you can do, and what you are guessing. Those three things get different sentences, and the guesses never go out.

The queue is a signal

A support queue is the cheapest research the business will ever get. If eleven people this week asked where their invoice number lives, that is not eleven annoyances, it is one missing label in the interface or one missing help article. Keep a running note of repeated questions, a plain Google Sheets tab with the date, the topic and a link to the ticket. Once a month you can say, with numbers, that this one confusion cost roughly forty replies. That is the difference between someone who answers tickets and someone the business keeps. Nobody else in the company sees this pattern, because nobody else reads every message.

How AfterDesk differs

Support work on AfterDesk looks different from support work elsewhere, and you should know both. Elsewhere you may sit in a shared inbox and reply to customers directly under your own name. Here you never speak to a client and never speak to their customers. A support task usually means drafting replies from a ticket export, writing help articles, tagging and triaging a backlog, or building a macro library. You upload the drafts, the operator reviews them, and the client sends them. Everything in this course still applies, because the judgement is identical. The only change is that your reply passes a review step before it reaches a human, so anything uncertain goes in the note to the operator rather than into the reply.

Remember

  • You are the first person reached, and the whole company to them.
  • Separate what you know, what you can do, and what you are guessing.
  • Repeated questions are data. Log them and report them monthly.
  • On AfterDesk you draft replies; the operator reviews before anything is sent.

Triage and priority

~8 min

Read before you answer

The instinct at the start of a shift is to open the oldest ticket and begin typing. Do not. Spend the first five to ten minutes reading every subject line and the first two lines of every message, and sort them. You are looking for one thing: what breaks if this waits four hours. A queue of thirty tickets usually contains one or two that genuinely cannot wait, a handful that are quick, and a long middle that is fine until this afternoon. If you answer in arrival order you will spend your best hour on a font colour question while a payment failure sits unread. Reading first costs ten minutes and routinely saves two hours.

Impact times urgency

Priority is not how upset the sender is. It is impact multiplied by urgency. Impact means how many people are affected and how badly: everyone locked out is high, one person mildly inconvenienced is low. Urgency means what happens if it waits: a payroll run tonight is urgent, a report due next month is not. A calm message saying nobody on our team can log in outranks a furious message about a misspelled heading. This is the hardest habit to build, because loud feels urgent. Judge the described consequence, not the tone. If the message does not say what is at stake, that is your first question, and it is worth asking in the first reply.

Four buckets that work anywhere

Sort into four buckets and use the same names every day. Broken for everyone: the product or a core function is down or losing money right now. Broken for one: a single account is blocked and cannot work. Degraded: it works but wrongly or slowly, and a workaround exists. Question: nothing is broken, someone needs an answer or a how-to. Work them top down, but never let the bottom bucket rot. A question left for three days becomes a complaint, and a complaint costs four replies instead of one. Practical rule: clear the top two buckets, then spend a fixed block on the oldest questions before touching anything new.

Re-triage as the day moves

Priority is not set once. A degraded ticket becomes broken for everyone when three more people report the same thing within an hour. Two similar tickets are a coincidence, four are an incident. When you see a pattern forming, stop answering them one by one and say so upward immediately, before you write another reply. Also re-triage downward. A ticket marked urgent because the sender said urgent, which turns out to be a question about next quarter, should be moved down without ceremony and without a lecture. Nobody needs to be told they mislabelled their own problem. Handle it correctly and move on.

Remember

  • Read the whole queue before answering the first ticket.
  • Priority is impact times urgency, never how loudly it was written.
  • Four buckets: broken for everyone, broken for one, degraded, question.
  • Four similar reports in an hour is an incident. Say so immediately.

The first reply

~8 min

Four parts, in this order

Every good first reply does four things, in order. Acknowledge what happened in the sender's own terms. State what you know right now, including that you do not yet know the cause if that is true. State what happens next and who is doing it. Give a time. Three sentences can carry all four. Thanks for the screenshot, I can see the export is stopping at row 500. I have not found the cause yet, so I have passed the file to our engineer. I will write back by 14:00 your time today, even if the only news is that we are still looking. Nothing there is a promise the business cannot keep, and the customer now knows exactly what to expect.

State what you know, not what you hope

The most common failure in a first reply is filling the silence with optimism. This should be fixed shortly. It is probably a browser issue. Try clearing your cache. Those sentences buy you an hour and cost you the next three, because when the guess is wrong you have to walk it back, and you have taught the person not to trust you. If you do not know, write that you do not know and write what you are doing to find out. Customers forgive not knowing. They do not forgive being managed. The one thing you must never do is invent a cause, a cure, or a date that nobody has agreed to.

Give a time you can keep

Never write soon, shortly, as soon as possible, or we will get back to you. Those tell the reader nothing and they start a countdown you cannot see. Give a clock time or a date, and pick one you can beat. If you think you will know by noon, say by end of day, then reply at noon and be early. If the deadline arrives and you have nothing, still write. A message saying no news yet, still with the engineer, next update by 17:00, is a real update and it keeps the trust you built. Missed self-imposed deadlines destroy more support relationships than slow fixes do.

Answer the question they asked

Read the whole message before replying, including the part after the first question mark. People often bury the real problem in the last line: and also our invoice still shows the old company name. Answering only the first question guarantees a second ticket. If there are three questions, answer three, in the order they asked, and make it visually obvious that you did. If you can only answer two, say plainly that you are still working on the third and when you will have it. Never answer a question they did not ask in order to avoid one you cannot.

Close the loop before you close the ticket

A ticket is not resolved when you send the answer. It is resolved when the person confirms it worked, or when you have given them everything they need and told them how to reopen. Before closing, ask one specific question: can you confirm the export completes now. Vague closers like let me know if you need anything else invite silence. If they go quiet after a real fix, close with a short note saying what you did and that replying reopens the thread. Never close a ticket to make your numbers look better while the person is still stuck. That is the fastest way to lose the work you are trying to keep.

Remember

  • Acknowledge, state what you know, state what happens next, give a time.
  • Never invent a cause, a cure, or a date nobody agreed to.
  • Give a clock time you can beat, then beat it.
  • Answer every question asked, including the one buried at the end.
  • Close when it is confirmed fixed, not when it is off your screen.

Tone under fire

~7 min

The anger is about the problem

When someone writes in furious, almost none of it is about you. They are late, they look bad in front of their own boss, or they have explained this twice already. Reading their message as a personal attack makes you defensive, and defensive writing sounds like blame. Read it instead as information: this person is under pressure, and the pressure has a source you can probably name. Your first sentence should name it. You have reported this twice now and it is still happening, and I understand why that is frustrating. That sentence does more work than any apology, because it proves you read the history rather than starting fresh from their worst moment.

Apologise once, precisely

One apology, for something specific, then move to action. I am sorry this took three days to answer. Not I am so sorry for the inconvenience, repeated in every paragraph. Repeated apology reads as either insincere or panicked, and it pushes the whole reply toward you rather than their problem. Do not apologise for things that are not wrong, either. If policy is being applied correctly and the answer is no, saying sorry four times does not soften it, it just makes the no sound negotiable when it is not. Apologise for the delay, the error, the confusion you actually caused. Then spend the rest of the message on what happens now.

De-escalate without over-promising

The trap in a hot ticket is buying peace with a promise. I will make sure you get a full refund. I will have this fixed today. Said to calm someone down, those sentences hand the business a bill and hand you a problem, because if it does not happen you have turned a bad situation into a broken promise. Calm comes from certainty, not generosity. Specific facts, a named next step, a time, and one person owning it will settle almost anyone. Here is what I know, here is what I am doing, here is when you will hear from me, and I am staying on it until it is done. That is enough.

Words that inflame, words that settle

Some phrases reliably make things worse. As I already explained tells someone they are slow. Unfortunately our policy states hides behind paperwork. You should have makes it their fault. Actually corrects them for sport. Replace them with plain statements: here is the part I did not make clear, here is what I can do, here is what I cannot. Avoid the passive voice when something went wrong on your side. Your order was not shipped is a shrug. We did not ship your order is the truth and it lands better, because people can feel the difference between an account of events and a story with nobody in it.

When it stops being about work

Frustration is normal and part of the job. Insults, threats and abuse are not, and you do not have to absorb them to be professional. Answer the work content once, calmly, and state plainly that you will keep helping but will step away from the thread if the language continues. Then follow through, and tell your manager or the operator what happened, with the thread attached. Do not argue, do not match the tone, and do not delete the message. Keeping a record protects you. This is one of the few situations where handing a ticket to someone else is not a failure. Nothing in your job description includes being abused.

Remember

  • Their anger has a source. Name it in your first sentence.
  • Apologise once, for something specific, then move to action.
  • Calm comes from certainty, not from promises you cannot fund.
  • Write we did not ship your order, not your order was not shipped.
  • Abuse is not part of the job. State the limit and follow through.

Macros that still sound human

~6 min

Why macros are not cheating

If you answer the same question forty times a month, writing it fresh each time is not craftsmanship, it is a slow way to make more typos. A macro is a saved reply you paste and adapt. Done well it makes your answers more accurate, because the tested wording, the correct link and the exact steps stop being retyped from memory at eleven at night. The failure is not using macros. The failure is sending one unedited into a situation it does not fit, so the customer receives an answer to a question they did not ask, correctly formatted and completely useless.

Build the library free

You do not need paid software. Keep a Google Doc with one macro per heading, or a Google Sheets tab with three columns: trigger, macro text, last reviewed. Most help desks, including free tiers, have a saved-reply feature, so use it when the client has one. Your browser or operating system may also offer free text expansion. Name macros with the customer's words, not internal jargon: call it cannot log in after password reset, not auth flow 2. You will find it faster at speed. Start with the ten questions you answered most this month. Ten good macros cover most of a normal queue.

The two-line rule

Every macro goes out with a first line and a last line written by you, for this person. The first line names their specific situation: I can see your reset email went to the old address on the account. The last line names the specific next step: try it now and tell me if the code arrives, and if it does not I will reset it manually from my side. The middle can be the saved steps word for word. That is enough to make a pasted reply read as written. Also delete every part of the macro that does not apply. A leftover paragraph about mobile apps in a reply to a desktop user tells the reader you did not read their message.

Kill the tells

Certain phrases mark a message as machine-shaped: dear valued customer, we sincerely apologise for any inconvenience this may have caused, your satisfaction is our top priority, please do not hesitate to reach out. They are not offensive, they are just empty, and readers skip them looking for content. Write macros the way you would explain it to a colleague. Short sentences, second person, specific nouns. Also check the placeholders every single time before sending. A reply that opens Hi FIRSTNAME undoes everything else in the message, and it is the one mistake customers screenshot and post.

Review the library monthly

Macros rot. Prices change, buttons move, features get renamed, and a saved reply that was accurate in March will be quietly wrong by August. Put a monthly reminder in your calendar and walk the list: does this link still work, is this still the actual screen name, is this policy still current. Update the last reviewed column. If you cannot confirm something is still true, do not send it, ask. Sending a customer a step that no longer exists costs two more replies and looks worse than saying you will check. A stale macro is a promise made by a version of the business that no longer exists.

Remember

  • A macro is a starting point, never a finished reply.
  • First line and last line always written by you, for this person.
  • Delete every macro paragraph that does not apply to this ticket.
  • Check placeholders before sending. Hi FIRSTNAME undoes the whole message.
  • Review the library monthly. Stale macros are wrong answers delivered confidently.

Promises, refunds and limits

~8 min

Never invent a promise

This is the rule the whole course rests on. You may only state commitments the business has actually made: published policy, written terms, or something a manager or the operator confirmed in writing. You may not promise a refund, a discount, a delivery date, a feature, or an exception because it would end the conversation faster. An invented promise does not disappear when your shift ends. It becomes a screenshot, a chargeback, or a legal problem, and it lands on somebody who never agreed to it. If you feel the pull to promise something, that is the moment to write: I do not have the authority to approve that, here is what I can do, and here is who decides.

Know your decision box

On your first day with any client, ask for the box: what can I approve alone, what needs approval, what is never allowed. Write the answers down and keep them beside the queue. A typical box might be resend an invoice, extend a trial by a fixed number of days, replace a damaged item under a set value, apply a documented policy exception. Anything above the line goes to a named person. If nobody will define the box for you, write your best understanding and send it for confirmation, then work from the confirmed version. Ten minutes of that saves you from the worst mistake in support, which is discovering your limits by exceeding them.

Refunds and money questions

Refund requests are where invented promises do the most damage, so handle them mechanically. Find the written policy. Check the facts of this account against it. If it clearly qualifies and it is inside your box, do it and say so plainly. If it does not qualify, say so once, in plain words, without hiding behind the policy document, and offer what you can actually give. If it is borderline or sympathetic, do not decide alone: escalate with a short recommendation and tell the customer a decision is coming and when. Never speculate about tax, invoicing law, or what their bank will do. Point them to the official source or the finance contact and say plainly that it is outside what you can answer.

Saying no without hiding

A clean no has three parts: the answer, the reason in one sentence, and the best available alternative. We cannot refund this because the purchase is outside the return window written in the terms you agreed to. What I can do is extend your plan by one month at no charge, and I have asked my manager to review the case. Note the tone: nothing apologetic, nothing defensive, no policy fortress. Do not say I am afraid there is nothing I can do unless you have genuinely checked that there is nothing, including asking someone with more authority. Most of the time there is something, and finding it is the job.

Write down every exception

When an exception is approved, record it: the date, who approved it, what was granted, and why. One line in a shared sheet or a note on the ticket is enough. Two things then become possible. You can answer the next similar case consistently instead of guessing, and the business can see that it granted the same exception eleven times, which usually means the policy is wrong and should change. Undocumented exceptions are how a support team ends up with fourteen private versions of the rules, and how a customer discovers that the answer depends on who picked up their ticket.

Remember

  • State only commitments the business has actually made, in writing.
  • Ask on day one what you can approve, what needs approval, what never.
  • A clean no: the answer, one reason, the best real alternative.
  • Borderline and sympathetic cases get escalated with a recommendation, not decided alone.
  • Record every approved exception. Repeated exceptions mean the policy is wrong.

Escalating cleanly

~7 min

Escalate on triggers, not feelings

Agree the triggers in advance so escalation is a rule, not a mood. Common ones: you have spent your agreed maximum time and are not closer, the issue affects more than a set number of accounts, money or data has been lost, someone mentions legal action, press or a regulator, the request is outside your decision box, or the same problem has come back after being marked fixed. Write your triggers on the same page as your decision box. Escalating too early wastes a senior person's time, escalating too late costs the business a customer. Triggers remove the ego from the choice, and they let you escalate at minute twenty instead of hour three.

The handover packet

A good escalation can be picked up by someone who has never seen the ticket, without asking you anything. Include six things: a link to the ticket, one sentence on what the customer wants, the exact steps to reproduce or the facts of the case, what you already tried and what happened, the impact in plain numbers, and what you told the customer including any time you promised. Then ask one clear question. I need you to decide whether we refund outside the window, or I need engineering to confirm whether the export limit is intentional. Escalations that say please help with this are why senior people stop reading escalations.

You still own it

Escalating moves the work, not the responsibility. You remain the person the customer hears from. That means you keep the update schedule you promised, even when you have nothing new, and you chase the person you escalated to when the time passes. Set your own reminder. If your escalation has gone unanswered past its deadline, chase once, politely and specifically, then escalate the escalation. Handing a ticket over and going quiet is how a customer discovers three weeks later that nobody was ever working on it. The customer never has to know who inside the business is holding the ball. They only have to know that you are still holding the thread.

Escalate safely

Escalation is the most common place customer data leaks. Share the minimum needed and use approved channels only. Do not forward a customer's file to your personal email to work on later, do not paste their spreadsheet or their message into a free AI tool or an online converter to summarise it, and do not put account numbers into a group chat that half the company can read. Redact what the recipient does not need. On AfterDesk the rule is absolute: client data never leaves the task. No copies after delivery, no third-party uploads unless the brief says so, and no using the work as a portfolio sample. Treat every client you ever work for the same way.

Remember

  • Agree escalation triggers in advance so the choice is never emotional.
  • Handover packet: link, want, facts, what you tried, impact, promises, one question.
  • Escalation moves the work, never the responsibility. Keep updating the customer.
  • Never put customer data in personal email, group chats, or free AI tools.

From ticket to help article

~7 min

Write it while it is warm

The best moment to write a help article is the ten minutes after you solve something for the second time. You still have the exact error text, the working steps, and the wrong turn you took first. A week later you will remember the shape and lose the details, and the details are the article. Keep a running list of candidates: any question you have answered twice, any answer that took you more than fifteen minutes to work out, any step people get wrong in the same place. You are not writing documentation for its own sake. You are writing the reply you will paste next Tuesday.

Title it the way they ask it

People search with the words in their head, not the words in your product. Title the article the way the customer described the problem. Export stops at 500 rows, not Handling pagination limits in bulk data operations. If several people described it differently, put the alternatives in the first paragraph so search can find them. A good test: paste your title into the search box of the help centre and ask whether a stressed person typing at speed would land on it. If the title contains a word that only appears in your internal tools, it is the wrong title.

Symptom, cause, steps, failure

Use the same four-part shape every time. Symptom: what the person sees, in their words, including the exact error message. Cause: one or two sentences on why it happens, without an engineering lecture. Steps: numbered actions, one action per step, written so someone can follow them while tired. What if it still fails: the one or two other things it could be, and how to contact support with the right details. That last part is the one everybody skips and the one that saves the most tickets, because it stops the article from ending in dead silence for the third of readers it did not fix.

Take the customer out

The article ships to the public. The ticket does not. Remove every trace of the person who reported it: name, company, email, account number, order number, internal ticket references, and anything visible in a screenshot. Rebuild screenshots with a test account and dummy data rather than blurring real details, because blurring is often reversible and always looks careless. Never quote a customer's message, even flatteringly, without written permission. This is the same rule you follow when you deliver on AfterDesk and when you build a portfolio: the client's data is theirs, and their customers never agreed to appear in your work. Anonymous by default, always.

Prove it works

An article is finished when someone else can follow it. Test it yourself from a clean state, following only what you wrote and doing nothing you know from memory. You will find one missing step almost every time. Then use it: link it in your next reply on that topic, with one line of context rather than a bare address. If people still write in after reading it, the article is not clear, and that is information, not an insult. Track which articles you send most and revisit those first. Two well-tested articles that get sent daily beat forty that nobody ever finds.

Remember

  • Write the article the second time you solve it, while details are fresh.
  • Title it with the customer's words, not your product's vocabulary.
  • Symptom, cause, numbered steps, and what to do if it still fails.
  • Strip every identifier. Rebuild screenshots with dummy data, never blur real ones.
  • Test the article from a clean state before you publish it.

Measuring yourself honestly

~6 min

Three numbers, not fifteen

Track three things and you will know whether you are good. First response time: how long from the customer writing to a real human reply. Resolution time: from arrival to the moment they confirm it is done. Reopen rate: how often a ticket you closed comes back. Everything else is decoration at your level. If your workplace does not measure them, measure yourself in a Google Sheets tab: date, ticket, arrived, first reply, resolved, reopened yes or no. Twenty rows a week is enough to see your own pattern, and it is the only evidence you will have when you ask for more work or better pay.

First response, honestly counted

First response time only counts a reply that carries information. An automatic acknowledgement is not a first response, and neither is a message saying we have received your request and will look into it, because the customer knows nothing they did not know before. Count from when they wrote, not from when you opened it, and count in their working hours, not yours. Most support work across time zones is judged this way: a ticket that arrived at nine in the morning for them and was answered at nine the next morning for them was a one day response, no matter how convenient your night was.

Resolution and reopens

Resolution time flatters you if you close tickets early, which is why reopen rate sits beside it. A fast average with one in five coming back means you are closing tickets, not solving problems. Watch the pair together. Also separate the tickets you could solve alone from the ones that waited on someone else, because they measure different things: your work, and the business's bottlenecks. If your queue is slow because engineering takes eleven days, that number belongs in a report, not in your conscience. Bring it up with the dates, calmly, once you can show it happened more than twice.

The ways people cheat

Every metric can be gamed and every trick is visible. Sending a content-free holding reply to stop the response clock. Closing and reopening a ticket to reset resolution time. Splitting one problem into four tickets to raise your closed count. Marking a ticket solved on Friday knowing the customer will write back Monday. These work for one review cycle and then somebody reads the tickets. Worse, they cost you the one thing that makes you employable across every client you will ever have, which is that your numbers mean what they say. Report a bad week as a bad week, with the reason.

The weekly five minutes

Once a week, look at your own sheet and answer three questions. Which ticket took longest and why. Which answer did I have to send twice, and should it be an article or a macro. What did I promise and not deliver. Write one line for each. Over a quarter this becomes an honest account of your work that you can hand to anyone: here is my volume, here is my response time, here are the four articles I wrote that cut the password questions in half. On AfterDesk, that same habit shows up in the note you send the operator with each delivery.

Remember

  • Track first response, resolution and reopen rate. Ignore the rest for now.
  • A holding message with no information is not a first response.
  • Fast resolution with high reopens means closing tickets, not solving problems.
  • Report a bad week as a bad week, with the reason.
  • Five minutes weekly turns your queue into evidence of your work.

Sit the exam

The courses are free. The work is real.

Twelve scenario questions. Pass at ten. Three attempts a day. The bar is the point.

No paid tier. No certificate fee. No upsell. Not now, not later.

Create a free account

You can start the first course tonight.

The curriculum

Everything, and what is in it.