Helpdesk: SLA by Priority, Ratings, Knowledge Base, WhatsApp & Assets

Settings → Support & Helpdesk → SLA by Priority (also reached from the SLA by priority button on Categories & SLA) is a grid of targets in minutes, first response and resolution, with a column for each priority — low, normal, high and urgent. The first row, Workspace default, applies to every ticket. Each category then has its own row, where a cell overrides the target for that category at that priority. Cells you leave empty fall through, and the greyed placeholder in a category’s cell shows the category’s own default from Categories & SLA.

A ticket takes each target in this order: its category’s cell for its priority, then its category’s own default, then the Workspace default for its priority. The ticket page shows which rule applied under SLA — for example “Urgent · Network category”, “Network category default” or “Urgent priority default”. Targets are applied when a ticket is created and again when its priority or category changes; saving the grid does not re-date tickets already open. The category still decides whether the clock runs on elapsed time or on working hours, and a ticket with no category runs on elapsed time. Changing the grid needs the permission to manage helpdesk settings.

In practice: a Nairobi internet provider sets Workspace default first response to 480 minutes for low, 240 for normal, 60 for high and 15 for urgent. Its Outages category gets an override of 10 minutes at urgent, and its Billing category keeps its own default of one working day for everything. An urgent outage ticket now takes 10 minutes; an urgent billing ticket takes the billing default; and a normal ticket in a new category nobody configured takes 240 minutes. When an agent raises a normal outage ticket to urgent, its deadlines are recalculated on the spot.

When a ticket is resolved, its requester is asked to rate it from 1 (Very poor) to 5 (Excellent) with an optional comment, and how they are asked depends on who they are. A requester with a login rates in the app, on the web or on mobile, and the status notification tells them so — no email is sent. A customer-portal contact rates from the portal’s Support tab, which lists their tickets. Anyone else with an email address — someone who used the public form, emailed the desk, or is an employee without a login — receives one email with a signed link for each score, so one click records the rating, and they can add a comment.

A rating can be changed for 30 days; the last answer wins, because a requester who clicked 2 in frustration and later calmed down is worth hearing twice. After 30 days the link no longer works. A reopened ticket cannot be rated until it is resolved again, and the next resolution asks again. Agents see the rating and comment on the ticket. Employees who use only the PIN-protected employee portal are asked by email when their record has an address; the portal itself has no rating screen.

The agent dashboard shows the overall CSAT average with the number of ratings, then the same broken down by channel — In the app, Mobile app, Email link and Customer portal. In practice: a Kampala property manager’s overall CSAT is 4.3, but the Email link row shows 3.1 across 40 ratings, all from residents’ public-form tickets. Reading the comments, most say nobody told them the fix was done. The team starts resolving those tickets with a public reply that states what was repaired, and the email-link average rises the following month.

Helpdesk → Knowledge Base holds the answers requesters see as they type a new ticket and agents link in replies. New article asks for a title, the article in Markdown (bold, italics, links, lists and headings; any HTML is removed), keywords, an optional category and who it is visible to: Requesters and public, or Agents only. An article is saved as a draft and goes live when published. The library lists each article’s status, visibility, category, views, helpful votes, deflections and when it was updated, filtered by status, visibility and category.

Write the title the way a requester would search for it — “How to reset your portal password”, not “Password policy”. Keywords carry almost as much weight as the title in suggestions, so put the other words people use there: login, locked out, forgot password, sign in. Readers can mark an article helpful or not, which with the view count tells you which articles earn their place. Reading the library and searching it needs the permission to see all tickets; writing, publishing and deleting articles needs the permission to manage the knowledge base.

In practice: a Dar es Salaam payroll bureau’s desk lead sorts last quarter’s tickets and finds that one in six asks where to download a P9. She writes a public article titled “Where to download your P9 tax certificate”, with keywords P9, tax certificate, annual tax form and P9A, in the Payroll category, and publishes it. She also writes an agents-only article on how to reissue a payslip, which agents can open from a ticket but never send to a requester.

