A Non-Developer's Workflow Automation Case That Began with a Staffing Rejection

People overwhelmed by repetitive tasks often begin by looking for ways to process them faster. But this case began differently. In a situation where adding staff was difficult, a project management specialist reconsidered why every request and review had to pass through them, rather than simply accelerating the work already concentrated in their hands.

This article does not introduce the features of automation technology. Instead, it analyzes the work environment that made automation unavoidable, the first structural improvements, the learning process of a non-developer, and the principles that can be generalized from that experience.

The Starting Point of the Case: Complexity Increased More Than Work Volume

The team had originally been responsible for an infrastructure operations project. It already had familiar workflows for keeping systems stable, responding to incidents, and compiling monthly performance results. The problem began when a new maintenance project was added without changing the existing staffing level.

This was different from performing the same work twice. While handling unfamiliar tasks, the specialist also had to design the following elements from scratch.

• Which deliverables to receive
• Which items to include in the documents
• How to determine the review sequence for vendors and customers
• How to manage numbers and schedules for each task
• How to collect and report signed deliverables

The core cause of the overload was not merely that the amount of work had increased, but that the system for processing it also had to be created.

Without Standards, Reviews and Rejections Are Repeated

Because the existing standards for maintenance deliverables were insufficient, the specialist created forms and distributed them directly to vendors. At work sites, however, recurring problems included the use of forms from the previous year, missing worker signatures, and ambiguously written notes.

For example, if a result field says only “action to be taken later,” the manager cannot track when it will be completed. The document must be rejected with a request to provide a specific expected date, and the revised version must then be reviewed again. This creates a structure in which the administrative work of checking and correcting deliverables becomes greater than the inspection itself.

This case shows that standardization must come before document automation. If input formats and required fields have not been defined, an automation tool will merely transfer ambiguous and incomplete data more quickly. Before considering automation, the following should be determined.

1. Fields that must be completed
2. Permitted formats for dates and names
3. Conditions requiring signatures or attachments
4. Reasons for rejection and the person responsible for corrections
5. Criteria for determining completion

Why Requests That Took Only a Few Minutes Disrupted the Entire Day

For security reasons, bringing external files in and taking them out was handled through a single point of contact: one designated specialist. Each request did not take long to process, but the problem was that requests arrived without warning.

When a request came in while the specialist was focused on their primary work, they had to stop and process the file. They then had to recall the context of the interrupted task. In this case, repeated task switching increased the perceived burden more than the time required for each individual request.

When identifying candidates for automation, it is not enough to calculate only the time needed to process one request. The following costs must also be considered.

• Time spent checking requests and determining priorities
• The switching cost of stopping and restarting existing work
• Time spent asking the requester again for missing information
• Time spent separately recording and reporting whether a request was processed
• Waiting time when a specific specialist is absent

Short but unpredictable recurring requests can become bottlenecks that significantly disrupt overall schedules and concentration.

The First Solution Was Not Automation but Removing a Route

The first improvement to the file transfer issue was not software development. The workflow was changed so that requesters and customers could exchange requests directly through a bulletin board in the internal project management system.

The principle that can be drawn from this is clear. Rather than performing an assigned task faster, a better solution may be to ensure that the task no longer needs to pass through you.

Before designing automation, it is useful to review the process in the following order.

1. Is this a step that can be eliminated?
2. Can the requester enter or verify the information directly?
3. Can the route be simplified using features of the existing system?
4. Can the input and decision criteria be standardized?
5. Can the repetitive work that remains afterward be automated?

Overload Became Entrenched as Multiple Simple Tasks Arrived at Once

The overall maintenance workflow included establishing schedules, organizing vendor and worker information, assigning numbers, collecting work logs, obtaining customer reviews and signatures, scanning, reporting inspection results, and delivering outputs to each vendor. None of these stages was individually difficult, but when they overlapped, it became difficult for one person to control them through memory and manual work alone.

This situation continued for about three months. During the day, the specialist handled file transfer requests, vendor inquiries, confirmations from team members, and customer requests. Only after business hours, when incoming communications decreased, could they address the backlog of core tasks. Rather than solving the problem, they were continually catching up on events that had occurred that day.

The specialist requested additional support staff, but the request was denied. Once adding personnel was no longer possible, changing the existing approach became important. Automation was not a hobby that began out of personal interest. It was a response to the conclusion that the same problems would recur the following month under the current work structure.

