What Goes in an AI Receptionist's Brief Before It Answers?
The short answer
An AI receptionist is briefed, not trained: it answers from a written document that says who it is, how it speaks, what it does, what it collects, what it may say, what it must never do, and how a call ends. Durbacti's own brief, for 0483 982 033, is 10 paragraphs, and every answer traces to one of them.
This site describes the 24/7 AI phone receptionist with one promise, on its own page, on the IVR comparison and in three posts: it answers from your information and not from general knowledge, and a question it was not given goes to a person. None of them shows what "your information" looks like once it is written down.
A receptionist that answers from a document is only as good as the document. Here is the shape of Durbacti's own brief, the one behind 0483 982 033, paragraph by paragraph, then what a restaurant's would say and seven questions to answer before writing yours.
What is a brief, and what is it not?
An AI receptionist built by Durbacti is briefed, not trained. Durbacti does not feed your business into a model to learn from, and its privacy policy makes the same commitment about what callers and enquirers give it. Instead it follows a brief: a written document of plain sentences that the language model reads on every call. Change a sentence and the next call answers differently, so a wrong answer traces to a fact and is fixed by changing it, as When the AI receptionist gets it wrong sets out.
A brief is not everything the receptionist can say. Some facts change too often to live in a document: whether a slot is free at 10 tomorrow, whether a transfer can go through right now. Those come from tools the receptionist calls. The brief holds the facts that stay put and the rules; the tools hold the facts that move.
What do the 10 paragraphs in Durbacti's own brief do?
Durbacti's brief is 1,276 words in 10 paragraphs, nine of them labelled, read on 30 September 2026. Each paragraph does one job.
Who it is. The virtual receptionist for Durbacti, what the business builds, who the founder is, and that it answers the published number. The Sydney date and time are filled in on every call.
How to speak. Plain Australian English, short sentences, one question at a time. Never pretend to be a person; if asked, say it is an AI receptionist. Never say a person is picking up. No lists read aloud. Names, numbers and email addresses read back, numbers and emails one character or digit group at a time.
What to do, in what order. Find out what the caller wants; if they are a business interested in what Durbacti does, collect the enquiry details and offer a strategy call; if they need a person now and it is inside hours, offer a transfer; otherwise take a message; and before ending, say exactly what happens next and when.
The enquiry details. Which details to collect and how: naturally across the conversation, never as a form read aloud, never refusing to help because one is missing; the number they are calling from offered before one is asked for; an email only if the caller is happy to give one.
Booking. What a strategy call is, when one can be offered, that the availability tool is checked before any time is offered, and what to say when it returns nothing.
What it may say about the business. The stages of a Durbacti project, the three ways to work together, the service area, the email address, and what the receptionists Durbacti builds do.
What it must never do. No prices, no legal advice, no claims of clients or results, no telling callers what their business is losing, no answer about the business from general knowledge, no invented service or timeline, no calendar time the tool did not show. The handoff lines in this paragraph are the subject of Which calls should an AI receptionist hand to a person?, so they are not restated here.
Transcription. What happens when a caller declines it: stop, keep a name and a number for a callback, end politely.
Wrong numbers, sales calls and silence. Each closed kindly and briefly.
Ending. Summarise in a sentence or two, thank the caller, end the call. Never read the caller's details back as a roll call, never speak the contents of a tool call, never keep talking after goodbye.
Every answer the receptionist gives on 0483 982 033 traces to one of those 10 paragraphs; the greeting and the goodbye are two settings that sit beside them, and How do you test an AI receptionist before you pay for it? is nine calls for finding out whether that is true.
Which facts belong in the brief, and which in a tool?
The rule for where a fact lives is whether it moves. Hours, services, locations, policies, the answers to common questions, what to say about prices: these change rarely and belong in the brief, where a person can read them, with the greeting beside it as a setting. Free times, whether a transfer can go through right now, the record of what the caller said: these change every minute or every call and belong in a tool, so the brief never holds a stale copy.
That split decides who does the maintenance. A fact in the brief changes when someone edits the document, and which plan covers that edit is settled on the scope call, as How we work says. A fact in a tool changes when the tool does: update the calendar and the next call offers the new times.
What would a restaurant's brief say?
A restaurant's brief would be shorter than Durbacti's in most paragraphs and longer in one, the paragraph on what it may say about the business: the menu and how it is described, dietaries and what the kitchen can do about them, parking, hours by day, the cancellation policy, the largest group the floor seats without a function enquiry.
The order of operations would put the reservation first: date, time, party size, a name and a number, dietaries if offered, and a confirmation read back before it is written into the book. A function enquiry would be captured, not booked. Its never-do paragraph would carry the restaurant's own lines: never promise a table the booking tool did not show as free, never say the chef can do something the brief does not say, never handle a complaint about a meal on its own. And the greeting would say it is the restaurant's virtual receptionist, with no first name unless the owner wants one and knows what it costs.
How does a brief change, and how do you know it is wrong?
A brief changes in two ways: because a fact about the business changed, or because a call showed that a sentence was wrong. The second is found in the record every call leaves: a wrong answer there points at a paragraph.
Durbacti's own brief has been corrected from three calls, all on Sunday 13 September 2026. The first test call, that morning, changed three paragraphs: the availability tool returned no free times, which was the tool working, and the receptionist narrated it as a broken calendar, so the booking paragraph now says an empty list means nothing is open in that window; the enquiry paragraph gained the offer of the caller's own number before asking for one, and a keypad fallback after two failed read-backs; and the never-do paragraph gained its line on not telling callers what their business is losing, which the receptionist had said unprompted. A late-morning call ended with the receptionist reciting the caller's details after goodbye, and the ending paragraph gained its three never lines. An evening call had it saving what it had over and over; the enquiry and ending paragraphs gained a two-call limit and a stop. A fourth correction sits beside the brief rather than in it: the greeting in the platform's dashboard had drifted to a human first name and was put back to "you have reached our virtual receptionist" that morning. That is what a brief change looks like: a call, a paragraph, a reason and a date.
What we will not do
Put a fact in the brief that we cannot back. The brief forbids claims of clients, results and reviews, and says nothing about Durbacti that this site does not say.
Let the receptionist answer from general knowledge. A question it does not cover gets "I do not have that detail" and an offer to have a person answer. Inventing an answer is one of the two fails the testing post says to ask about first.
Give it a human name. The decision is on the record, and the greeting Durbacti proposes for a client carries no name either.
Pass off a client checklist as used. A list of what a client hands over before a build can be written from the brief above; it is not presented as something a client has been through until a client's build has produced it.
What is not yet proven about the brief
Two things. First, the document that holds the brief also holds settings whose names are marked to confirm: written from memory of the platform's API rather than read off its dashboard, and the workflow that would read the dashboard back had not run as of 30 September 2026. The brief's sentences in that document are exact, with one exception, the date expression in its first line, which carries the same marker. Whether the copy pasted into the dashboard still matches them is what that same workflow would show, and the greeting beside it has drifted from the document once already.
Second, a brief is only proven by calls, and the record of Durbacti's line held five on 29 September 2026, none using the transfer or the decline. The paragraphs those calls would exercise are written and enforced, not yet used by a caller.
Seven questions to answer before writing yours
Who is it, and for whom? One sentence a caller could hear and understand.
How does it speak, and does it have a name? Decide the name question on purpose, either way.
What does it do, in what order? Bookings first or questions first; when it offers a person; what it says happens next.
What does it collect, and how? The details a person needs to act, gathered in conversation, not as a form.
What may it say about the business? Written in sentences you can read back, and only what you can stand behind.
What must it never do? Prices, promises, complaints, and anything outside the brief.
How does a call end? A summary, a thank you, and nothing read back as a list.
Durbacti writes the first version with you on the proof of concept, before any money moves. The 24/7 AI phone receptionist page says what the finished receptionist does and refuses to do; the free strategy call is where the first paragraph gets written.
Common questions
Is an AI receptionist trained on my business, or briefed?
Briefed. A receptionist built by Durbacti is not trained on your data in the machine-learning sense, and Durbacti's privacy policy makes the same commitment about what callers and enquirers give it: Durbacti does not use it to train AI models. It follows a written brief: a document of plain sentences that says what it is, how it speaks, what it collects, what it may say about your business and what it must never do. Change a sentence and the next call answers differently; a wrong answer is fixed by changing the fact. Durbacti's own brief is 10 paragraphs.
How long is an AI receptionist's brief?
Durbacti's own brief, for the receptionist on 0483 982 033, is 10 paragraphs and 1,276 words, read on 30 September 2026: what it is, how it speaks, what it does in what order, the details it collects, booking, what it may say about Durbacti, what it must never do, and three more on a caller who declines transcription, wrong numbers and silence, and how a call ends. A brief for a business with one job would be shorter; one with many call types would be longer, and every extra paragraph is another thing to keep true.
Should an AI receptionist have a name?
Durbacti's own receptionist does not, and that is a decision on the record rather than an oversight. Its greeting says it is a virtual receptionist and gives no first name; when the greeting once drifted to a human name in the platform's dashboard, it was corrected on 13 September 2026 and the reason written down: a first name is a step toward the coyness about what is answering that Durbacti's own consent post warns against, and it would cost more than the warmth is worth. A client's greeting is theirs to approve, and the one Durbacti proposes carries no name.
Who writes an AI receptionist's brief?
Durbacti writes the brief with you, and the first version is written for the proof of concept, before any money moves: the calls you get, how you book, the questions your customers actually ask. You approve the greeting, and the brief is tested against the calls you actually get before go-live. On a Project the brief and the accounts are yours at handover, with documentation on how to change it; on the other plans, who keeps a fact current after your hours or menu change is settled on the scope call rather than assumed.