How do you build an event customer support knowledge base?

Your support team has answered the parking question again. Someone else has sent the old refund reply. Meanwhile, the person working the door has a different version of the arrival instructions. Everyone thinks they're helping, but your attendees are getting different answers depending on who they ask.

An event customer support knowledge base gives your team a reliable place to find answers they've checked. Start with the questions attendees actually ask, confirm the underlying rules, and separate information you can publish from instructions only staff should see. Each answer needs someone responsible for keeping it accurate, especially when the event changes.

You don't need a large help centre to do this. A small collection of useful pages and a private staff guide can be enough. What matters is whether a buyer can finish their task and whether your colleague can handle the same question tomorrow without inventing a new policy.

This guide explains how to build that collection, with reusable answer formats and a worked example for a paid event. It also covers the awkward part: keeping replies, event pages and attendee messages consistent once tickets are already sold.

Start with the questions your team is already answering

The first thing you want to do is read the actual conversations. Check your booking inbox, contact form, social messages and notes from the previous event's support desk. Ask the people who handled those conversations which questions needed repeated explanation and which answers they couldn't find.

Keep the attendee's wording while you work out the problem. "My friend bought my ticket" might mean they can't find it, want to change the name, need a separate arrival arrangement or don't know whether they can enter without the buyer. Those are different tasks. A category called "third-party transactions" will hide the distinction from the people looking for help.

The UK Government Digital Service recommends learning about user needs through evidence such as search logs, support data and conversations with users and the people who assist them. Treat your support history the same way. It shows where people struggled, although it won't explain every person who gave up without contacting you.

Record the task, the event edition, the channel and what happened next. Did the person find the answer, need an order check or wait for a decision? Keep individual case information in your restricted support records. Your general question list can say "buyer could not locate group tickets" without reproducing their name, email address and entire message.

Don't count the same conversation as several independent problems just because it arrived through different channels. A buyer who emails, sends a direct message and visits the desk may have one unresolved issue. You can record the extra work those contacts created while keeping the underlying case together.

Also ask what the question tells you about the offer. If people keep asking whether a workshop ticket includes materials, you may need to fix the ticket description. Writing an answer in a separate help page leaves the original uncertainty in front of every new buyer.

Our event FAQ template helps you decide what the public needs answered before buying and attending. The knowledge base goes further by recording how the team verifies those answers, applies them to individual cases and changes them when necessary.

Choose what to fix before writing a large library

You will probably find more questions than you can write up immediately. Start with those that affect buying, admission, access, money or time-sensitive arrangements. A small number of clear answers is more useful than a full help centre containing details nobody has confirmed.

Frequency helps, but it shouldn't make the decision alone. A question about the cloakroom may arrive often because the answer is missing. A single report that the published step-free route is unavailable needs immediate investigation even if nobody else has asked. The consequences of a wrong answer matter as much as the number of messages.

For each recurring question, decide whether the next action is to explain something, correct something or make a decision. You can explain a confirmed doors time. You need to correct an outdated map. You cannot write a reliable answer about refunds for a changed session until the responsible person has agreed the options under your terms and applicable obligations.

Here's an illustrative way to compare ordinary support work. Suppose your team handles thirty similar questions, each taking six minutes to investigate and answer. That's three hours of handling work. If preparing and checking a reusable answer takes two hours, it might repay that effort over repeated use, but it won't automatically remove those thirty contacts.

Some people will still need personal help. The page needs maintenance too. All those figures are invented planning inputs, not a benchmark or a forecast of savings. Use them to ask whether an answer is worth preparing, then check what actually happens at your events.

Avoid turning every unusual request into another public article. If a question depends on a particular booking or individual arrangement, the useful reusable material may be a staff instruction explaining what to check and who can decide. Publishing the individual outcome as a universal policy creates more trouble than it saves.

Choose a manageable first batch. Confirm who can approve each answer and when you can test it. You can expand after the team has used the first answers and shown you what is still missing.

Separate public answers from private staff instructions

