Start with the manager’s exact question, not the largest guest export the AI vendor can accept. If the question asks how many guests returned, a count or an anonymous customer group may be enough. If the task is to contact a particular guest, the workflow may need an identity and a contact route—but only for the people and action in scope.
For each request, write down the fields the assistant needs, where they come from, and the decision its answer will support. Then ask the vendor to demonstrate that unrelated fields stay out. Staff report permissions are a separate question: a manager’s ability to open a report does not by itself explain what data an outside AI provider receives or keeps.
Map the manager’s question to the data
Use one narrow question for the first evaluation: “Of guests who ordered in April, how many ordered again in May?” The desired answer is a count and a percentage. The source would be order records for those two months, matched by a customer identifier before the information is sent to the assistant.
The match needs a consistent identifier in the system doing the counting. The AI itself does not necessarily need that identifier. It could receive the April guest count and the number who also ordered in May. It does not need guest names, phone numbers, email addresses, delivery addresses, or notes about dietary requests to calculate the percentage.
Agree on definitions before asking for the answer. Does “guest” mean a customer account, a phone number, or another identifier? Are canceled orders excluded? Are all order channels included? An assistant can calculate a neat percentage from inconsistent inputs and still give the manager a misleading answer.
For the hypothetical example below, assume the restaurant can match orders to a consistent customer identifier, includes completed orders from all chosen channels, and excludes canceled orders. Assume April has 120 distinct guests and 30 of them also placed a completed order in May. These figures are invented for the exercise, not observations from a restaurant or a Fleksa system.
The worksheet separates the question, the input sent to AI, and what each choice permits. It also shows where a larger data transfer would need a different business purpose.
| Manager’s task | Input sent to AI | Useful answer | Decision or limit |
|---|---|---|---|
| Count April guests who returned in May | 120 April guests; 30 returned | 30 of 120, or 25% | Summary counts answer the question; no guest identities needed. |
| Compare return rates by first-order channel | Guest and return counts for each agreed channel | A return rate for each group | Use group counts if the source can produce them reliably. |
| Prepare a follow-up for named guests | Only the selected records and contact fields needed for an approved workflow | A draft or a selected recipient list | Identity may be necessary; confirm permissions and contact rules before use. |
Check the source system’s definitions with whoever maintains the order data. A restaurant POS system may be one source to examine, but ask how the relevant customer and order records are matched across your actual channels. Do not assume that a sales total alone can identify returning guests.
Compare the answer from counts with identifiable records
For the first task, summary counts give the same calculation the manager needs: 30 divided by 120 equals a 25% return rate. Sending 120 named records would add exposure without improving that answer. If the vendor says it needs every guest record, ask which part of the calculation cannot be done before the transfer.
Now consider a different possible outcome. The manager sees the 25% rate and wants to compare first-order channels. Assume, separately within the same fictional cohort, that 60 guests first ordered through each of two channels. If 21 guests from the first group and nine from the second returned, their rates are 35% and 15%, respectively. Those group counts still add up to 120 guests and 30 returning guests.
That difference could prompt the manager to investigate the ordering experience in each channel. It does not establish why guests returned, and it does not identify anyone to contact. The source data must classify each guest consistently; otherwise, the comparison may be unreliable.
The choice changes if the manager’s approved task is to follow up with specific guests rather than compare group performance. A count cannot create a recipient list. Ask whether selection can happen in the restaurant’s own system and whether the AI can receive only a message draft without recipient details. If it must handle a list, define the selected population, required contact fields, authorized users, and next action before sending it.
Also ask what happens with very small groups. A summary can still make a person easy to recognize when combined with other information. Set a minimum group size or combine groups where appropriate, and ask the vendor how its output avoids exposing small-group details.
Test the failure case before relying on an answer
Give the vendor a fictional dataset that includes a deliberate matching problem: for example, one customer appears under two identifiers. Ask the assistant for the return rate and ask the vendor to show how the input was prepared. If the system treats both identifiers as separate guests, the answer may look precise while counting the same person twice.
Name the operations manager as the person responsible for detecting that issue in the demonstration. The manager should compare the assistant’s input counts with a manually prepared control count and stop the result from being used if they differ. The correction is to resolve the matching rule at the source, recalculate the counts, and rerun the question—not to accept a confident explanation from the assistant.
Keep this a simulation. Use fictional records and a test environment. Do not send a real guest message, take a real card payment, or dispatch a courier as part of the practice scenario. If the vendor cannot prevent a simulated action from triggering a live one, do not run that action in the live workflow.
Ask the vendor to explain the data path in plain terms:
- Which fields leave the restaurant’s system, and which service receives them?
- Who at the vendor and its service providers can access the inputs and outputs?
- How long are prompts, uploaded files, logs, and generated answers retained?
- Are restaurant inputs used to improve models, and what choices does the restaurant have?
- How is deletion requested, what does it cover, and how is completion confirmed?
Get the answers in the written agreement or supporting terms, and ask a qualified adviser about contract or legal treatment when needed. Deleting a file from a screen is not, by itself, proof that every retained copy or log has been removed.
Set a pass-or-fail demonstration
Before the demo, give the vendor the exact question, the fictional input, the expected 25% result, and an irrelevant field such as a fictional dietary note. The note is a marker: it should not be included in the data sent to the assistant for this count.
- Inspect the transfer. Ask to see the fields and values sent to the AI service, not just the final answer. Pass if the agreed counts are present and the dietary note, name, and contact fields are absent.
- Check the calculation. Pass if the assistant reports 30 of 120, or 25%, and states the agreed time periods and definition of a completed order. Fail if it changes the denominator or presents an unsupported reason for the result.
- Run the matching exception. Pass if the mismatch is flagged or the control comparison catches it, and the manager withholds the answer until the source counts are corrected. Fail if the wrong result is presented as dependable without an effective check.
- Review access and retention. Pass if the vendor provides understandable written terms for access, retention, and deletion that the restaurant accepts. Fail if the data path or deletion process cannot be explained.
- Confirm the simulation boundary. Pass if the demonstration produces no real guest contact, payment, or courier dispatch. Fail if a practice step can trigger a live action.
Assign the operations manager to record exceptions and decide whether a corrected demonstration is required. If the vendor requests an additional field, pause the test and ask what specific result needs it. The owner should approve a revised scope before any real guest data is shared.
For broader context, review how your team defines sales periods in the sales report workflow and how it compares inputs in this guide to labor hours and sales by shift. Those workflows can help frame management questions; they do not establish what an AI vendor receives.
Next step: Take the worksheet and demonstration criteria to your vendor conversations. Compare your requirements with Fleksa’s restaurant management software and confirm current support before choosing a workflow.
Frequently asked questions
Does an AI assistant need guest names to calculate a return rate?
Usually the calculation can use summary counts if the source system has already matched customers consistently. Ask to see the actual fields transferred and check the denominator before relying on the result.
Are anonymous counts always safe to share?
Not necessarily. Small groups or combinations of details can make someone recognizable. Ask how the vendor handles small groups and limit the detail sent and returned.
Who should approve an exception to the data scope?
Name an owner before the demonstration. The operations manager can document the request and its business purpose; the restaurant owner should approve any revised scope before real guest data is shared.