As a requester types the subject on a new-ticket form — My Tickets in the app, the employee self-service portal, the public support form, or the new-ticket screen in the mobile app — the best published articles they may read appear under “These articles might already answer it”. The public form and other requesters see only public articles. Each suggestion has a This solved it button; clicking it records a deflection and tells the requester they do not need to raise a ticket. The customer portal has no new-ticket form, so there are no suggestions there. Published public articles also have their own public web pages that can be shared.

The agent dashboard’s Knowledge base deflection card counts tickets solved without a ticket in the last 30 days and all time, the number of published articles, and the articles that deflect most. On a ticket, the agent sidebar’s Knowledge base panel searches articles starting from the ticket’s subject; Insert link puts an article’s link into the reply box. Agents-only articles can be opened there but not linked, because the requester could not read them. Agents can also search the knowledge base and read articles in the mobile app.

In practice: a week after the payroll bureau publishes its P9 article, the deflection card shows 23 solved without a ticket, almost all from that article. An employee who still raises a ticket — his P9 shows the wrong employer PIN — gets a reply from an agent who uses the sidebar to insert the article’s link for the download steps and explains the PIN correction in the same reply.

WhatsApp intake uses Meta’s WhatsApp Cloud API through your own Meta app and number. Open Settings → Connectors → WhatsApp and connect the number — either sign in with Meta and pick it, or paste the Phone number ID and an access token from WhatsApp → API Setup in your Meta app (use a permanent System User token for production). Then, in the Helpdesk ticket intake card on the same page, copy the Callback URL and the Verify token into your Meta app under WhatsApp → Configuration → Webhook, subscribe the webhook to the messages field, and enter your Meta app secret so each incoming call’s signature can be checked.

Choose the Default category and Default priority that WhatsApp tickets start with — the category gives them their SLA and their assignment strategy — tick Enable ticket intake, and Save intake settings. From then on, a message to the number opens a ticket, and a follow-up from the same number within 7 days joins that sender’s open WhatsApp ticket instead of opening another. The sender is matched by phone number to a customer, employee or user where one exists, and images, PDFs and other documents they send are attached to the ticket. Seeing the page needs the permission to view the integration manager; changing it needs the permission to manage connectors.

Agents reply from the ticket as usual, and the reply goes back over WhatsApp — but WhatsApp allows free-form replies only within 24 hours of the customer’s last message. After that, the agent is warned before sending, and the reply is emailed if the customer has an email on file or stays in the app. Template messages are not sent. With intake switched off, replies on existing WhatsApp tickets still arrive but new numbers do not open tickets. In practice: a Mombasa courier puts its WhatsApp number on every waybill. A customer sends a photo of a damaged parcel at 18:00; the ticket opens in Claims at normal priority with the photo attached, and the agent’s reply the next morning at 09:00 goes back over WhatsApp because it is inside 24 hours.

A ticket about a laptop, a printer or a vehicle can be tied to that record in the asset register. On the ticket, the Linked assets card lists what is linked and has a Link an asset picker that searches by tag, name or serial number; a ticket can carry several assets, and each can be unlinked. Linking and unlinking needs the permission to manage tickets, and an asset’s tag opens its page for anyone allowed to see assets. In the mobile app an agent links an asset by scanning its label.

Employees can do it themselves when they raise a ticket: My Tickets → Raise a ticket asks “Which of your assets is it about?”, offering only the assets assigned to them. On the asset’s own page, a Support tickets card lists every ticket linked to it with its reference, subject, status, priority, the date it was opened and its rating — the asset’s repair and complaint history in one place, for anyone allowed to see tickets.

In practice: a Kigali bank’s IT desk links each printer fault to the printer’s asset record. After a quarter, the Support tickets card on one branch printer shows nine tickets, six of them about paper jams, most rated 2 or 3. The IT manager takes that list to the replacement budget meeting instead of a recollection, and the branch gets a new printer.