Write a restaurant AI phone agent decision record

Write the decision in one paragraph

State the restaurant scope, the call workflows and the chosen next step. A next step may be a limited pilot rather than a full rollout. Name the evidence that supports it and the conditions that must be met before expanding. Avoid a vague sentence such as “the demo was good.”

Example structure: “We will pilot the selected candidate for the specified call intents at the approved location. The witnessed test demonstrated the required destination records. Expansion depends on the written acceptance criteria and the open issues below.” Replace each general term with your actual decision. This is a template, not a claim that a pilot has happened.

Attach the evidence ledger

Include the frozen requirements, scorecard export, source documents and demo run log. For each important claim, record whether it is company-published, demonstrated or observed in your own pilot. Add the review date and configuration version so future reviewers understand what was tested.

Do not paste a metric into the record without its scope. If citing Loman's 99.6% order accuracy, identify the proprietary simulated 1,000-call benchmark. Loman reports 93% containment. Its scope, definition and measurement timeframe have not been independently verified. Keep these limits visible in your decision record.

List conditions, not hidden assumptions

Separate a failed requirement from an unknown requirement. A failed gate needs a correction and retest. An unknown gate needs evidence. Neither should disappear because a weighted score is high. Assign each open item an owner, a due date and the specific proof needed to close it.

Examples include confirming the installed POS version, verifying reservation changes, agreeing on after-call staff review and demonstrating a safe fallback. If the restaurant accepts a limitation, write down its operational consequence and the workaround staff will actually use.

Bring commercial scope into view

Confirm the exact plan, locations, included workflows, support arrangement and billing terms in the vendor's written offer. Do not assume a feature list on a general product page is the purchased scope. The current Loman plan page separates inquiry and transfer features from ordering, reservations, POS and payment functions.

Review service terms, data handling and cancellation provisions with the people responsible for those decisions. This worksheet is operational guidance, not legal advice. A public guide cannot establish your contractual rights or approve data-processing terms on your behalf.

Name the rollout and rollback owners

The purchasing owner, restaurant manager and phone-system administrator may be different people. Assign responsibility for the first live test, staff briefing, routing change and rollback. Preserve the previous phone configuration before any cutover. The person who can restore routing must be reachable during the pilot.

Finish with a review date and the decision that will be made then: continue, expand, correct or stop. Revisit the scorecard only after new evidence arrives. A recommendation is more useful when the restaurant can see what would change it.

Customer evidence for this evaluation

A decision packet someone else can audit

Use one short record: proposed scope; requirements tested; unresolved gates; evidence links; commercial questions; pilot owner; rollback owner; next review date. The next reviewer should be able to tell what would change the decision without reconstructing a sales call.

Attach the relevant Loman plan information and service terms as source records, while keeping the signed offer and your own approval process authoritative. This reference does not interpret or accept contractual terms for you.