Requirements, authority, and approval design when a major restaurant company introduces Robo Claw
Once the target tasks are decided, specify As-Is/To-Be, target brands/stores, input/output, read/write permissions for reservation, customer, menu, and allergy data, approvals, job responsibilities, responsibility boundaries, logs, idempotency, and KPIs.
The purpose of the Refine STEP is to document "who will automate what to what extent under which approvals" for the target tasks. In particular, clarify at this stage the approval conditions for menu/price updates and customer transmissions, the involvement of the food safety officer when handling allergy information, and the division of duties between stores and headquarters. Proceeding to the Pilot stage with ambiguity here will result in redesign in later processes.
Who This Is For
Who This Is For
This is aimed at personnel from the information systems department, store operations managers, and quality/food safety officers who decided on the target tasks in the Discover STEP.
What You'll Decide
What You'll Decide in This Step
In the Refine STEP, the scope of the target operations, the data handled, the connected reservation, POS, and CRM systems, read/write permissions, approval conditions, job responsibilities, accountability boundaries, and KPIs are documented and broken down into requirements that can be verified in Build & Validate.
Industry Challenges
Challenges unique to large restaurant chains
The concept of permissions differs for each store and brand.
The existing permission operations differ for each store and brand, making it difficult to have a unified permission design.
Approval rules for menu and price changes are not established.
In many cases, the rules for who approves menu revisions and price changes are not clearly documented.
The roles of stores and headquarters are ambiguous.
There are cases where the divisions of roles between store staff, headquarters personnel, and approvers are not clearly defined in operations.
Behavior upon re-execution (idempotency) has not been considered.
There are cases where the design has not been considered to prevent duplicate sending to reservations or customers when the same process is re-executed.
Method
Implementation Steps
1. Organize As-Is/To-Be
We organize by comparing the current business flow with the business flow aimed for after the introduction of Robo Claw.
2. Define target brands, stores, and operations.
Clarify the scope of the target brands, stores, and operations.
3. Design Agents, Skills, and Tools
Design the roles of agents required for target operations, the skills for business procedures, and the scope of tools used for reservation and POS operations.
4. Define the Tool Policy
Define as a policy what operations (read/write, Allow/Deny) the tool is allowed to execute.
5. Design permissions for reservations, customers, menus, and allergy data
Design who can view and update reservations, customer, menu, and allergy information, and to what extent, by brand and store.
6. Define approvals and division of duties
Define approvers for menu, price changes, and customer communications, as well as the division of duties between store staff and head office personnel.
7. Define the food safety manager confirmation process
Define the escalation path to the food safety manager in situations where decisions related to allergies or food safety are required.
8. Define idempotency, responsibility boundaries, logs, and KPIs
Define designs to prevent double updates or double sending upon re-execution, responsibility boundaries among AI agents, systems, and humans, operation logs to be retained, and KPIs for effectiveness measurement.
Data & Systems
Data and Systems Used
Human-in-the-loop
Where Human Approval Is Required
- Clearly specify the final approver of menu and price changes by job position
- Clearly specify the final decision-maker for allergy suitability (store manager, food safety manager)
- Obtain confirmation from the Legal and Security departments regarding the scope of handling customer and reservation information.
- Obtain approval from the Information Systems department for authorization across brands and stores.
Measurement
KPI
In the Refine STEP, define candidate KPIs to be verified in Build & Validate
Target level for store daily report creation time.
Target time required to create the daily report summary.
Lead time until approval
Time required from draft creation to human approval
Number of detected permission deviations
Number of detected operations exceeding the defined permission scope
Checklist
Requirements definition checklist
- The applicable brands, stores, and tasks (including tasks included and not included) are documented.
- Input data and outputs (daily reports, reports, notifications) are defined.
- The reservation, POS, and CRM systems to be connected and their connectivity have been confirmed by the Information Systems department.
- Access rights for reading and writing are defined separately
- Approval conditions and approvers for menu and price changes and customer communications are defined.
- The confirmation process by the food safety officer for decisions related to allergies and food safety is defined.
- Roles and responsibilities of store staff and head office personnel are defined.
- A design to prevent double updates or duplicate transmissions when re-executing (idempotency) is being considered.
- The scope and retention period of operation logs are defined.
- KPIs used for effect measurement are defined
Pitfalls
Common Pitfalls
Postpone authority design.
If you try to adjust permissions after running first, significant rework will occur when deploying across multiple stores.
Proceed with the approver unclear
Deciding approvers by individual name rather than position will cause operations to stop during transfers or resignations.
Omitting the documentation of the allergy confirmation process.
If you proceed without deciding who will conduct the final check, operations will vary from store to store, and the responsibility in case of an accident will be unclear.
FAQ
Frequently Asked Questions
Which department should lead the requirement definition?
It is recommended that the field managers of the target operations and the information systems department lead jointly, and if it involves allergies or food safety, also involve the quality/food safety managers, and if it involves sending information to customers, involve the security and legal departments as well.
How detailed should authority design be?
At a minimum, clearly define the read/write scope at the brand/store level and the approvers for menu/price changes and customer communication. The level of detail should be adjusted according to the risk of the target operation.
What is idempotency?
This refers to the property where the result does not change and is not duplicated even if the same process is executed multiple times. It becomes important in cases such as retries due to communication errors.
Continue
Previous and Next Steps
Shall we organize requirements, authorities, and approval design together?
The scope of the target operations, reservation/POS privileges, approval flows, and responsibility boundaries can be concretized through consultations on the official LP.