A faster AI-assisted task can be useful even when it does not tell you how long the whole process takes. Define each clock before reporting the result.
An AI pilot can make one task faster without making the whole decision equally fast. The useful question is: exactly which time was measured, and what happened to the work around it?
Google DeepMind's October 31 update on PlanAssist offers a concrete example. Google reports that, in early testing with Barnet, Camden and Dorset councils, the average time planning officers spent on householder assessment tasks fell by 58%. The tool helps assemble information and draft assessment reports; officers retain the final decision.
That is a promising reported task-level result. It is not, by itself, evidence that every application moves through the entire planning process 58% faster, or that another organization will see the same result. The announcement does not describe enough of the measurement method to settle those questions.
Define the clock before reporting the percentage
A document workflow usually has more than one clock. An employee may spend time gathering information, reviewing a draft and correcting it. The case itself may also wait in a queue, need missing material or pass through another review.
If you measure only drafting time, call it drafting time. If you measure hands-on work, state which activities are included. If you report elapsed time, define its start and end points. Those numbers answer different questions and should not be combined casually.
For example, suppose a team uses AI to prepare an internal account brief. Measure the time spent assembling and checking the brief, including any corrections. Separately, track the elapsed time from request to delivery. A faster first draft could help the person doing the work while the request still waits for information or review. That is a reason to investigate the next constraint, not a reason to dismiss the task improvement.
Measure review and quality alongside speed
A credible comparison needs a baseline and similar work on each side. Record the types and complexity of cases, the period measured and the number of cases. If the work changes during the pilot, say so. A small or unusual sample may be useful for learning without being a reliable forecast for a wider rollout.
For a document workflow, I would look at a few measures together:
- Hands-on time: time spent preparing, reviewing and correcting the document, with the boundaries defined in advance.
- Elapsed time: time from the agreed starting point to a completed, delivered result, including waiting.
- Review and rework: how often material needs correction or another pass, and how much effort that takes.
- Quality: whether the completed work meets the team's criteria, including checking important claims against their sources.
- Exceptions: cases excluded from the comparison or requiring a different process, with the reason recorded.
Avoid treating an unchanged draft as proof that it is accurate. Review whether the evidence actually supports the important statements, using an appropriate sample and criteria for the work. Record problems without putting unnecessary personal or confidential information in the measurement log.
Use the next phase to test what travels
Google says twelve more councils are joining a 12-month beta, bringing the total involved to fifteen. Its announcement says wider availability across England in 2027 depends on successful testing. The UK government's October 30 announcement also says officers remain responsible for reviewing applications and making decisions.
The next useful evidence is whether the results hold across different cases and organizations, what review and correction require, and whether improvements in task time show up in the broader experience. Those are questions to test, not results to assume.
The practical takeaway for any team evaluating an AI document workflow is simple: label the clock, compare like with like, and check the finished work. A precise task-level saving is more useful than a bigger number that nobody can explain.