Decide Which Tasks to Stop Before Introducing AI

Even when AI can produce a report, the workload may not fall as much as expected if staff still have to copy the information into Excel and explain it individually to their manager. Entering information into the AI, checking its output, and copying it back into the old workflow can add more work.

For business leaders and department heads considering AI, the first question we suggest asking is: “Which tasks will we be able to stop after introducing it?” Netsujo starts by helping clients work through that decision and translate the conditions for changing the workflow into requirements the implementation team can use.

Why does this task still exist?

Consider a process in which a head office consolidates reports from its branches. As an illustrative example, suppose a staff member copies information from each branch's file into a summary, and the person responsible checks the contents.

If AI takes over the copying but the person responsible still rereads every source file, the overall workload may barely change. Yet rereading serves a purpose: checking that the numbers agree and spotting unusual results. Removing that check along with the copying could sacrifice the quality it protected.

Start by identifying the purpose, before focusing on the name of the task.

This helps us consider a division of responsibility in which, for example, copying becomes a candidate for automation while people retain judgment over unusual results. Even if little is automated, reducing unnecessary copying or duplicate reporting can still improve the process. The scope for AI can be decided once it is clear which work needs to remain.

We reviewed when duplicate automated checks were being triggered internally

In Netsujo's own development, more AI-assisted changes and reviews led to automated checks serving the same purpose being triggered repeatedly. Even documentation changes that did not alter code caused database and browser test environments to be prepared.

We changed the setup to classify changes at the entry point and avoid starting environments that documentation changes did not need. Checks covering contract-related wording and execution safety conditions that could be affected by documentation changes remained in place. Changes that cannot be classified fall back to the broader set of checks.

The following results come from one actual documentation-only pull request in our implementation log, published in August 2026 and updated on October 18. A pull request, or PR, groups changes together for review.

Elapsed time fell by 7 minutes 22 seconds, or 77.4%. This is the reduction in elapsed check time for one PR. Any reduction in the monthly bill would need to be calculated separately.

The focus here was the purpose of each task and the conditions under which it should run. We retained the checks that were needed and stopped processing that the particular change did not require. In client workflows, we similarly help distinguish checks that must remain from duplicated work, so the client can decide what can be stopped.

Before making it faster, we questioned why it needed to run

An important part of this review was moving away from the question of how to make every process a little faster. If preparing an environment takes time, tuning caches or the execution environment is one option. But does a documentation-only change need that environment at all? That was the first thing we checked.

CI is a mechanism for automatically checking whether changes have caused problems. Running a broad set of checks can be easier to understand when first setting it up. As the types of changes and number of runs grow, however, there is room to revisit that assumption. Running the same steps every time and checking the necessary quality every time can be considered separately.

In the implementation log, classification at the entry point determines whether checks involving application code, browsers, or databases are needed. If classification happens after the expensive setup, skipping a check still leaves the preparation time. Deciding what a particular change needs before that preparation starts was an important part of the improvement.

The same question can be applied to a client's business process. If someone formats meeting materials every week, for example, we would first check who uses which fields to make decisions, before asking AI to do the formatting. Producing unused fields faster can simply increase the volume produced. Separating fields that people use, fields they consult only when something unusual happens, and fields that currently go unused can change the system that is needed. This meeting-materials scenario illustrates how the reasoning applies to business work; it is not a claim about a completed client engagement.

What should remain when a change cannot be classified?

Reducing unnecessary runs also requires thinking about the risk of skipping something by mistake. Should a change still be treated as documentation-only when a new type of file appears or when the list of changed files cannot be retrieved?

In our internal design, uncertain classifications fall back to the broader checks. Without evidence for taking the faster route, the system does more checking. Checks that were not run are also recorded as “not run.” Marking skipped checks as passed would make it unclear later which checks had actually been completed.

