1. Home
  2. Guides
  3. Set up a helpdesk

How to set up a B2B helpdesk

A shared inbox works until the first customer gets the same answer twice, or none at all. This guide walks through every choice you make before you switch on a helpdesk: channels, statuses, priorities, an SLA, macros, staffing and the numbers you track afterwards.

Helpdesk ticket list with status, priority and owner

Why B2B support works differently

In B2C a question comes from one person and the job is mostly speed at volume. In B2B every question belongs to an account with a contract, an account manager and often ten or twenty users. A ticket from a user at your largest customer carries different weight than a question from a trial account. And the person asking is rarely the person who signs the renewal.

So a B2B helpdesk does not start with the tool. It starts with three questions. Who may ask us for help, and through which channel? What do we promise, and to whom? And who needs to know what when a customer is upset or a deal is in progress?

Many teams start with support@ as a shared mailbox. That is fine with two people. After that, things go wrong that you only notice when a customer complains. Two colleagues answer the same email. A question sits untouched because everyone assumes someone else has it. And nobody knows how long a customer waits on average. A helpdesk does not fix that by itself. It does make it visible, and that is where it starts.

A second difference: in B2B, sales wants to know what is going on with an account. When the helpdesk lives in a separate system, an account manager calls about a renewal while three tickets are open. So put tickets on the same organization as your deals, whatever system you use. Then everyone sees the same picture, and you can later measure customer success on real signals.

The numbers in this guide are examples that show the math. They are not benchmarks. A good response time depends on your product, your contracts and what your customers expect.

Set up a helpdesk in eight steps

Follow this order. Each step builds on the one before.

  1. Pick your channels and say no to the rest

    Start with email and possibly a portal or chat. Every channel you open must be staffed within your SLA. A chat nobody answers after 4 pm is worse than no chat. Decide what happens to questions that arrive elsewhere, such as an email to a personal address. The person who receives it turns it into a ticket.

  2. Define your statuses with a meaning

    A status answers one question: whose move is it? New means nobody has looked yet. Open means we are up. Pending means the customer is up. On hold means we wait for a third party, such as a supplier or a developer. Solved means we think it is done. Closed means the case is finished. Write this down, or everyone will use the statuses differently.

  3. Define priorities in plain words

    Agree when something is urgent without letting the customer’s tone decide. Urgent: the system is down for the whole organization. High: a core process fails and there is no workaround. Normal: something is wrong but a workaround exists. Low: a question, a request or a small bug. Whoever sets priority looks at impact, not exclamation marks.

  4. Keep a short list of categories or tags

    Ten to fifteen at most, such as login, billing, integration, error message and feature request. With more tags nobody picks them consistently. You use them later to see where questions come from and which articles your knowledge base lacks.

  5. Decide who picks up what

    Choose between agents picking from a shared queue and automatic distribution. Picking works with two or three people. Beyond that, the easy tickets disappear fast and the hard ones stay. Distributing over available agents prevents that. Also agree who watches the queue when someone is out sick.

  6. Write your first macros

    Look at the last fifty questions and find the five that keep coming back. Write a standard reply for each with room for one personal sentence. Three templates follow below.

  7. Prepare a knowledge base and a portal

    Start with ten articles on the most common questions. A portal where customers see their own tickets and get article suggestions when they open a new one saves you the “any news?” email.

  8. Ask for satisfaction after every solved ticket

    A CSAT question after solving gives you a signal per ticket. Keep it short: one question, a scale and an open field. Read the low scores every week. That is where the work is.

An SLA table you can copy

An SLA (service level agreement) states what you promise: how fast you respond and how fast you resolve, per priority. Below is an example table. The values are made-up examples. Pick your own using the method that follows.

Example SLA table

  • Urgent. Definition: the system is down for the whole organization. First response: within 1 business hour. Resolution: within 4 business hours. Business hours: Monday to Friday, 8 am to 6 pm.
  • High. Definition: a core process fails, no workaround. First response: within 2 business hours. Resolution: within 1 business day. Business hours: Monday to Friday, 8 am to 6 pm.
  • Normal. Definition: something is wrong, a workaround exists. First response: within 4 business hours. Resolution: within 3 business days. Business hours: Monday to Friday, 9 am to 5 pm.
  • Low. Definition: question, request or small bug. First response: within 1 business day. Resolution: within 10 business days or moved to the backlog. Business hours: Monday to Friday, 9 am to 5 pm.

How to choose the values

Do not start with what sounds good. Start with what you achieve today. Take the last three months of tickets and look, per priority, at the response time you met for eight out of ten tickets. Set your first target just below that. An SLA you miss in the first month is one nobody takes seriously, your own team included.