Your attendee and your support colleague need different information. The attendee wants to know whether they can do something and what to do next. The colleague may need to check the booking, confirm eligibility, record a change and contact an authorised decision-maker.

A public answer about a missing ticket might explain where the confirmation was sent, how to request help and which limited details to provide privately. The staff instruction can describe the approved booking lookup, the checks required before disclosing information and what happens if there is no matching order. It shouldn't expose those checks in a public article.

In the staff guide, link each instruction to the corresponding public answer so your colleague can see both. Keep the private instructions behind staff access controls, and test what somebody without a staff account can open. A heading marked "internal" won't protect a page that anyone can read.

There is also information that belongs in neither general collection. A particular attendee's complaint, an access arrangement and a decision about their order belong in the appropriate restricted case record. The reusable staff guide can explain the process without collecting those personal details itself.

For example, the public page can say that someone with a booking problem should contact the event team privately. The staff guide names the ticketing lead and backup. The case record says what happened to this person's booking. You can update the general process without exposing or rewriting the individual case.

Be particularly careful with discretionary decisions. If a manager approves an exception for one order, record why and which booking it covers. Don't add it to the standard reply until the policy owner confirms that it should apply more widely. Otherwise, the next support colleague may promise an exception you never intended to offer generally.

Confirm the answer before you improve the wording

An old support reply is evidence of what someone said. It isn't proof that the answer remains correct. Check it against the current event offer, ticket terms, venue arrangements and the actual process your team can carry out.

Some answers need more than one person's confirmation. A late arrival rule may involve the programme lead, venue and access team. A permitted ticket change needs an agreed policy and a working way to make that change. A sentence saying "we'll sort it out at the door" doesn't settle either question.

Assign one person to coordinate the answer, even when several people confirm parts of it. They should be able to explain where the rule came from and which event it covers. That prevents a copywriter from making an operating decision simply because the page needs to be finished.

Use a short private record for each answer:

• The question and event edition it applies to.

• The public answer and any related staff instruction.

• The confirmed policy, booking process or venue information supporting it.

• The person who approved the facts and the person who maintains the wording.

• When it was checked and what should trigger another check.

• Where the answer is published or reused, including saved replies and scheduled messages.

The UK Department for Education's content strategy guidance includes agreeing factual responsibility, approval and maintenance, alongside testing and feedback. You can use that principle without creating a publishing department. For a small event, one person may maintain the answers, provided the right people still confirm the facts.

Check which event the answer covers. An answer approved for a seated Friday performance may be wrong for Saturday's standing show in the same building. Record the date, ticket type or session where those distinctions affect the response. A general answer should direct people to their own booking when the arrangement varies.

If the decision is pending, say so internally and assign the next action. Publish an honest holding answer when people need one, with a realistic update time and contact route. Don't fill the gap with a confident sentence that the operating team will later have to reverse.

What a completed answer record looks like

For the fictional Workshop Exchange event used below, the private record for arrival information could read like this:

• Question: "Which entrance should I use?"

• Applies to: Workshop Exchange at River Rooms, Saturday 22 May 2027.

• Confirmed arrangement: Mill Lane entrance for attendees, including the agreed step-free arrival route.

• Fact approval: venue lead, with the access lead confirming the route on 7 May.

• Copy owner: attendee support lead; duty backup covers their absence.

• Reused in: event page, arrival guide, saved entrance reply, queued arrival email and door briefing.

• Recheck when: the venue reports works, the entrance arrangement changes or a new event edition is prepared.

These are invented arrangements, but the record shows what your team needs to find. The approval date says when somebody checked the facts. It doesn't guarantee the route will remain available. A report from the venue should trigger another check even if the scheduled review is still weeks away.

Keep unanswered questions visible until somebody decides

Not every question will be ready for the knowledge base. You may still be negotiating an arrangement with the venue or checking how a ticket change works. Keep those questions in a separate work list so an unfinished draft cannot be mistaken for an approved instruction.

