A useful buying brief states the call tasks, coverage windows, connected systems and exception rules. For each requirement, name the evidence you will accept as proof that it works.
If language support is a requirement, use the documented scope to select realistic calls and verify the resulting operational record. Loman’s multilingual service documentation ↗
Check fees, usage limits, renewal and cancellation against the written proposal and Loman’s service terms. A plan label alone does not define the complete commitment.
List the locations, phone numbers, ordinary hours and peak periods in scope. Explain whether callers reach a local number or a shared number. Include the languages and accessibility needs you intend to evaluate, but do not assume a provider supports them until confirmed.
Describe call volume using a measured range and identify what data is missing. If you lack reliable records, start with an observation period. A quote based on guessed volume can be useful for early planning only when the uncertainty is visible.
Replace “takes reservations” with a statement such as “checks the approved reservation source, follows party-size limits and provides a confirmation only after a successful booking.” Replace “takes messages” with the fields, delivery destination and responsible owner.
For orders, specify the receiving system, item and modifier handling, correction flow and the behavior when a request is outside scope. For information calls, state which source controls hours, policies and availability. Separate mandatory launch requirements from later optional features.
Identify which matters must go to a person: disputed charges, uncertain allergy information, major complaints or nonstandard group requests. The exact list is your restaurant’s decision. Assign a destination and fallback for each category.
Document what the service must never promise. Examples include a refund before approval, a table without confirmation or a response time that your team cannot meet. Make these restrictions visible in training and test cases, not just in a contract appendix.
For each mandatory requirement, ask the provider to demonstrate it using your scenario and show the resulting record. Request details about fees, billing units, included volume, overages, setup, cancellation and support. Enter confirmed amounts in the worksheet and mark unknown items separately.
Finally, name who signs off before launch and who owns changes afterward. A requirement without an owner tends to drift. Use your pilot findings to update the brief before the service handles all live calls, and retain the accepted version as the reference for later reviews.
List locations, hours, call types, systems, languages to evaluate, completion evidence and staff-owned exceptions. Separate mandatory launch requirements from later options.
Describe the resulting record and the evidence you will inspect. For example, require a booking only after availability is checked and a confirmed reservation exists, rather than writing “takes reservations.”
Editorial operating guidance from Loman. The checklists are planning aids, not independent performance research or legal advice. Confirm your restaurant’s current policies and provider support.
Official Loman product information ↗Use the same call tasks and acceptance criteria when you evaluate Loman.
Learn more about Loman ↗Featured entity