Requirements, authorization, and approval design when a logistics startup introduces Robo Claw
Once the target operations are determined, specify the target shippers, delivery areas, delivery workflows, delivery companies, data classification for delivery, customer, location, fee, and billing information, read/write permissions, external transmission, integration with external SaaS/delivery partners, human approvals, responsibility sharing among a small number of people, and KPIs.
The purpose of the Refine STEP is to document 'who automates which processes, to what extent, and under which approvals.' In particular, clarify the approval conditions for dispatch/assignment confirmation, fee/billing updates, and transmission to shippers/customers, the involvement of the safety officer responsible for operational safety decisions, and the sharing of responsibilities among members with concurrent duties at this stage. If you move to the Pilot with ambiguity here, redesigns will occur in the later stages.
Who This Is For
Who This Is For
This is intended for business owners, dispatch/dispatching managers, and CS managers who have determined the target operations in Discover STEP.
What You'll Decide
What You'll Decide in This Step
In Refine STEP, we document the target shippers, areas, delivery workflows, delivery companies, scope of operations, data handled, external SaaS connections, read/write permissions, approval conditions, division of responsibilities among a small number of people, and KPIs, and translate them into requirements that can be validated in Build & Validate.
Industry Challenges
Challenges specific to logistics startups.
The concept of authority is not organized.
Because of the small number of people, there are many cases where it is not clearly documented who can approve what.
Approval rules for dispatch and fare updates are not established.
There are many cases where the rules for who approves dispatch confirmations or fare updates are not clearly documented.
Roles among members with multiple duties are ambiguous.
Sometimes operations are carried out without clearly defining the division of roles among dispatch coordination, delivery operations, and CS staff.
Behavior on re-execution (prevention of double execution/duplicate dispatch) has not been considered.
There are cases where the design has not been considered for whether re-executing the same process would cause duplicate updates to delivery information, duplicate dispatches, or duplicate notifications to shippers or 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 shipper, area, delivery workflow, and delivery company
Clearly define the scope of the target shippers, delivery areas, delivery workflows, and delivery companies.
3. Design Agents, Skills, and Tools
Design the roles of Agents required for the target operations, the Skills for operational procedures, and the scope of Tools for delivery management and TMS operations.
4. Define the Tool Policy
Define as a Policy the operations that Tools are allowed to perform (read/write, Allow/Deny). Confirming actual dispatch and assignment, and updating actual rates and billing is set to Deny.
5. Design permissions for delivery, customer, location, rate, and billing information
Design who can view or update these pieces of information and to what extent.
6. Design shipper/customer transmission, external SaaS, and delivery partner integration
Design the approval conditions for transmission to shippers/customers and the scope of data exchange for each connected external SaaS and delivery partner.
7. Define approval, transport safety officer confirmation, and responsibility sharing for small teams
Define approvers for dispatch/assignment confirmation, rate/billing updates, refund decisions, the confirmation process by transport safety officers involved in transport safety decisions, and responsibility sharing among members with multiple roles.
8. Define Secrets, Logs, Duplicate Execution Prevention, and KPIs
Define methods for managing SaaS API keys, operational logs that should be saved, design to prevent incorrect updates or duplicate dispatches upon re-execution, and the KPIs for measuring effectiveness.
Data & Systems
Data and Systems Used
Human-in-the-loop
Where Human Approval Is Required
- Clearly define the final approver for dispatch and assignment confirmation by role
- Clearly define the final approver for fee and billing updates by role
- Clearly define the final decision-maker (CS manager) for refunds and compensation
- Clearly define the approver for communications sent to shippers and customers
- Obtain confirmation from the person responsible for operational safety regarding operational safety decisions
- Even in a small team, designate a verifier for granting permissions to external SaaS and delivery partners
Measurement
KPI
In the Refine STEP, define candidate KPIs to be verified in Build & Validate
Target level for delivery inquiry classification time
Target time required for inquiry 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 shippers, areas, delivery workflows, and delivery companies (including and excluding specific operations) are documented
- Input data and outputs (classification proposals, summaries, drafts) are defined
- The delivery management, TMS, and mapping services to be connected, and whether the connection is possible, have been confirmed.
- Access rights for reading and writing are defined separately
- The approval conditions and approvers for dispatch/assignment confirmation and rate/invoice updates are defined.
- The approval conditions and approvers for sending to shippers/customers and for refund/compensation decisions are defined.
- The confirmation process by the person responsible for operational safety, which concerns operational safety judgments, is defined.
- The procedure for responding to hazardous/special cargo and customs/import/export matters assumes verification by official information or specialized departments is defined.
- The division of duties among members with multiple roles is defined.
- A design to prevent double updates, duplicate dispatches, and duplicate transmissions upon re-execution (idempotency) is 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 run it first and then adjust authority, significant rework occurs when expanding to multiple shippers and multiple areas.
Proceed with the approver unclear
If approvers are not designated as roles rather than individuals, operations may stop when members are changed.
Make the boundary with operational safety judgment ambiguous.
If dispatch/assignment confirmation and production rate updates are not explicitly denied in the Tool Policy, there is a risk of granting unintended write permissions.
FAQ
Frequently Asked Questions
Which department should lead the requirement definition?
It is recommended that the person in charge of the target operations and management jointly lead, and that the person responsible for operational safety is involved when it concerns operational safety decisions. If external transmission is involved, the CS manager should also be involved.
How detailed should authority design be?
At a minimum, please clarify the read/write scope at the business unit level, and the approvers for dispatch confirmation, fare updates, refunds, and compensation. The level of detail should be adjusted according to the risks of the target business.
What is idempotency?
It refers to the property that even if the same process is executed multiple times, the result does not change and it is not reflected twice. It becomes important for retries during communication errors and preventing duplicate dispatches.
Shall we organize requirements, authorities, and approval design together?
The scope of target operations, SaaS permissions, approval flows, and responsibility allocation can be concretized through consultations with the official LP.