For each one, name the person investigating, the decision needed and the next update time. Record which existing answer may be affected. If the question came from an attendee, their support case still needs an owner and a response. Moving the question into your writing work doesn't finish their enquiry.

Suppose a buyer asks whether they can move from the morning workshop to the afternoon session. The team hasn't approved a general exchange process. The useful next action is for the ticketing and programme leads to check the request, availability and permitted arrangements. A writer cannot settle it by borrowing a generous-sounding policy from another event.

You can still acknowledge the person promptly. Explain that you're checking the session change and when you will update them. Promise the update your team can deliver, rather than a successful exchange. If the planned answer time becomes unrealistic, contact them before it passes and explain the next step.

When the decision arrives, ask whether it applies only to that booking or establishes a general process. Record an individual outcome in the case. Add a reusable answer only after the responsible person confirms its scope. This prevents your knowledge base from gradually turning a collection of one-off favours into promises made to every buyer.

Write the answer in the order an attendee needs it

Start with the answer to the question. Then explain the conditions, the next step and how to get help if the ordinary answer doesn't resolve it. That order works better than opening with your administrative process and hoping the reader finds the result at the end.

Take "Can I arrive after the first session starts?" The reader needs the confirmed admission arrangement before the history of your room booking. If admission depends on the activity, name that condition. A workshop with a required briefing may need a different answer from a performance where late arrivals can enter at a suitable break.

Use words people recognise in their own booking. If the ticket says "Saturday workshop", don't call it a "single-session entitlement" in support. Someone should be able to compare the answer with their ticket without translating your internal language.

The W3C's writing guidance for web accessibility recommends descriptive titles and headings, meaningful link text and clear instructions. For event support, that means a heading such as "I can't find my ticket" and a link labelled "Contact ticket support", rather than "Other queries" and "More".

Give a reason when it helps someone understand the rule. "Entry pauses during the opening demonstration because the instructor cannot repeat the safety briefing while supervising the activity" explains the restriction. A long paragraph about operational efficiency will sound defensive and won't help the person decide when to arrive.

Keep instructions specific to the system your buyers use. Don't copy troubleshooting steps from another platform and present them as your own process. Test the ticket email, support route and booking changes using your actual setup. If a browser instruction is necessary, make sure it addresses the reported problem rather than sending every buyer through the same exhausting checklist.

You can be warm without being vague. "Send us the order reference privately and we'll check the booking" tells someone what to do. "Our friendly team is always here for you" leaves the method, hours and next action unanswered. State the service you can actually provide.

Use a reusable format without making every answer sound identical

A format helps your team remember the information an answer needs. It shouldn't force a simple question into a long article. A confirmed finish time might need a few sentences. A booking change may need several steps and a clear route for exceptions.

For a public answer, use the question as the heading. Follow it with the direct answer, any important limit and the action the reader can take. Add the relevant event date when the page could otherwise be mistaken for guidance about another edition. Keep private approval notes out of the published copy.

Here's the public wording for the same fictional Workshop Exchange event. Its daytime programme, location and arrangements are invented to demonstrate the writing. Replace them with your confirmed details before using either example below.

Public answer: can I arrive separately from the person who booked?

"Yes. Each guest needs their own valid ticket for Workshop Exchange on 22 May. Ask the person who made the booking to share the ticket intended for you before you travel. Showing the same ticket twice won't provide entry for two people.

"If you can't get your ticket, contact ticket support through the event page. Tell us somebody else booked for you, and share the order reference privately if you have it. We'll check the booking and explain what to do next. We may need to hear from the person who bought it. Don't put your ticket image or booking details in a public comment.

"Ticket support is monitored from 9 am to 5 pm on weekdays before the event, in the venue's local time. On event day, visit the staffed support point beside the Mill Lane entrance, open from 8:30 am. Doors open at 9 am and the first session starts at 10 am."

That answer has a practical limit. It doesn't promise that a screenshot transfers ownership or that anyone who knows an order reference can receive somebody else's tickets. Your own version needs to match the ticket format, permitted sharing and verification arrangements you've actually confirmed.

