Prepare Your Business Information
Build a clear, approved source of business facts, call rules, and examples for your Voxen implementation.
The information you provide is the foundation for your agent setup. It should reflect what your team wants callers to hear today—not an old brochure, an unfinished policy, or the answer people remember from last year.
The goal is not to produce polished marketing copy. It is to create a dependable reference that the Voxen implementation team can use to understand your business, configure agreed behavior, and identify questions that still need a decision.
Create a business basics sheet
Start with facts that apply to many calls. Put them in one document so they are easy to review and update.
Include:
- the business name as it should be spoken;
- a short, plain-language description of what the business does;
- each location and the area it serves;
- opening hours, including any differences by location or day;
- planned holiday or temporary closures;
- approved phone numbers, email addresses, and website addresses;
- accessibility or arrival information callers commonly need; and
- the correct pronunciation of names, places, services, and specialist terms.
If different departments or locations follow different rules, label those differences directly. Avoid general statements such as “usually open late” when a caller needs a specific answer.
Use dates for temporary information. For example, write “Closed on 2 September 2026” rather than “Closed next Wednesday.” This prevents a short-lived note from becoming misleading later.
List common call reasons
Ask the people who currently answer the phone to list what callers actually request. Group similar reasons together, then describe the preferred outcome for each group.
A simple worksheet can use these columns:
| Call reason | Information needed from the caller | Approved next step | When a person is needed | | ------------------------ | ------------------------------------------------ | ------------------------------------- | ------------------------------------------------------ | | General service question | The service they are asking about | Give the approved explanation | The request is outside the documented information | | New enquiry | Name, contact details, and a brief description | Follow the agreed enquiry process | The caller needs advice or a decision | | Existing matter | Enough detail to identify the reason for contact | Route or arrange the agreed follow-up | The matter is urgent, sensitive, or disputed | | After-hours call | The reason for the call and a callback method | Follow the after-hours rule | The situation matches an approved escalation condition |
Replace these examples with your own call types. Include less common but important situations, not only the easy questions.
For each call reason, decide what must be collected and what is merely helpful. Asking for unnecessary detail makes the conversation harder and gives your team more information to manage.
Write clear, approved answers
Write answers as if you were explaining the business to a new employee. Use direct sentences, define unfamiliar terms, and make conditions explicit.
Instead of:
We can probably help with most nearby jobs.
Write:
Our team reviews requests in these named areas. For other locations, collect the caller’s location and arrange the approved next step without promising service.
For each answer:
- Confirm that it is factually current.
- Name any condition that changes the answer.
- State what should happen when the information does not cover the caller’s situation.
- Identify the person who approved it.
- Add a review date if the information changes often.
Include examples of the words callers use, especially abbreviations, alternate service names, local place names, and common mispronunciations. These examples help the implementation team understand the conversation without changing the approved meaning.
Define rules and boundaries
Facts explain the business; rules explain what should happen. Write down where the agent may continue and where a team member must take over.
Consider rules for:
- requests your business does and does not handle;
- information that must not be guessed or improvised;
- commitments that require staff approval;
- complaints, disputes, or sensitive conversations;
- urgent situations and their approved escalation path;
- calls received when the relevant person is unavailable;
- incomplete or unclear caller information; and
- requests that do not match a documented call reason.
Use an “if this, then that” format when possible:
If the caller asks for an exception to an approved policy, explain that a team member needs to review it and follow the agreed escalation or follow-up route.
Do not solve uncertainty by writing a vague rule such as “use best judgement.” Decide who owns that judgement and how the caller should be helped while waiting for them.
Only share information that is appropriate and necessary for the setup. If you are uncertain about the format, access, or account-specific details Voxen needs, ask the Voxen implementation team before sending materials.
Organize, review, and share
Combine the approved material into a small set of clearly named documents. Remove duplicates and label drafts so they cannot be mistaken for final instructions.
Before sharing, run this review:
- Accuracy: Are hours, contacts, locations, and policies current?
- Consistency: Do separate documents give the same answer?
- Ownership: Is there a named person who can approve corrections?
- Coverage: Are common, urgent, after-hours, and out-of-scope calls addressed?
- Clarity: Could someone unfamiliar with the business follow each rule?
- Maintenance: Is there a plan for reporting future changes?
Share unresolved questions alongside the documents rather than hiding them. The implementation team can then focus the next conversation on decisions that affect configuration.
Keep your own dated copy of the approved information. When something changes, describe both the old rule and the replacement, when the change takes effect, and whether any related call scenarios should be tested again.