Then check your contracts. If an agreement states a response time, that is your floor for that customer. Put those customers in their own group so you can track them in a separate view.

Finally, agree what stops the clock. Most teams pause resolution time while a ticket is Pending, because the customer has the next move. On hold is harder. If you are waiting for your own developer, that is your time. Write it down before someone uses a status to stop the clock.

Worked example: an SLA with business hours

An example to show how business hours add up. A customer emails on Friday at 4:30 pm about a High priority issue. Business hours are Monday to Friday, 8 am to 6 pm, and the first response is due within 2 business hours.

On Friday one and a half business hours remain, from 4:30 to 6 pm. The weekend does not count. The last half hour runs on Monday from 8 to 8:30 am. So the first response deadline is Monday 8:30 am, not Friday 6:30 pm.

Now take a resolution target of 1 business day, which is 10 business hours. You reply on Monday at 8:15 am and ask for a screenshot. The ticket is Pending from 8:15 to 11:15 am. If the clock pauses, those three hours do not count. Friday from 4:30 to 6 pm used 1.5 hours. Monday from 8 to 8:15 am used another 0.25 hours. That leaves 8.25 hours from 11:15 am, which puts the resolution deadline at Tuesday 9:30 am.

If a public holiday falls in between, such as Easter Monday, everything moves by a business day. So add your holidays to the helpdesk before go-live, or it will look as if you missed a pile of SLAs after every holiday.

Three macro templates

A macro is a standard reply you insert in one action, often together with a status change. Keep them short and always leave room for one sentence of your own. In many teams these three cover a large share of first replies.

Received, we are on it. “Hi {first name}, thanks for your message. I have picked up your question about {topic}. I will let you know what I found by {time}. Best, {agent name}.” Status stays Open.

We need more information. “Hi {first name}, to look into this properly I need two things: a screenshot of the message and the time it happened. As soon as I have those, I will continue.” Status moves to Pending.

Solved, can you confirm? “Hi {first name}, the integration works again. The cause was {cause}. I am marking the ticket as solved. If it still does not work for you, reply to this email and I will look again.” Status moves to Solved.

Check every month which macros nobody uses and which questions still have no macro. A macro that agents edit by hand every time usually means the text is wrong.

How many agents do you need? A worked example

You work out staffing with three numbers: ticket volume, time per ticket and the hours someone really spends on tickets. Here is an example with made-up numbers.

Say you receive 300 tickets a week. A ticket takes 15 minutes on average, including reading, investigating, replying and a follow-up reply. That is 300 times 15 minutes, or 4,500 minutes, or 75 hours of work a week.

An agent works 40 hours but does not spend all of them on tickets. Meetings, updating the knowledge base and breaks take time. Use 70 percent, for example, and you have 28 hours per person. 75 divided by 28 is about 2.7, so you plan for 3 people.

That is the average. Tickets do not arrive evenly. If Monday morning is twice as busy as the rest of the week, that is where your SLA slips first. So look per part of the day and staff to the peaks, not the weekly average. And account for holidays: with three people, one person on leave is a third of your capacity.

If you want fewer tickets per person, you have two levers. Lower the time per ticket with macros and better context on the ticket, or lower the number of tickets with a knowledge base that answers questions before they are asked.

The helpdesk KPIs to track

Six numbers, each with a formula. For every number, write down which period and which tickets count.

First response time

Time between a ticket arriving and the first public reply from an agent, in business hours. An automatic acknowledgement does not count. Look at the median and at the share of tickets within SLA.

Resolution time

Time from arrival to Solved, in business hours, minus time spent Pending if that is what you agreed. Split it by priority and by category.

Backlog

Number of tickets open at a given moment: New plus Open plus On hold. Watch the trend and the number of tickets older than a week.

Reopen rate

Tickets reopened after Solved, divided by all solved tickets. Example: 12 out of 240 is 5 percent. A rise often means tickets are being marked solved too early.

CSAT

Satisfied responses divided by all responses to the satisfaction question. Example: 81 out of 90 is 90 percent. Also watch the response rate. With few answers the score says little.

Deflection through articles

An approximation: the number of times someone read a suggested article and did not open a ticket, divided by the number of times an article was suggested. It is hard to measure exactly, so use it as a direction, not a hard number.

Common helpdesk setup mistakes

Too many statuses. Every extra status is a question with a different answer for each person. Start with the six from step 2 and only add one when you have a question they cannot answer.

