Cebu Pacific, the Philippine airline, says its legal team’s contract review now takes about 1.2 hours per pass, down from an average of 2.5.
That is not a dramatic number. It is roughly half, not a tenth. That modesty is the first reason to take it seriously.
The figure comes from an announcement, reported by TNGlobal on 16 September, of the airline’s rollout of ChatGPT Enterprise across legal, engineering and project intake. The deployment was delivered with Thinking Machines Data Science, OpenAI’s services partner in Asia Pacific. So three companies sit behind the story: the airline reporting results, the firm that sold the deployment, and the company that makes the product. That is worth holding in mind as we go.
The part that is not about the tool
The most useful sentence in the announcement is not a figure. The programme, it says, combined the product with “workflow redesign, governance and evaluation tailored to different business use cases.”
Two more details follow. The checks on each workflow were set according to its risk. And the business teams worked hands-on with the designers before anything was rolled out more widely.
Put those in order and you have a sequence most AI rollouts skip. Pick a workflow. Redesign it with the people who do it. Decide how much checking it needs, based on what goes wrong if it fails. Then roll it out.
The usual order is the reverse. Buy the licences, run a training session, and wait to see what people do. That produces individuals who are quicker at individual tasks, and very little change in how the department’s work gets done.
Harvard Business Review ran an argument along the same lines two days earlier. Masha Shunko of the University of Washington and Serguei Netessine of Wharton write that companies miss enterprise-wide returns because they automate individual tasks instead of redesigning the workflows that produce value. Their headline says it more bluntly: stop automating old processes, and design new ones instead.
The rest of the numbers
The airline reported three more figures.
Project intake and triage fell from five days to about one, with around 80 per cent less manual review effort. Engineering reference searches that took 10 to 15 minutes now take under 10 seconds. And 86 per cent of staff surveyed said AI supported more than a third of their daily work.
These figures are not equal. The intake figure is the most interesting, because five days to one is a change the people waiting on that process would notice. The search figure is the least surprising, because fast lookup is exactly what these tools do well. The 86 per cent comes with no survey size, method or date, so it is a sentiment rather than a finding.
Note also where the 80 per cent belongs. It is about intake, not legal. It would be easy to read it as a claim about contract review, and it is not one.
How to read a number like this
You are going to be shown figures like these, by suppliers, by consultants and sometimes by your own colleagues. This announcement is a good one to practise on, because it is more specific than most.
Four questions.
What was the baseline, and when was it measured? “An average of 2.5 hours” is only useful if you know which contracts and which period it covers.
What does “per pass” mean? If a contract goes through three passes, the saving per contract is larger. If the new process adds a pass, it may be smaller. The announcement does not say.
Who measured it? Here the answer is the airline and its deployment partner, jointly, in an announcement. That does not make the number wrong. It makes it unaudited.
What did it cost? Licence count, programme length and the hours the business teams spent on the redesign are all missing. Those hours are the real price of doing it properly, and they are the figure nobody publishes.
None of this is a reason to dismiss the result. It is the checklist that turns someone else’s success story into something you can plan with.
What transfers to a team that has not started
The useful thing about this case is that it starts where most departments already are. Legal review, intake, searching for reference material. Nothing exotic, and nothing that needs an engineering team.
So before buying anything, try the sequence on paper. Pick one workflow your team runs every week. Write down its steps as they actually happen, including the waiting. Mark which steps carry real risk if they go wrong and which do not. The risky ones need a person checking the output. The others may not.
Then, and only then, ask where a tool fits.
Choosing which workflow to start with matters as much as the method. The best first candidate is boring. It runs often, so a saving repeats. It has a clear finish line, so you can tell whether the new version is done. And a mistake in it is annoying rather than serious, so the checking can be light while people learn. Cebu Pacific’s engineering search fits all three, which may be why its figure is the most dramatic. Contract review fits the first two but not the third, which is why it needed checks set according to risk.
Avoid starting with the workflow that causes the most pain. It is tempting, because the case for change writes itself. But the most painful process is usually painful for reasons a tool cannot fix: unclear ownership, a missing decision, a handover nobody agreed. Redesigning it is worth doing. Doing it at the same time as introducing a new tool means you will not know which change made the difference.
The paper exercise costs an afternoon. It will tell you more about whether AI can help your team than any demonstration, because it starts from your work rather than from the product.
It also gives you a baseline of your own. If you do go ahead, you will be able to say what the process took before, measured by you, which is the one number in the Cebu Pacific announcement that nobody outside the company can check.
The airline’s number is roughly half. The part worth copying is the order it did things in.