The first draft is the most visible result of a copilot trial.

It appears on the screen, reads like finished work and is easy to demonstrate. A consultant who previously started with a blank page can now begin with a structured draft. The improvement feels immediate because everyone can see the output.

Reporting capacity is harder to see. It sits in everything that must happen before the consultancy is willing to deliver that report.

That distinction matters because a firm does not deliver drafts. It delivers reports that have reached its professional standard. Faster drafting increases capacity only when the rest of the reporting process can absorb more work without creating an equivalent demand somewhere else.

The copilot ceiling appears when assistance improves the visible task but leaves the delivery constraint in place.

Where copilots earn their place

There is a good reason copilots perform well in demonstrations.

A consultant can use one to organise notes, compare possible structures, explore an interpretation or test alternative wording. The interaction is flexible. If the first answer misses the point, the consultant can add context, change direction or discard it.

Experienced practitioners are often particularly effective users. They know which details matter. They can recognise a statement that sounds plausible but does not fit the case, and they know when a stronger or softer conclusion is justified.

For bounded work, that may be enough. The person using the tool owns the task, holds the relevant context and can verify the result without handing it to someone else. Research, early analysis and drafting all contain work of this kind.

A consultancy does not need to turn every useful interaction into a production system. When the work is unusual, low-volume or exploratory, the copilot does not have to prove that it can scale across the firm. Flexibility may be the point.

The difficulty begins when the demonstration is asked to prove something larger.

A strong first draft shows that one consultant can work productively with the tool. It does not show how the same approach behaves across different consultants, reports and periods of demand. It says even less about what happens after the draft enters the rest of the firm.

The stronger the operator, the more convincing the demonstration can look. That is also why the result needs to be interpreted carefully. The pilot may be showing the judgement of an experienced consultant expressed through a new interface. The firm still has to find out whether that judgement travels with the report.

What happens after the draft

Consider a hypothetical leadership assessment report.

A consultant uses a copilot to prepare the first draft. They know the client context, the purpose of the report and the reasoning behind the main interpretation. After making a few changes, they send it to a practice lead.

The draft is fluent and well structured. Nothing is obviously broken. During review, however, the practice lead reaches a paragraph that describes a development risk more strongly than expected.

The sentence could reflect a deliberate professional judgement. It could also be an overstatement introduced during drafting. The finished paragraph does not reveal which one happened.

The practice lead returns the report with a question. The consultant is now in client meetings, so the report waits. When the answer arrives, the consultant explains that the risk was meant to be conditional on a particular situation. The wording is revised, and the report returns for another check.

The copilot may have shortened the time taken to produce the first draft. The report still needed a handoff, a clarification, a revision and a second decision before it was ready to deliver.

Those steps are ordinary parts of professional reporting. Consultancies already review work, resolve questions and apply judgement. The drafting demonstration left them outside the frame.

Because the paragraph is fluent, the practice lead cannot rely on surface quality to decide whether it is sound. A visibly rough paragraph is easy to challenge. This one requires the reviewer to reconstruct what the consultant intended, compare that intention with the wording and decide whether the report still reflects the case.

That is more than proofreading. It is another piece of professional work.

By then, the document has moved from the consultant to the practice lead, but the reasoning behind one sentence has stayed with its author. Until that reasoning catches up, the report cannot move forward.

Different firms will handle this in different ways. Some use professional review for every report. Others apply different checks according to the work. The capacity question turns on the actual route a report must complete before delivery.

Once that route is included, the relevant output changes. Reporting capacity is the number of reports the firm can bring to its deliverable standard, not the number of drafts it can generate.

When local speed reaches a shared bottleneck

One delayed report may look like a small coordination problem. Now imagine several consultants using the same copilot successfully. Each produces drafts sooner, and those drafts enter a smaller number of shared review, decision or production stages.

The drafting step has accelerated. The shared stages may still be working at the same pace.

If reports arrive faster than the next stage can process them, the queue grows. Reviewers switch between cases. Questions return to consultants who have already moved to other work. A report can spend less time being drafted and more time waiting for the context or authority needed to continue.

The queue is only the visible part of the bottleneck. When the practice lead's question is resolved by revising the sentence, the report can move on. If the reason for that revision remains in a comment, an inbox or someone's memory, the same issue can return in another report. Another reviewer then has to reconstruct a methodology decision that the first review had already settled.

The next report may not be resolved by reusing that decision. A standard paragraph may not fit the case. A familiar term may mean something different for a particular client. The available information may support more than one reasonable interpretation. These cases need somewhere to go and someone who can decide what happens next.

At low volume, experienced practitioners often absorb this work informally. They remember the earlier decision, explain the context in a quick conversation and move the report forward. The process appears to work because their tacit knowledge repairs it.

As more reports move through the firm, the same expertise can become a shared constraint. Exceptions accumulate around the people most trusted to resolve them. Reports wait for their attention, and routine decisions are reconstructed because no durable record tells the next person what to do.

Professional judgement remains important. The avoidable burden is asking senior people to rediscover the same judgement whenever a report changes hands.

A consultancy can make drafting faster and still make report delivery slower.

A custom system can preserve the same queues, unclear ownership and repeated decisions behind a more sophisticated interface. Technology changes capacity only when the work around it changes as well.

A consultant handling novel or low-volume work from beginning to end may benefit from assistance without creating a shared production problem. In that setting, the copilot may be the right design.

The ceiling matters when the firm's goal shifts from helping one practitioner to delivering more reports reliably across a team. At that point, the firm needs to know who owns the report after drafting, what information travels with it, where an exception waits and which decisions still depend on scarce attention. None of those answers is visible in the first draft.

Test delivery, not drafting

No general argument can determine whether a copilot has increased capacity in a particular consultancy. Its effect will vary with the route from drafting to delivery. Any claim about time, quality, productivity or total cost needs evidence from the process in which the tool is used.

A useful pilot therefore has to follow the report after generation.

Start with a representative mix of reports. The strongest demonstration is too narrow for a production test. Keep the firm's delivery standard unchanged, follow each report beyond the first draft and stop measuring only when it is ready to deliver.

Then ask:

• How many reports reached the existing delivery standard?
• How long did they wait between drafting and delivery?
• How often did they return for revision or missing context?
• Which decisions still required scarce senior attention?

A simple record may be enough. A timestamp can show where a report waited. A return reason can distinguish simple correction from repeated method reconstruction. A named decision owner can show whether exceptions have a route or merely find the same senior consultant each time.

The result may still support a copilot. If consultants complete bounded work more easily and the rest of the process absorbs it, task assistance can contribute to delivery. If the trial reveals a growing queue, the firm has learned something equally useful: the next problem is no longer drafting.

Count reports ready to deliver, not drafts produced. If review and rework rise with drafting output, the copilot has moved the bottleneck. It has not increased capacity.