Stopping the clock as a trick. Whoever sets a ticket to Pending to save the SLA keeps the numbers and loses the customer. Also report on total elapsed time including waiting, and it shows.

Priority by tone. An angry customer then always goes first and a polite one waits. Priority is about impact. An angry customer with a small question gets a fast, friendly reply, not an urgent priority.

No rules for internal notes. An internal note is for colleagues. Never write anything there you would not want the customer to see if it went public by mistake, and check the field before you send.

Writing the knowledge base before go-live and never again. Articles go stale with every product change. Agree that whoever solves a ticket where an article was wrong updates that article or flags it.

Leaving sales out. An account manager who does not see three open tickets at the account calls at the wrong moment. Make sure tickets sit on the same organization as the deals.

Helpdesk go-live checklist

  • Channels are chosen and each one is staffed during business hours
  • Every status has a written meaning
  • Priorities are defined by impact, with examples
  • The SLA per priority is set, including what stops the clock
  • Business hours and public holidays are in the helpdesk
  • There are fifteen categories or tags at most
  • Assignment is agreed, including sickness and holidays
  • The five most common questions have a macro
  • The knowledge base has at least ten articles
  • Every solved ticket triggers a satisfaction question

A helpdesk in the same system as your customers

In Lumo the helpdesk sits next to deals and contacts, so tickets belong to the same organization. Tickets use the statuses New, Open, Pending, On hold, Solved and Closed. They come in from a mailbox, the customer portal, an escalated chat, or you create them by hand. Agents reply publicly or with an internal note, use macros with Cmd or Ctrl and /, and work with tags, saved views and rules. Assignment can also be distributed over available agents.

You set the SLA per priority for first response and resolution, with business hours and holidays, and a warning at 75 percent of the time. After solving, a satisfaction survey goes out through a signed link. Read more about the helpdesk, the customer portal, live chat and the page for service teams.

  • Six statuses, four channels
  • SLA per priority with business hours, holidays and a warning at 75 percent
  • Macros, tags, saved views and rules
  • Portal with sign-in through a link in the email
Ticket list with status, priority, SLA and owner per ticket

Knowledge base and portal for customers

The customer portal works without a password. A customer signs in with a link in an email, sees their own tickets, opens a new ticket with article suggestions, replies and marks a ticket solved. Internal notes are never shown there.

The knowledge base holds Markdown articles with categories and version history, in Dutch and English. You write the translation yourself, there is no machine translation. You see what gets read and searched, and readers leave feedback per article. If you are moving from a separate helpdesk, also read switching from a service tool.

  • Sign in through a link in the email, no password
  • Article suggestions when opening a ticket
  • Insight into what gets read and searched
Knowledge base with categories and articles

What you should know

Live chat in Lumo is not an AI chatbot. The bots are chat channels with fixed texts, and your team answers the conversations. WhatsApp, a social inbox and a phone channel are not included. Questions that come in by phone you log as a ticket by hand in Lumo, so they fall into the same queue and SLA.In the demo we show what that looks like for your mailbox.

Helpdesk setup FAQ

What is the difference between a shared inbox and a helpdesk?

A shared inbox is a mailbox several people read. A helpdesk gives every question a status, an owner, a priority and an SLA. So you see what is waiting, with whom, and for how long.

Which ticket statuses do you need?

Usually six: new, open, pending on the customer, on hold for a third party, solved and closed. Each status answers the question of whose move it is.

How do you write an SLA?

Look per priority at what you achieved for eight out of ten tickets over the last three months and set your target just below that. Define what stops the clock and add business hours and holidays.

What is a good first response time in B2B?

There is no fixed benchmark. It depends on your product, your contracts and what customers expect. Start from what you achieve now and check what your contracts promise.

Does the clock keep running while a ticket waits on the customer?

Most teams pause resolution time while a ticket is pending. Agree on it upfront and also report on total elapsed time.

How many support agents do you need?

Multiply weekly tickets by time per ticket and divide by the hours an agent really spends on tickets. Then staff to the busiest parts of the day, not the average.

How many articles should a knowledge base have at launch?

Ten good articles on the most common questions is a fine start. Expand based on what people search for and which tickets keep coming back.

How do you measure customer satisfaction in a helpdesk?

With a short CSAT question after every solved ticket. Divide satisfied responses by all responses and read the low scores every week.

Should sales see a customer’s tickets?

In B2B, yes. An account manager who knows about open tickets picks a better moment for a renewal or upsell. Put tickets on the same organization as the deals.

See the helpdesk on your own questions

In the demo we set up an SLA with business hours, show macros and the portal, and look at tickets next to your deals.

Account manager on a call with a customer