How do you handle more visual requests without overloading your best people?

Stop treating visual requests as one queue. Classify them into repeatable work with specified inputs and exception work that needs expert judgment, then move only the first category into reviewed workflows that trained staff can run. The measure that matters is specialist minutes consumed by routine requests, not images produced. The goal is not fewer experts; it is experts spending their time on the work only they can do.

A visual queue that nobody has written down cannot be shortened on evidence. It can be felt, and the person it lands on can be named, but what arrives, at what rate, and what it displaces is nowhere on paper.

Without that record every intervention is guesswork and any improvement is unprovable, which is why the first work here is not automation. It is two weeks of recording.

Record four things: the request, the requester, the time taken, and what the person was doing when it arrived. That last column is the cost a timesheet has no field for, and it is the one a recording sheet has to be designed to capture rather than one it collects on its own.

Volume is a misleading number. Twenty identical finish-swap requests and twenty bespoke concept visuals are the same volume and two different problems.

Classify by demand type instead: what varies between instances, what has to be decided, and who could legitimately decide it. A request that varies only in its inputs is a different species from one that varies in what it is asking for.

Demand type is a property of the instance rather than of the request's name. The same words in the same email can arrive as either species depending on what has already been specified elsewhere.

Apply the test one instance at a time rather than one category at a time. A classification made at the category level misroutes every instance that does not match its own label, and misrouting is the mechanism behind both failures in the limits section below.

This part publishes no study. It publishes the model you populate yourself, and it has three quantities: the arrival rate of each demand type, the minutes one instance consumes, and the recovery cost — the time it takes to get back into the work the request interrupted.

Recovery cost is the quantity that escapes a timesheet, and that follows from what a timesheet records rather than from anything anyone watched. A timesheet has a field for the task; it has no field for the resumption. So the resumption is unlogged, and a load can be real and absent from the record at the same time.

Moving a routine request out of a specialist's day removes both quantities attached to it, the minutes and the resumption, which is why the measure in the evaluation section below is specialist minutes rather than images produced.

This guide publishes no measured result of its own. The model above is a method to run on your own numbers, and nothing here establishes what it will say when you do.

The workflows are the easy part. The governance is what decides whether this holds: who may run which workflow, what a reviewer checks before an output is accepted, and what happens when a request does not fit the pattern.

The exception rule matters most. Without an explicit route back to a specialist, an operator has two options and both are bad — escalate everything, which changes nothing, or force an unsuitable request through the workflow, which is worse than the queue it replaced.

Write both rules down and put a name against the reviewer role. An unnamed reviewer is an unreviewed process.

Over-automation is the failure where a business pushes exception work through a routine workflow because the workflow is available and the specialist is not. The output has the shape of the routine output and none of the judgment that made the routine output safe.

It is detectable, because the missing judgment has to surface somewhere: as a revision late in a project, or as a client asking about something nobody decided. Where that pattern follows a rollout, the classification is what is wrong, not the tool.

The second risk is quieter and slower. Exception work is where judgment is learned, so staff who only ever operate workflows are not standing where it is learned — and a bottleneck relieved that way is relieved by the workflow rather than by a second person who can do the exception work, because nothing in the arrangement is training one.

A queue can be a demand problem rather than a capacity problem. Where a client asks four times because the first answer was unclear, three of those four requests exist only because of the first answer, and producing each of them faster does not stop them being made.

Outsourcing moves the work and keeps the coordination cost, which is the part that does not move. Hiring works, and it is the right answer when the demand is genuinely expert work.

Weigh both before assuming the answer is a workflow. A queue made of expert requests does not respond to distribution at all.

Take the single highest-volume repeatable request in your recording. Note its arrival rate, its handling time and who handles it. Configure one workflow, name one reviewer, and run it long enough that the novelty wears off.

Measure the specialist minutes that request type consumes, the number of handoffs, and how many instances came back for rework. Do not measure images produced: that number counts output, not the specialist time a request consumed, so it cannot answer the question this pilot asks. The Business Value page lists specialist hours on routine requests among the measures to record before anything changes.

Decide at the end between the four outcomes the pilot page publishes — roll out, refine, pause, or no fit. Where the specialist minutes did not move, the classification was wrong, and the honest response is to redo it rather than to widen the rollout.