opinion
AI Is Helping. So Where Are the Time Savings?
AI is useful, but the working day still feels much the same. The next opportunity lies in the work people still have to do after the AI response.
Where Is the Time Still Going?
Look at what someone still has to do after the AI tool has helped them.
A search returns the right document. Someone opens it, reads through it, finds another document to compare it with and checks whether the instructions are current. The search was quicker. Much of the task remains.
That is one way an AI tool can be useful without saving as much time as expected. It has helped with a step in the process, while leaving the work around that step largely intact.
Our view is that the productivity test belongs at the level of the completed task. The useful measure is how much effort it takes to reach an acceptable result, including the work that follows the AI response.
Personal use can make the gap more noticeable. You have seen an assistant help you explore a question or work through a problem. At work, there is a much larger collection of company information, yet getting to a usable answer can still involve considerable effort.
The useful question is what happens between the AI response and the task being finished. That is where we would start looking for the next improvement.
What Would a Useful Answer Let Someone Do Next?
Describe what the person needs to be able to do with the answer, including the checks they would need before relying on it.
For a document assistant, finding a file and answering a question from its contents are different outcomes. An answer may also need to draw on several files, distinguish a current instruction from an older one, and show where the information came from.
Without those decisions, “make the chatbot more useful” leaves the development team guessing. It also leaves the business with little basis for judging whether the next version is better.
Start with one real task. Walk through how someone completes it today, including the reading, checking and hand-offs that happen after a search. Then describe the point you want them to reach with less effort.
That conversation does not require a technical specification. The people doing the work can explain where they lose time and what they need to trust an answer. A technical partner can help turn that into a proposed workflow.
The answer may involve a better use of existing tools, a process change or additional software. The brief should leave room to assess those options.
In AI Is Making Traditional Automation Faster and Cheaper, we examined how lower development effort can make more improvements worth building. Here, the question is where to look for the next improvement when AI is already helping. The work people still have to finish provides a starting point.
What Could Make the Next Step Impractical?
An approach can be technically achievable and still be too expensive to use at the required scale.
That was an important consideration in the document-assistant engagement below. Extracting document contents was relatively straightforward. The volume of material made the cost of processing it a more important question.
This is why discovery needs to examine the uncertain parts of the intended workflow. The hardest question is not always whether AI can produce the answer. It may be how much information needs processing each time, how often that information changes, or how much checking people would still need to do.
At Adaca, we map the intended user workflow, translate it into technical steps and identify which assumptions need investigation. Some call for a focused technical test. Others need a cost model or a decision about how the business operates.
The result should be a plan with enough detail to judge the next investment: what will be built, what remains uncertain, what drives the running costs and how the result will be tested.
What Did This Mean for a Document Assistant?
A high-volume manufacturing company in Australia wanted to move from finding documents to receiving useful answers from their contents.
In its existing workflow, the company used Copilot, supported by its managed service provider, to help find files in SharePoint. It had seen enough value to ask whether the experience could go further.
The volume of files, historical versions and access rules shaped the proposed solution. Reading the whole collection for every question was not a feasible cost model for this use case.
The approved design combined keyword and meaning-based retrieval to identify relevant material, with permission checks before answer composition, document-version checks and citations. It also included document cleanup, human review where needed and customer acceptance testing.
The business contributed its use cases, organisational structure and access rules, with its internal IT function and managed service provider involved. We translated those inputs into a technical plan and estimated initial ingestion and ongoing costs. The first stage covered a selected part of the environment.
The outcome at that point was an approved plan and authorisation to build. The time savings would need to be established through implementation and use.
What Should You Bring to That Conversation?
Bring the problem, the people who understand it and someone who can make the relevant business decisions.
You do not need to decide how documents should be indexed or which model should answer a question before asking for help. Those are technical decisions to work through during discovery.
The business contributes knowledge that an engineering team cannot infer from the files alone:
- Where the Effort Goes
The steps people perform, the checks they repeat and the points where they wait for someone else. - Which Information Counts
What the business treats as current or approved, and who resolves conflicting instructions. - Who Can See and Decide What
Access rules, approval responsibilities and the people who can settle unclear cases. - What a Useful Result Looks Like
The task someone should be able to complete and the evidence they need to rely on the output.
These inputs can be developed together. If the conversation exposes an unclear rule, discovery should identify the decision and who needs to make it.
This is the same division of responsibility behind Own Your Technology, Do Not Build a Tech Team. The business owns the direction and decisions. Its technical partner turns those inputs into an implementation brief.
How Will You Know It Has Been Worthwhile?
Compare the effort required to complete the whole task before and after the change, while checking that the result meets the agreed requirements.
Record the current work before development begins. Include the reading, verification and hand-offs that made the original AI response less useful than expected. Those steps belong in the comparison even if they happen outside the chat interface.
Agree what a good result must include. For a document assistant, that can mean the right source, the appropriate version, the correct access checks and enough detail for a person to verify the answer. In some circumstances, withholding information is the correct result.
The cost assessment should include preparing the information, processing changes and operating the service. Human review remains part of the work wherever it is required. A faster response alone cannot establish that the overall process takes less effort.
Start with the work people still have to do after AI has helped them. That gives the next discovery conversation a specific problem to solve, and a completed task against which to measure the benefit.
Lambros Photios is the founder of Adaca. This article draws on his account of Adaca’s discovery process and an engagement’s final approved technical scope.