Private instruction for the same question

"Confirm which event and date the person means. Use the approved private booking lookup and identity checks before sharing order information. An order reference alone is not permission to disclose the whole booking. Ask the buyer to use the approved contact route where their involvement is required.

"Check whether the issue is locating the existing ticket, a permitted ticket change or a disputed claim to the booking. Follow the current procedure for that task. Don't issue an extra usable ticket just to bypass an unresolved check.

"The ticketing lead decides cases outside the approved process. Use the duty backup if that person is unavailable. Record the decision in the restricted case record and tell the attendee the next step."

Notice how much of that instruction would be unhelpful in the public answer. Attendees need a usable route to assistance. Staff need a safe way to provide it, with someone available to make the decisions they cannot make themselves.

Work through a question that changes with the event

Now take another question from the same fictional event: "Which entrance should I use?" It's an ordinary public answer, but it depends on current venue information. That makes it a useful test of whether your knowledge base can handle a change.

Suppose the confirmed arrangement is the Mill Lane entrance for all attendees, with the agreed step-free route starting there too. The public answer names that entrance, explains how to identify it and gives the support point location. The private record notes who confirmed the route and where you've repeated the instruction.

You then learn that work outside the building may affect the route. At that point, staff should flag the answer for review and contact the venue lead. They shouldn't tell attendees to use another door because it looks closer on a map. The alternative may affect access, ticket checks or routes the venue needs to keep clear.

Once the venue and relevant event leads confirm a replacement arrangement, record the approved instruction and its effective time. Update the public answer, the event page, the support reply and any arrival message still waiting to send. Tell the door team what attendees have already been told.

The interesting part is what happens to people who already received the old directions. Updating your help page doesn't contact them. Decide which buyers need a direct correction, and explain the changed detail clearly enough that they can recognise the earlier instruction is out of date.

With Loopyah's attendee email tools, you can send event updates to ticket holders and test the message before sending it. Your team still confirms the arrangement, checks the intended audience and writes the instruction. That connects the maintained answer to the people who need the correction.

Keep the correction focused on the event they booked. If you're also preparing a sales campaign, manage that separately through the appropriate promotional audience. A necessary arrival update shouldn't become an excuse to add unrelated offers to the message.

If the replacement route isn't confirmed, publish what you know and give the next update time your team can meet. Keep a working contact route for people whose travel or access arrangements depend on the answer. The knowledge base should make that uncertainty visible instead of hiding it behind last week's confident directions.

Make answers easy to find where the question arises

A good answer won't help somebody who doesn't know it exists. Put the most important information beside the relevant decision, then use the knowledge base for the explanation and support route. Ticket restrictions belong near the ticket offer. Arrival details belong in the practical information people receive before travelling.

For the public collection, group answers around what attendees are trying to do. Buying tickets, finding an order, preparing to attend and getting help are understandable starting points. Your internal departments are less useful as navigation. A buyer shouldn't need to know whether their question belongs to operations, customer experience or finance.

Keep the main help page short enough to scan on a phone. Use headings and clear links to the actual answers. If your collection is small, a well-organised page may be more useful than adding search. A search box creates another thing to test and won't rescue confusing article titles.

Where search is available, try the phrases people use in messages. "Lost ticket", "email never arrived" and "friend booked" may lead to related answers without meaning exactly the same thing. Use those phrases naturally in the relevant pages or search settings. Don't create several competing articles just to cover different wording.

For staff, make the current answer reachable during a conversation. They should be able to open the public wording, check the private instruction and identify the right decision-maker. A file buried in last month's crew chat is unlikely to stay reliable during a busy arrival period.

Test access as well as navigation. A buyer shouldn't need a staff login to read basic arrival information. A temporary worker should be able to open the instructions their role requires. Private permissions should protect the information without preventing the assigned person from doing their job.

Our event-day help desk guide covers the people, authority and handovers needed at the venue. Use the knowledge base to support that work, and keep a staffed route for anyone who cannot use the page or needs help with an individual booking.