A Claude Code Demonstration Prompted a Small Experiment

The turning point was a demonstration of automation using Claude at a headquarters event. More important than the complex development technology was recognizing the possibility that “we could apply this tool to our work as well.” A conversation with a colleague who attended the event about trying something small became the starting point for the subsequent automation work.

The specialist, who was not a developer, began by asking another generative AI how to install Claude Code. They reviewed and ran instructions and commands appropriate for the operating system and followed other users’ initial setup processes through video materials and other resources. They did not begin only after fully learning programming theory.

However, this approach does not mean that commands from unknown sources should be run without review. On work devices, organizational security policies and software installation permissions must be checked, and installation procedures from official documentation should be used whenever possible. Before running a command, users must also verify whether it deletes files, changes permissions, or transmits data externally.

The Interactive Problem-Solving Process Was More Important Than the Output

The first output gave the specialist confidence that “even a non-developer can build automation.” In this case, however, the more important learning came from the creation process rather than the finished program.

Interactive development generally proceeds through the following cycle.

• Explain the problem to be solved and the current procedure.
• Provide constraints such as input files, output formats, and security restrictions.
• Review the method and code proposed by the AI.
• Run them using copies or test data.
• Explain the error messages and results that differ from expectations.
• Apply the revisions and verify them again.

Generative AI can suggest technologies or approaches that users did not know about, and users can ask it to explain unfamiliar terms again. On the other hand, its suggestions are not always accurate or suitable for the organization’s environment. AI should therefore be treated not as an approving authority that makes judgments on the user’s behalf, but as an assistive tool that expands the available options and reduces trial and error.

Criteria for Selecting Automation Targets Derived from the Case

Not every task needs to be automated simply because it is repetitive. Evaluating the following criteria together makes it easier to set priorities.

The first tasks to automate are generally small tasks with clear rules, high repetition frequency, and results that people can easily compare and verify. In contrast, it is safer to retain human review stages for work involving legal judgments, security approvals, contractual responsibility, or decisions about significant amounts of money.

Controls and Maintenance That Are Easy to Overlook in Automation

If automation is rushed because the work is urgent, the risks of existing manual processes may simply be transferred into code. Particularly in an environment like this case, where external files, signed documents, and customer data are handled, controls must be designed alongside processing speed.

Minimum Controls to Review

• Permissions: Limit the folders and accounts that the automation tool can access to the necessary scope.
• Data protection: Do not enter personal information, contract materials, or authentication information into unauthorized external AI services.
• Test environment: Run the automation first using copies rather than originals and using de-identified test data.
• Human approval: Add confirmation procedures for difficult-to-reverse steps such as file transfers, deletion, and final reporting.
• Records: Retain records of inputs, execution times, processing results, errors, and revision history.
• Recovery: Preserve originals and backups so that the previous state can be restored after a failure.
• Dependency on the person responsible: Document how to run and stop the automation so that team members other than its creator can use it.

The success criterion for automation should not be that “it ran once.” It should also be evaluated based on whether it can be modified when forms change or the person responsible is replaced, whether errors can be detected, and whether the process can return to a manual procedure. These criteria distinguish a short-term personal productivity tool from a sustainable work system.

Facts Confirmed by the Experience and Limitations of Generalization

Because this case is based on the actual experience of one specialist, it does not guarantee the same results for every organization. It is necessary to distinguish between what was directly confirmed in the case and what must be verified when applying it in another environment.

The core value of this case, therefore, does not lie in claiming that a particular tool produces the same results for everyone. It lies in redefining repetitive work not as a lack of individual effort, but as a problem involving workflows, standards, permissions, and bottlenecks.

Conclusion: A Lack of Time Can Be the Starting Point

Automation does not have to be treated only as a separate project to learn after spare time becomes available. If work continues to accumulate and the same problems will recur the following month, that may be a signal that the current structure needs to change.

The starting point does not need to be an ambitious development plan. You can choose the one request that most frequently breaks your concentration and first determine whether that step truly has to pass through you. If it cannot be eliminated or transferred to an existing system, it is safer to standardize the input format and begin by automating a small part whose results can be easily verified.

The most important question left by this case is not, “How can I do this work faster?” It is, “Why does this work keep recurring, why must it pass through me, and how much of the process can be entrusted to a system?”