Tasks suitable for Robo Claw and how to select implementation candidates in major TMT companies
The target tasks are evaluated from six perspectives: workload, frequency, standardization, number of exceptions, system connectivity, and presence of external transmission. It is recommended to prioritize standardized tasks that span multiple systems and have many exceptions.
When major TMT companies select target tasks for Robo Claw implementation, prioritize tasks that meet the following criteria: ① high occurrence frequency, ② standardized procedures, ③ cross multiple systems, ④ high burden of exception handling, and ⑤ external transmission is limited or can be conditioned on approval. Tasks that meet these criteria are easier to verify for effectiveness in a Pilot.
Who This Is For
Who This Is For
This is intended for development department managers, product managers, QA managers, DX managers, and others who are considering which tasks to start implementing Robo Claw with.
What You'll Decide
What You'll Decide in This Step
In this Discover STEP, we identify candidate target tasks for Robo Claw, prioritize them, and decide on the first 1–2 tasks to undertake. Detailed design of requirements, authority, and approvals will be carried out in the next Refine STEP.
Fit Check
Suitable/Not Suitable Tasks
Suitable Tasks
- Tasks with high frequency and standardized procedures, such as ticket classification and prioritization
- Tasks where initial drafts of decisions, such as writing Pull Request review comments, can be easily reviewed and modified by humans
- Tasks that check information across multiple systems (Jira, GitHub, monitoring tools, etc.)
- Tasks that involve external transmission, provided approval can be obtained before sending
- Tasks where the format of input data is relatively stable (tickets, logs, source code, etc.)
Unsuitable tasks
- Tasks that occur very infrequently and for which automation benefits are difficult to anticipate
- Design tasks that heavily depend on human expert judgment and are difficult to standardize
- Tasks that require immediate reflection of changes to the production environment without approval
- Tasks where input data contains a large amount of highly confidential personal or unpublished information and handling is unorganized
Industry Challenges
Issues specific to major TMT companies
Many companies face the following challenges when selecting target tasks.
Too many candidate tasks to narrow down
There are a wide variety of candidates such as development, QA, incident response, and CS, and it is difficult to determine where to start.
Unable to formulate hypotheses of effectiveness
The actual volume of tickets and effort required for response are not visualized, making it difficult to estimate the introduction effect in advance.
Uncertainty about system connectivity
Whether GitHub or Jira support API integration and the extent of permissions required can only be judged by the information systems department.
Uncertainty in handling tasks involving code changes
There are no criteria to determine whether tasks involving code, such as creating or reviewing Pull Requests, are appropriate to include.
Method
Implementation Steps
1. Identify candidate operations
We will take stock of tasks related to development, QA, operations, and CS, such as ticket classification, code review support, primary incident triage, and primary CS responses.
2. Check workload and frequency
We confirm the frequency of each task (always, daily, weekly, etc.) and the man-hours required to handle them.
3. Evaluate standardization and frequency of exceptions
We will assess whether procedures are standardized and the extent to which exceptional handling (such as major incidents and emergency responses) occurs.
4. Check whether data system connection is possible
Check with the Information Systems Department to confirm the location of the data required for the target operations and whether the system can integrate with it.
5. Confirm the necessity of external transmission and human approval
We will organize the extent to which human approval needs to be retained, including whether it involves external transmission to customers or changes in production.
6. Determine priorities
We will compile the evaluation results and decide on the first one or two tasks to start with.
Evaluation Table
Candidate Task Evaluation Sheet
The following is an example of an evaluation table. Please replace it with your company's candidate tasks. The tasks closer to ◎ have a higher priority for Discover.
| Candidate tasks | Frequency | Formality | Exception frequency | System connection | External Transmission |
|---|---|---|---|---|---|
| Primary Classification and Prioritization of Tickets | Always | Expensive | Moderate | Jira／Backlog | None |
| Creating Pull Request review comments | Daily | Moderate | Middle to high | GitHub／GitLab | Internal only |
| Primary troubleshooting of the malfunction | Irregular | Moderate | Expensive | Monitoring and logging tools | Internal only |
| Drafting initial response to customer inquiries | Always | Moderate | Moderate | CRM / Help Desk | Based on approval |
Data & Systems
Data and Systems Used
In the Discover STEP, the status of the following data and systems is checked to evaluate candidate tasks.
Human-in-the-loop
Where Human Approval Is Required
At the Discover STEP stage, implementation is not performed, but during the evaluation of candidate tasks, the following judgments are organized based on the assumption that they will always be made by humans.
- Final decision on whether the target task can be selected as an automation candidate
- Decision on whether to include tasks involving changes to the production environment or external transmission as candidates
- Judgment on whether to include operations that handle customers' personal information as candidates
Measurement
KPI Candidates
In the Discover STEP, the following are recorded as hypotheses for each candidate task and used as verification material in subsequent steps.
Current work effort
Estimation of the human workload currently required for the candidate task
Effect hypothesis
Hypothesis of the workload and time savings expected if automated
Implementation priority score
Priority calculated from factors such as frequency, regularity, and exception frequency
Pitfalls
Common Pitfalls
Select only tasks where the effects are easily visible
If you select only the prominent tasks without considering their frequency or the burden of handling exceptions, it becomes difficult to verify the effectiveness of the pilot.
Postpone system connection verification
If you decide on candidate tasks first and then check connectivity, rework may occur in later steps.
Start multiple tasks simultaneously
If multiple tasks are carried out concurrently from the beginning, the authority design and pilot evaluation become complicated, and verification will take longer.
FAQ
Frequently Asked Questions
How many tasks are appropriate to start with first?
In most cases, it is recommended to start with 1–2 processes. Handling multiple processes simultaneously can complicate authority design and Pilot evaluation.
Should processes that involve touching the code be excluded from candidates?
It is not always necessary to exclude them. By automating up to the creation of draft review comments and having humans make the merge decisions, they can be treated as candidates.
What should we do if we do not know whether system connection is possible?
Coordinate with the information systems department and confirm whether the target system's API or data linkage is possible. Individual consultations are also available.
Who should evaluate the candidate tasks?
It is recommended that the on-site managers of the relevant processes (development, QA, SRE, CS, etc.) and the information systems department work together. An evaluation that considers both the actual business situation and system constraints is necessary.
Continue
Next Step
Once the target operations are decided, the next step is to concretize the requirements, authorities, and approval design for those operations.
Shall we organize the selection of target operations together?
Based on the current number of tickets, response man-hours, and system configuration, you can consult formally in the LP about the candidates and priority for applying Robo Claw.