call nerd Let’s talk
← All field notes

Better answers

How do I write a good FAQ from real customer questions?

Turn support-call questions into clear answers, put them where customers need them, and check whether avoidable calls actually fall.

In this guide

THE SHORT ANSWER

Start with questions customers actually asked. Check whether each needs a clearer answer, an easier place to find it, or a change to the service itself. Publish a small set of useful answers, then compare the same call reasons across comparable periods. Fewer calls only count as progress if customers can still get help.

You have answered the same question six times this morning. It is tempting to put the answer on an FAQ page and consider the problem solved.

First, find out what those customers needed. “When do you deliver?” and “Why hasn't my delivery arrived?” sound similar, but one may need a clear policy while the other needs someone to investigate an order.

A good FAQ gives a customer enough information to take their next step. Its usefulness depends on the question, the answer and where the customer encounters it—not how many entries you publish.

Start with evidence you already have

Choose a manageable, complete period of customer calls and messages. Use notes or transcripts your business is authorised to review; you do not need to begin recording people to do this exercise. Remove unnecessary names, numbers and order details from your working examples.

Write down the question in the customer's words, what answer they received, and whether another action was needed. If you need a grouping method, use the customer-question ledger first. This guide picks up at the next decision: what should you publish or change?

Shopify's FAQ guidance recommends using support questions and feedback to choose topics, and writing questions in language customers use. Competitors can suggest things to investigate, but your own customers should decide what earns space on your page.

Count distinct calls containing a question, not every time someone repeats it. Note the coverage: questions from 20 reviewed calls are evidence about those calls, not automatically your whole customer base. A frequent question is a candidate for review; it is not proof that an FAQ can resolve it.

Decide whether the problem belongs in an FAQ

Use this audit before drafting. The examples are fictional.

On a phone, scroll the table sideways to see every column.

What callers ask What you discover Useful next change
“Can I change my delivery address?” The cut-off is missing from the website Publish the cut-off and the exact request route
“Do you deliver to my area?” The answer exists, buried in a policy page Put a short answer beside the delivery choice
“Where is the technician? They were due this morning.” The promised visit window has passed Investigate the booking and improve delay updates
“Can you check my refund?” The answer depends on that customer's case Explain how to request a status check and keep human help available

This is a practical interpretation of a broader service-design principle: support enquiries can reveal problems elsewhere in the service. The GOV.UK Service Manual recommends using support feedback to improve the service, rather than treating support as an isolated reaction to problems.

Do not write a more polished explanation of a promise the business cannot keep. If staff give different answers, settle the policy with the person responsible before publishing it.

Write the answer someone can act on

For each selected question, draft four parts:

  1. Direct answer: answer the actual question in the first sentence.
  2. Condition: state the limit, exception or deadline that changes the answer.
  3. Next action: say what the customer should do and link to the right place.
  4. Fallback: explain how to get help if their situation does not fit.

Here is an invented example for a shop whose confirmed policy permits address-change requests before dispatch. It is a writing example, not a suggested policy for every business.

Question: Can I change the delivery address after ordering?

Weak answer: We pride ourselves on flexible delivery. Contact our friendly team for assistance.

Useful answer: You can request an address change before your order is dispatched. Send your order number and the new address through our order-help form. We will confirm whether the change is possible; sending a request does not mean it has been accepted. If your dispatch email has already arrived, use the delivery-help link in that email to check the available options.

On a real page, link those phrases to working destinations. Check that the support team can follow the published process. A reassuring sentence that leaves the customer guessing can still generate a call.

Give each answer an internal owner and review it when the policy or process changes. If you serve customers in several languages, have someone competent review the meaning of each version, especially deadlines and exceptions.

Put the answer at the moment of doubt

Keep the FAQ as a useful reference, but also place short answers where the question arises. Delivery eligibility might belong beside the delivery options. Preparation instructions might belong in a booking confirmation. An address-change deadline might belong in the order confirmation.

Ask someone unfamiliar with the page to find an answer on their phone and explain what they would do next. Watch where they look. If they cannot find it, adding another answer to the bottom of the FAQ is unlikely to help.

Use descriptive links and short, specific headings. Avoid hiding the contact route: some questions need access to a particular order or a conversation with a person. The purpose is to make routine answers accessible while preserving a route for exceptions.

Check whether the change helped

Before publishing, record the call reason you want to reduce and a relevant denominator. For delivery questions, that might be orders dispatched in the period. For booking questions, it might be appointments booked. Keep the scope and counting rule consistent.

For example, suppose a fictional shop receives 20 delivery-policy calls for 200 dispatched orders, then 15 for 100 orders. Raw calls fell, but the rate rose from 10 to 15 calls per 100 orders. That would not support a claim that the FAQ reduced demand. These are illustrative calculations, not a measured result.

Compare similar complete periods and record other changes: seasonal demand, staffing, a delayed shipment, a promotion or a new contact channel. With very small counts, keep observing rather than declaring success.

Also check whether customers completed their task, whether the same questions moved to messages, and whether unresolved problems or complaints increased. Pageviews show that a page loaded; they do not show that its answer worked. Hiding the phone number can reduce recorded calls without improving the experience.

Start with a few answers you can maintain. Your first review should end with a decision: keep the answer, make it easier to find, rewrite it, or fix the underlying process.

Where Call Nerd fits

Call Nerd can help teams using approved Android phones turn usable customer-call recordings into transcripts and recurring questions. That gives the FAQ owner evidence to review. Capture quality still depends on the phone and conditions; the business must confirm that its setup produces usable recordings.

Call Nerd does not publish your FAQ or prove that an answer prevented a call. You still approve the wording, put it in the right place and measure what happens. If the immediate problem is simply too many calls to handle, start with the small-business call-overload plan.