How to utilize Robo Claw in TMT startups and how to choose potential implementation tasks
The target tasks are evaluated from six perspectives: workload, frequency, standardization, number of exceptions, initial cost, and operational burden. It is recommended to prioritize standardized tasks with a high dual-role burden, which are easier to measure effectiveness with a small team.
When selecting target tasks for Robo Claw implementation in TMT startups, prioritize tasks that (1) occur frequently, (2) have standardized procedures, (3) place a high burden on employees with multiple roles, (4) involve limited external communication or can be approval-based, and (5) can start with low initial cost. Tasks that satisfy these criteria make it easier to verify effectiveness with a pilot even with a small team.
Who This Is For
Who This Is For
This is intended for CTOs, Heads of Product, VPs of Engineering, and others who are considering which tasks to start implementing Robo Claw with in small teams.
What You'll Decide
What You'll Decide in This Step
In this Discover STEP, we will identify candidate tasks for Robo Claw, prioritize them, and decide on the first task to undertake. Detailed design of requirements, permissions, and approvals will be handled in the next Refine STEP.
Fit Check
Suitable/Not Suitable Tasks
Suitable Tasks
- Tasks such as ticket classification and initial CS responses that take up a significant amount of time for staff handling multiple roles.
- Tasks such as creating Pull Request review comments, where humans can easily check and revise the initial judgment proposals.
- Tasks that require checking across SaaS and APIs (GitHub, Linear, 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 with extremely low occurrence frequency, where even small teams are unlikely to see automation benefits.
- Product design tasks that heavily rely on human expert judgment and are difficult to standardize.
- Tasks that require immediate reflection of changes to the production environment without approval
- Tasks that involve input data containing highly confidential customer information and are not yet organized for handling.
Startup Challenges
Challenges unique to TMT startups.
At the stage of selecting target tasks, many startups face the following challenges:
Too many candidate tasks to narrow down
There are many candidates, such as development, QA, incident response, and CS, making it difficult for small teams to decide where to start.
Unable to formulate hypotheses of effectiveness
The actual labor hours for roles with multiple responsibilities are not visible, making it hard to estimate the expected effects of implementation in advance.
Wanting to keep initial costs low.
There is a strong need to start with tasks where cost-effectiveness is easy to see within a limited budget.
Unsure how to handle tasks that involve touching code
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 take stock of the tasks being handled concurrently, such as ticket classification, code review support, initial troubleshooting of incidents, and first responses to customer service inquiries.
2. Check workload and frequency
We check the frequency of each task and the man-hours required to handle them.
3. Evaluate standardization and frequency of exceptions
We evaluate whether the procedures are standardized and how often exceptions (such as major incidents) occur.
4. Check candidate connections
We confirm the location of the data required for the target tasks and whether it can be integrated with SaaS or API.
5. Estimate initial costs and operational load
We estimate the initial cost of implementation and whether the concurrent task personnel can continue to handle the operational load.
6. Determine priorities
We will compile the evaluation results and decide on the first task to start.
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 | Candidate connections | External Transmission |
|---|---|---|---|---|---|
| Primary Classification and Prioritization of Tickets | Always | Expensive | Moderate | Linear／Jira | 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 |
| Creating draft responses for first customer service 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
Estimated man-hours of the current concurrent task personnel for candidate tasks
Effect hypothesis
Hypothesis of the workload and time savings expected if automated
Estimated initial costs
Estimate of initial costs for building and connecting the pilot
Pitfalls
Common Pitfalls
Select only tasks where the effects are easily visible
If you choose only the most noticeable tasks without considering frequency or operational burden, a pilot operation with a small team will not be sustainable.
Postponing connection checks
If you decide on candidate tasks and then check API connectivity, you may need to backtrack in later steps.
Start multiple tasks simultaneously
If multiple tasks are progressed simultaneously with a small team, permission design and pilot evaluation become complex, and verification takes longer.
FAQ
Frequently Asked Questions
How many tasks are appropriate to start with first?
We strongly recommend starting with one task for a small team. Handling multiple tasks at the same time makes permission design and pilot evaluation more complex and increases the workload.
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 I do if I don't know if connectivity is possible?
Please check whether API integration is possible with the subscription plan of the SaaS/API you are using. Individual consultations are also available.
Who should evaluate the candidate tasks?
It is recommended that the evaluation is centered on the personnel who are actually concurrently responsible for the target tasks (development, QA, CS, etc.), as they understand the actual workload the best.
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 workload, man-hours, and system configuration, you can consult on the suitability and priority of Robo Claw application candidates in the formal LP.