The single most common support request we get during onboarding isn't a bug report. It's a business asking why AIVA gave a vague or partly-wrong answer, when the FAQ they uploaded "clearly" covers it. Nine times out of ten, the FAQ does cover it — for a human skimming a page. It doesn't hold up as something an agent has to commit to as a spoken or typed answer, on the spot, to one specific question. Those are different writing jobs.
The FAQ page mistake
Most business FAQ pages are marketing documents first and reference documents second. "We offer flexible scheduling to fit your busy life" reads fine on a website. It's useless as an answer to "can I book same-day?" because it doesn't actually say yes or no. A human reader fills in the gap from context, tone, and the rest of the page around it. An agent answering one question at a time doesn't have that surrounding context to lean on — it has the words you wrote, and it has to turn them into a direct answer.
One question, one answer
Write each FAQ entry as if it's the only sentence the agent gets to say back. "Do you accept walk-ins?" should have an answer that actually starts with yes or no, not three sentences of context before the actual answer shows up. This isn't a new idea — W3C's guidance on writing for accessibility makes the same case for people: lead with the direct answer, since a reader shouldn't have to hunt through surrounding context to find it, and neither should an agent. If the honest answer is "usually, but not on Saturdays," write that — the nuance is fine, the vagueness isn't.
A few before-and-after rewrites
Seeing the pattern side by side usually makes it click faster than a rule does. "We pride ourselves on quick turnaround" becomes "Same-day for bookings made before 2 PM, next-day after that." "Our pricing is competitive and transparent" becomes "Consultations are ₹500, follow-ups are ₹300." "We're closed on major holidays" becomes "Closed on Republic Day, Independence Day, Gandhi Jayanti, and Diwali (2 days) — open regular hours all other days, including other holidays." Every rewrite does the same thing: it replaces a claim about the business with a fact the agent can repeat exactly, to any customer, without guessing what you meant.
Numbers beat adjectives
"Quick turnaround" isn't an answer. "Same-day for bookings made before 2 PM" is. "Affordable" isn't an answer. A price is. Every adjective in a FAQ is a place where the agent either has to guess what you meant or hedge — and a hedged answer is exactly what makes a business owner say the AI "doesn't really know" their own policies. It knows what you wrote. Write the number.
A hedge in your FAQ becomes a hedge in every answer the agent gives back.
Organize by what customers actually ask, not by department
It's tempting to structure FAQs the way your business is organized internally — services, then billing, then policies, mirroring an org chart. Customers don't ask questions in that order. They ask about price, then availability, then what to bring, often in the same breath. A flatter structure grouped around real customer questions — booking, pricing, cancellations, what to expect — tends to hold up better than one that mirrors an internal department structure nobody outside the business thinks in.
Write the exceptions down, don't hope they don't come up
Every business has exceptions to its own rules — holiday hours, a service that needs 48 hours' notice instead of the usual same-day booking, a cancellation window that's shorter for weekend slots. These are exactly the questions customers ask most, because they're the ones a generic hours-and-pricing page never covers. Give each exception its own entry instead of burying it as a footnote on a different answer. If it's not written down as its own Q&A, the agent has nothing to draw on when a customer asks about it specifically.
How much is enough to start
There's no need to write fifty entries before launch. Fifteen to twenty-five sharp, specific answers covering your actual most-asked questions — hours, pricing, cancellation policy, what's included, how booking works, your two or three most common exceptions — will cover the bulk of routine conversations for most small businesses. It's a much better use of an hour to write twenty precise answers than sixty vague ones; you can always add entries once your analytics show you which questions are coming up that aren't covered yet.
Where contradictions quietly creep in
A subtler failure mode than vagueness is two FAQ entries that technically disagree — one says walk-ins are welcome, another (written months later, for a different purpose) says appointments are required. A person skimming both might reconcile them with common sense. An agent answering a single question might pull from either one, and which it picks can look inconsistent to a customer who happens to ask both questions in the same call. It's worth a periodic read-through of your full FAQ list specifically looking for this, not just checking each entry in isolation.
Keep it current
A stale FAQ doesn't produce a "no answer" — it produces a confidently wrong one, which is worse. If your hours change for a season or a price goes up, that's a five-minute edit, and it's the difference between an agent that's accurate and one that's accurately repeating last quarter's information. Your analytics dashboard will show you which questions are getting asked most and which ones are triggering escalation — a good signal for what needs a clearer answer written for it.
"I don't have time to write all this"
Most owners already have every one of these answers — they just live in their head, not on a page, because they've said them out loud a hundred times to customers on the phone. The actual writing task is usually faster than it sounds: sit for twenty minutes and write down the answers to the ten questions you get asked most, in the same plain words you'd say them out loud. That draft, refined against what customers actually ask once you're live, covers more ground than a much longer document written from scratch without real call data behind it.
Where this fits into setup
Writing FAQs isn't a separate project from the rest of onboarding — it's usually the fastest part of it. Connecting a calendar or a booking system takes longer than writing answers to your ten most common questions, so it's worth doing the FAQ pass first and testing it live before the booking side is even wired up. Our setup documentation walks through where FAQs live in the configuration and how to edit them once you're live, and it's worth starting free with a first draft rather than polishing it for a week before anyone's actually tested it against a real question.
The test before you publish
Read each answer on its own, with no other context, and ask: could a new employee on their first day answer a customer using only this line? If they'd need to guess, add a follow-up question, or check with someone else, the agent will hit the same wall. Rewrite it until the answer stands on its own. This is also worth doing right before you go live, as one of the last checks before real customers start asking real questions — and it's a habit worth carrying into your booking flow copy too, since the same "would a new employee understand this without more context" test applies there as well.