Turn approved answers into useful saved replies

Saved replies can make routine messages easier to handle, but they need the same care as the public page. Link each reply to its approved answer and record where the copy is stored. Otherwise, you may correct the website while colleagues continue pasting an old policy from their inbox.

Write the reply so a person can adapt it to the question. If someone asks where to arrive, answer that before linking to the full guide. "Use the Mill Lane entrance. The arrival guide includes the support point and access information" is more helpful than "Please consult our knowledge base."

Don't send a standard answer when the message describes a case it doesn't cover. A buyer saying their ticket email is missing may have a routine delivery problem. A buyer saying they paid for the wrong event date needs a booking review. Sending the same troubleshooting reply to both people can delay the decision that matters.

Mark anything the sender must check before using a reply. That might be the event edition, ticket type or current support hours. Keep those notes visibly separate from the customer-facing wording, and test that the sender won't accidentally paste the internal instruction into the message.

Avoid a reply that promises an action before anybody has carried it out. "We've refunded your order" belongs after the authorised process confirms that result. Before then, say what is actually happening and who owns the next step. Reusable wording should make accuracy easier, not let your team skip verification.

The same applies if you use software to suggest or draft replies. Restrict it to approved material appropriate for the question, check how it handles an answer it cannot find and keep a human route for individual decisions. A fluent response can still cite an expired policy. Test the system with changed and missing information before relying on it.

Treat a policy change as more than a copy edit

Changing a refund answer is different from correcting a spelling mistake. It can affect money, expectations and people who bought under earlier terms. The person editing the knowledge base should not decide that a new sentence automatically applies to every existing order.

Start by confirming what changed, when it takes effect and which bookings it applies to. Check the actual terms and applicable consumer requirements with the responsible person. Our event refund policy guide explains the policy decisions behind the wording. Keep that decision separate from the task of making support copy readable.

For a changed answer, compare the old and new instructions privately. Identify the practical difference for the attendee. "Updated policy" tells your team very little. "The approved transfer process now requires the request before Friday noon for this edition" names the condition they need to check, if that is the valid arrangement you've agreed.

Record which earlier bookings need separate treatment. Staff should be able to find the terms relevant to a disputed purchase without leaving obsolete public advice presented as the current rule. Preserve necessary records privately under your retention arrangements, with access for the people authorised to investigate.

Then work through the places using the answer. Correct live pages, replace saved replies, review scheduled communications and brief the team. If attendees need a direct notice or an individual remedy, assign that action explicitly. A note saying "website updated" doesn't establish that either happened.

Keep a short change history for staff. State the old instruction, the replacement, the affected event or bookings and who approved it. You don't need to show every internal revision publicly, but people already relying on an earlier instruction need a clear correction when it affects their plans.

After the change, sample real replies and check the live pages. Ask a colleague who missed the briefing to find the current answer. That is a better test of the system than asking the person who made the edit whether they remember doing it.

Keep private case details out of reusable examples

A support conversation may contain contact details, ticket images, payment information, access requests and complaints. Copying it into a general staff article can expose far more than someone needs to understand the process. Use an anonymised summary or a clearly invented example wherever possible.

Remove identifying details as well as the obvious name. A specific job title, unusual request and quoted conversation can identify someone in a small audience. Ask whether the example still teaches the procedure after you remove those details. Usually, the useful part is the decision and next action.

The UK's Information Commissioner's Office explains data minimisation as keeping personal information adequate, relevant and limited to what the purpose needs. Where UK GDPR applies, this is a legal principle. The ICO notes that this guidance is under review following legislative changes, so check the current guidance and requirements for your operation.

Keep the detail needed to resolve an individual case in the approved restricted system, with an appropriate retention arrangement. The reusable knowledge base can describe the checks without retaining another copy of the evidence. Don't ask customers to post ticket codes, identity documents or card details in public comments to help your team locate a problem.

