Automating the busy stage can make the queue worse

TL;DR: My first automation question is where useful work stops moving. Sharran Srivatsaa’s discussion with Tiffany Guillen offers a compact way to ask it: opportunities arrive, a system converts them, and someone delivers the promised result. This is useful for service businesses and the teams building automation for them.

Around the four-minute mark, Srivatsaa separates traffic, systems and skills. Around six minutes, he proposes starting with one controllable traffic source, one conversion mechanism and one delivery channel. The point is to make a functioning business easier to diagnose before multiplying its parts.

I would apply that frame to an automation backlog. The task with the most repetitive clicks is not necessarily the task whose improvement changes the business. It may sit in front of a stage that cannot absorb any more work.

Follow one request all the way through

Imagine a small research service receiving plenty of enquiries. Qualification is slow, so a team proposes an assistant that replies immediately and books more calls. Meanwhile, the founder personally reviews every final report and is already behind. This is a constructed example, but the competing interventions are familiar.

Faster qualification could help customers get an answer. It could also create more accepted projects waiting for delivery. If the team measures only booked calls, the automation looks successful while the customer experience deteriorates later.

I would trace a recent request from first contact to accepted work and ask three questions: were enough suitable opportunities available, did suitable opportunities become commitments, and could the team deliver those commitments to the required standard?

The answers should come from the work record, not from whichever department speaks most confidently. A low conversion rate may reflect poor fit rather than a weak sales script. A delivery delay may reflect missing customer inputs rather than insufficient production capacity. The categories start the investigation; they do not finish it.

Choose a smaller intervention with a visible consequence

In the example, I would test a report-preparation aid that assembles evidence and exposes missing inputs before the founder’s review. Keep the final quality check, then see whether the reviewer can complete more acceptable reports without additional rework.

That experiment targets the suspected constraint. If it fails, the team learns where the time actually goes. If it succeeds, the next constraint may appear elsewhere. The diagnosis should be revisited after the change rather than treated as a permanent label for the business.

The interview is practical advice and personal experience, not causal evidence that a three-part framework guarantees growth. Its income examples should not become a forecast for another company. My automation application is a proposed way to test the diagnosis.

I would keep one measure at the end of the chain: work accepted by the customer at a cost the business can sustain. Local improvements still matter, but they should be connected to that outcome.

The useful automation may be a small change in the least glamorous stage. That is a good result if it allows the whole operation to deliver.

Automate the constraint you can demonstrate, then check whether more useful work reaches the customer.