Pareto 8:2 — The Bot Strips Away 80% of Repetitive Execution
Count support inquiries by type and there are dozens of kinds, but the actual volume clusters in a few. Routine inquiries — account-identifier lookups, login and email changes, simple status checks — make up most of the incoming count. As a share of types they are only 20%, yet they eat 80% of the workload: a textbook Pareto 8:2.
This 20% of types have predetermined answers and are done after a single lookup of the operational DB. It is work people have no reason to repeat, and yet the very work that steals the most of their time. So it is the first target for automation. The AI CS bot strips away this 80% of repetitive execution.
The key is to separate types from volume. A large number of types does not make automation hard; handing over only the few high-volume types already cuts the human load sharply. So when choosing what to automate, you look not at the hardest inquiries but at the most frequently repeated ones whose answers are already fixed.
How Does the CS Bot Handle Repetitive Inquiries?
We ran this structure in the support operation of a pharmacy-software company. When an agent calls the bot in an internal messenger channel, the bot queries the operational DB and replies with sources attached. Ask for a given pharmacy's account ID and it looks it up and tells you; send a request to change the signup email and it identifies the account, checks whether the change is possible, then guides through the steps or executes it directly.
Two things are key. First, sensitive changes go through human confirmation while simple lookups and guidance are finished automatically. Second, every answer cites the evidence it looked up, keeping hallucination in check. It is trustworthy not because the bot is clever, but because the data it references is accurate and its answers carry sources.
The actual screen makes the flow clear. An agent mentions the bot to ask about a pharmacy account, and the bot finds the account ID in the operational DB and answers with sources. For a request to change the signup email, it identifies the account, narrows the target by business number and pharmacy name to find the exact account, attempts the change, and re-checks the result — stepping through the lookup, matching, and confirmation a person used to do.
The Next Step — AI Plans and Builds New Services on Its Own
After stripping away repetitive execution comes planning and development. AI monitors posts in a domain community, analyzes them weekly, and produces a briefing on what the issues are and which unmet demands recur. It does not stop there: it auto-plans recurring demand into new services or features and files them as JIRA issues.
Then comes development. For an issue people have marked Go, AI builds it automatically and runs E2E tests. In other words, both the discovery and planning of 'what to build' and the implementation and verification of 'how to build it' move to the machine side. This is a structure currently being built at SH Consulting.
The briefing is more than a summary. It gathers recurring complaints and workaround requests into 'opportunity' items, and once the same demand crosses a certain frequency, it promotes that to a candidate feature or service. Instead of launching fresh market research, it wires the voices already piling up in the community straight into the product backlog as input.
People Judge at Only Two Points — HITL
In this pipeline, people intervene at exactly two points. The first is the Go/Stop decision in the two-week sprint meeting: among the planning issues AI filed, people choose what to actually build. The second is functional testing after development: people give the E2E-passed output a final review and decide whether to ship.
The two points are not accidental. Setting direction (what to build) and owning release quality (whether to ship) are judgments people must make. The repetitive labor in between — monitoring, analysis, writing specs, coding, writing tests — is handed to the machine. This is the design principle of Human In The Loop (HITL).
The two gates differ in nature. The earlier Go/Stop is a judgment of direction — is this worth building? — while the later functional test is a judgment of quality and accountability — is it fine to ship this to users? One filters the entrance, the other guards the exit. Everything between is the machine's job.
Why HITL Rather Than Full Automation?
The danger of full automation is that it produces the wrong direction fast and at scale. Hand direction-setting and the ship decision to a machine, and the cost of undoing a mistake grows. The two human gates absorb exactly that risk. AI does not kill bad ideas on its own; people screen them with Go/Stop.
The more we hand to AI — from execution (the CS bot) to planning and building (the autonomous pipeline) — the more human work converges onto two judgment points. What AX points to is not pushing people out of the pipeline, but keeping people freed from repetition precisely where judgment is required.
In the end this structure changes the human role. Instead of handling repetitive execution, people spend their time deciding what to build and owning the result that comes out. If the goal of AX is not to replace people but to make an organization evolve on its own, HITL is a way to carve that goal into the automation pipeline as structure.