For access enquiries, explain the private route and the information the team actually needs to arrange assistance. Don't make a public answer demand a full medical history. Have the responsible person confirm the collection and handling arrangements before you add a form or a standard request for sensitive information.

Also review staff access when the event ends or somebody leaves the team. A temporary support role shouldn't quietly become permanent access to old booking cases. Separate the general learning your future team can use from the personal records only authorised people need.

Give urgent concerns a different route

Some messages need immediate attention rather than a help article. A medical problem, safeguarding concern or report of danger shouldn't wait while somebody searches a knowledge base or completes an ordinary booking form. Your public contact information and staff instructions need to make the relevant route clear.

Great Britain's Health and Safety Executive calls for planned emergency procedures and clear responsibilities. Your knowledge base can help staff locate the arrangements agreed for the event. It cannot replace the emergency plan, competent people or the communication methods they need to use.

Keep the public wording consistent with your actual venue and event procedures. Staff instructions should identify how to raise the alarm, reach the responsible team and provide the location. Have the appropriate lead approve that material. Don't let an ordinary customer service template invent emergency instructions.

For non-emergency questions, be equally honest about availability. If email stops being monitored while the team runs the event, publish the working onsite help route and update the automated acknowledgement. A knowledge base that advertises immediate support through an unattended inbox creates another avoidable problem.

Where the team cannot answer immediately, explain who owns the next action and how the attendee will hear back. Repeatedly sending the same article to someone whose case needs investigation is a refusal to help in practice, even if the wording sounds polite.

Test the collection with real tasks before relying on it

Ask somebody unfamiliar with the event to use the public information. Give them a realistic task, such as finding their ticket after a friend booked or working out where to arrive. Watch where they look and what they understand. Don't explain the page while they're trying to use it.

Then test the private instructions with the support team. Give them an ordinary case, a case outside their authority and a question whose answer recently changed. Can they find the right event edition, check the current instruction and name the person who can decide? If they disagree, resolve the disagreement before they answer attendees.

Include a phone and the devices people will actually use at the venue. Check that links open, text is readable and private material remains private. If your team uses an approved offline copy, label its event, version and preparation time. Decide how they will learn about a later change when connectivity returns or through the agreed event communication route.

Don't judge success solely by whether someone found the page. Ask them to explain what they would do next. An article can be easy to locate and still leave the reader uncertain about whether their ticket is valid, whether help is available or whether they need the buyer's involvement.

Keep a short record of what failed and assign the fix. Sometimes the answer needs clearer wording. Sometimes the link is wrong, the instruction contradicts the ticket or the support process doesn't work. Editing the article won't solve every failure, so send operational problems to the person responsible.

Review usefulness alongside the cost of maintaining answers

After the event, look at the questions that still reached your team. Which answers did people find? Which led to another contact? Which were wrong or couldn't be followed? Ask the support team where they had to depart from the guide and why.

Compare similar event periods where possible. More messages during a larger on-sale don't necessarily mean the knowledge base failed. Fewer messages after a smaller event don't prove it worked. Look at the number and type of contacts alongside orders, attendance, changes to the event and the support channels available.

You can track repeat questions per order, time spent handling recurring issues and cases reopened because the first answer didn't resolve them. Define those measures before comparing editions. A reply sent is different from a booking problem resolved, and closing a conversation isn't proof that the attendee received what they needed.

Include the work needed to maintain the collection. Checking a venue answer, updating replies and testing links all take time. If an article gets little use and changes every week, a shorter event-specific answer or direct support may be a better choice. More documentation is not automatically better service.

Before reusing the collection for another edition, confirm every answer that depends on the venue, programme, ticket offer or support schedule. Reuse the useful question and structure freely. Recheck the answer. Keep old editions clearly labelled where they still need to remain available, and direct new visitors to the event they're actually attending.

Start your next review with one question your team keeps answering. Confirm the rule, write the public explanation and the staff instruction it needs, then test the whole task. Once that works, use the same process for the next question. Build the collection at a pace your team can keep accurate.