This reasoning can also apply when AI processes business forms. Forms with all required fields that meet the comparison conditions can be processed automatically, while those in a different format or with unreadable content are routed to a staff member. Defining when to hand work to a person can make routine processing lighter without burying cases that require judgment. The errors that can be tolerated vary by business process, so we agree on them with the responsible person on the client's side.

Being able to explain both why the process became faster and the conditions that protected quality makes the improvement useful for the next change, too.

Who needs to agree to the workflow change?

Frontline staff understand the effort involved, while department heads are responsible for the process's purpose and quality. IT staff understand constraints on data and connected systems. If an introduction proceeds on the judgment of just one of these people, unresolved conditions can surface when operation begins.

Netsujo helps organize the questions that sit between these roles. We ask what takes time, narrow the scope of the current change, and turn the data to be used and the necessary checks into implementation requirements. The final decision to change the business process remains with the responsible person on the client's side.

Netsujo's representative, Iida, handles Technical BizDev / AI Deployment, connecting the definition of client problems, technical scoping, proof of concept, and evaluation after production deployment. Implementation of the core product and specialist areas is shared with the CTO and the engineers responsible. The aim is to make decisions reached in client discussions usable during development and acceptance as well.

Decide when to stop the old procedure—and when to return to it

While trying a new method, it may be necessary to run the old and new approaches in parallel for comparison. But if the purpose and exit conditions of that comparison remain unclear, both procedures can become part of everyday work.

Before the trial, decide which conditions must be met to stop the old procedure. In the earlier example, those checks would include detecting missing required fields, tracing information back to the original report, and routing exceptions to a staff member. Then agree who will decide to switch and which procedure to return to if a problem occurs.

The task being stopped can be just one part of a process. There is no need to change every report at once; copying routine fields could be reviewed first. Make a small change, examine the checking effort that remains, and use that to make the next decision. We design the scope needed for that cycle.

Trace one case in the first meeting

When discussing a workflow, it helps to trace a recently completed case rather than define the scope solely from a general sense that “this is always hard.” Where did the request arrive? Who searched for information? Which table was it copied into? Where did approval stall? Matching the actual materials to the sequence of events makes the boundaries between tasks clearer.

In the branch-reporting example, we would look beyond the screen of the person consolidating the reports and check what the responsible person receiving the report actually looks at. Faster consolidation can create more back-and-forth checking if it loses the sources or explanations behind unusual results that this person needs.

What is useful to leave from that meeting is a short record that supports the next implementation decision, rather than an elaborate workflow diagram.

This is an example of a record to fill in during a meeting, rather than a log of a completed engagement. In an actual engagement, it would include names, the period covered, baseline values, and a specific assessment method. Items that could not be decided should also be shared as open questions, with an owner and a date for checking them.

What will the saved time be used for?

The purpose of improving a workflow should include what people will do after the time spent on a task falls. Will time saved on copying be used to investigate unusual results? Will staff use it to respond to clients? Is the aim to reduce overtime? The purpose changes both the metrics to measure and the operating arrangements needed.

What we confirmed in the internal CI example was a shorter wait for one check run. That number alone does not establish an improvement in the company's overall development speed or profit. In client proposals, we likewise distinguish the change observed from the value expected beyond it. We then decide what to measure next to support a business decision.

What you can discuss with Netsujo

Even at the stage of “we want to do something with AI,” work can begin if the business process causing difficulty is identifiable. Starting with forms people actually use, or situations in which they repeatedly explain the same thing, we clarify the purpose of the work, what can change, and which decisions should remain with the client.

Netsujo's AI implementation support covers workflow analysis, proof of concept, evaluation design, integration with existing systems, production implementation, and operational design. The scope of advisory and review support, and the scope in which we take on implementation and operation, are agreed individually.

Start by naming one task you repeat every day. Together, we can work through why it continues and what would need to be verified before you could stop it.

Explore our AI implementation support / Discuss your business process

References

• Netsujo's services and scope of responsibility
• The roles of Iida and the implementation team