Requirements, Authority, and Approval Design for Major Tourism and Accommodation Companies Introducing Robo Claw
Once the target operations are decided, concretize the As-Is/To-Be, target facilities and regions, input/output, read/write permissions for reservation, customer, itinerary, and pricing data, approvals, job responsibilities, division of responsibilities, logs, idempotency, and KPIs.
The purpose of the Refine STEP is to document “who automates what and under which approvals” for the target operations. In particular, make clear at this stage the approval conditions for reservation changes/cancellations and pricing updates, involvement of the safety officer when handling personal and location information, and the job responsibility division between facilities and headquarters. Proceeding to the Pilot phase with ambiguity here will result in redesign work in later steps.
Who This Is For
Who This Is For
This is targeted at the information systems department, the head of the reservations department, and the risk management officer, who determined the target operations in the Discover STEP.
What You'll Decide
What You'll Decide in This Step
In the Refine STEP, we document the scope of the target operations, the data handled, the reservation management / PMS / CRS connected, read/write permissions, approval conditions, roles and responsibilities, responsibility boundaries, and KPIs, and translate them into requirements that can be validated in the Build & Validate phase.
Industry Challenges
Challenges unique to large tourism and accommodation companies.
The concept of authority differs by facility and region.
Existing authority operations differ by facility and region, making it difficult to design unified permissions.
Approval rules for reservation changes and rate updates are not established.
In many cases, the rules regarding who approves reservation changes and rate updates are not clearly documented.
Roles between facilities and headquarters are ambiguous.
There are cases where operations are conducted without clearly defined role allocation among on-site staff, headquarters personnel, and approvers.
Behavior on re-execution (idempotency) and duplicate reservations have not been considered.
There are cases where the design has not considered whether re-executing the same process could lead to duplicate reservations or double sending to customers.
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 the target brand, facilities, regions, and operations.
Clearly define the scope of the target brand, facilities, regions, and operations.
3. Design Agents, Skills, and Tools
Design the roles of agents necessary for the target operations, the skills required for operational procedures, and the range of tools used for reservation management operations.
4. Define the Tool Policy
Define as a policy what operations (read/write, Allow/Deny) the tool is allowed to execute.
5. Design access rights for reservation, customer, itinerary, and pricing data
Design who can view and update reservation, customer, itinerary, and pricing information by facility and region.
6. Define approvals and division of duties
Define the approvers for reservation changes, cancellations, price updates, and customer communications, as well as the duties of on-site staff and headquarters personnel.
7. Define the process for safety officer confirmation
Define the escalation path to the operational safety officer in situations requiring safety or operational judgment.
8. Define idempotency, duplicate reservation prevention, responsibility boundaries, logs, and KPI
Define designs that prevent double reservations or double sending upon re-execution, responsibility boundaries between AI agents, systems, and humans, operational logs to be saved, and metrics KPIs.
Data & Systems
Data and Systems Used
Human-in-the-loop
Where Human Approval Is Required
- Clearly define the final approvers for reservation confirmation, changes, cancellations, and price updates by position.
- Clearly define the final decision-makers for safety and operational judgments (facility manager and operational safety officer).
- Obtain confirmation from the legal and security departments regarding the scope of handling customer and location information.
- Obtain approval from the information systems department for authority assignments that span facilities and regions.
Measurement
KPI
In the Refine STEP, define candidate KPIs to be verified in Build & Validate
Target standard for initial classification time of reservation inquiries
Target time from inquiry to primary classification
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 target brands, facilities, regions, and businesses (including included and excluded businesses) are documented
- Input data and output (guidance text, reports, proposed itineraries) are defined
- The reservation management, PMS, and CRS systems to be connected and the feasibility of connection have been confirmed by the information systems department
- Access rights for reading and writing are defined separately
- Approval conditions and approvers for reservation changes, cancellations, rate updates, and customer communications are defined
- The process for confirming the safety officer for situations involving safety and operational judgments is defined
- The division of duties between on-site staff and headquarters personnel is defined
- Design to prevent double bookings or double sending during re-execution (idempotency) has been 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 first running the system, significant rework occurs when deploying across multiple facilities
Proceed with the approver unclear
Deciding approvers by individual name rather than position will cause operations to stop during transfers or resignations.
Omitting consideration of duplicate booking prevention
If behavior upon re-execution is not considered, there is a risk of double booking when retrying due to communication errors
FAQ
Frequently Asked Questions
Which department should lead the requirement definition?
It is recommended that the on-site business manager and information systems department jointly lead the process; if related to safety and operations, involve the risk management department, and if customer communication is involved, also involve the security and legal departments.
How detailed should authority design be?
At a minimum, please clarify the read/write scope at the facility and regional levels, as well as the approvers for reservation changes, rate updates, and customer transmissions. The level of detail will be adjusted according to the risk of the target operations.
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.
Shall we organize requirements, authorities, and approval design together?
The scope of target operations, reservation management/PMS permissions, approval flow, and responsibility boundaries can be concretized through consultation on the formal LP.