The Parallel Path
A two-part series on AI, ownership, and the choices business owners can make now
Part Two: Build One Useful System Before You Build an AI Strategy
Consider a professional services firm preparing its monthly client reports. Information comes from several places, someone reconciles the differences, and another person turns the results into a narrative. By the time the report reaches the client, the team has spent hours assembling material it has assembled before. The process may be familiar and dependable, but it is worth asking how much of that effort still requires a person's attention.
This is where an AI discussion becomes useful. The firm has a defined piece of work, people who understand it, and a result it can inspect. It doesn't need to predict the condition of the economy in ten years to decide whether that process deserves attention. It needs to understand the current effort, the errors that occur, and the parts of the work that must remain under professional judgment.
The broader pressures described in debates about AI can make change feel overwhelming. For a business owner, a more manageable starting point is a recurring constraint: a report that takes too long, an intake process that loses information, or a backlog that keeps knowledgeable staff occupied with preparation. Improving one of those processes can create room to act. It also teaches the business more than another general discussion about what AI might eventually do.
Understand the work before choosing the tool
In the reporting example, the first step is to follow a report from beginning to end. Where does the information originate? Which figures require reconciliation, and which comments depend on knowledge that hasn't been written down? Often, the difficulty becomes clearer once the people doing the work explain the exceptions. A system designed around the tidy version of a process can fail as soon as an ordinary complication appears.
Some of the improvement may require no AI at all. A standard intake form, a reliable calculation, or a clearer assignment of responsibility may remove a substantial part of the delay. AI may then help prepare a narrative from checked information or identify items that need review. Choosing each tool for the task keeps the business from paying for complexity that adds little value.
Research offers a reason to test that approach without promising a universal result. In Generative AI at Work, Erik Brynjolfsson, Danielle Li, and Lindsey Raymond studied an AI assistant used by customer support agents. The study's updated summary reports an average increase of 15 percent in issues resolved per hour, with substantial differences across workers. Less experienced workers benefited more, while the most experienced workers saw small speed gains and small declines in quality. A result from customer support cannot predict the return on a reporting system, but it shows why both performance and quality deserve measurement.
Give the first system a clear boundary
A useful first implementation should be small enough to understand and important enough to matter. For the reporting firm, that might mean preparing draft reports for one service line using approved information, with a named person responsible for review. The system would have a defined place to stop when information is missing or inconsistent. Nobody should have to guess whether a polished paragraph reflects a checked fact or a plausible assumption.
This is what I mean by a parallel path: creating room to test an improvement alongside the existing process. The business can compare results before committing its entire operation to the change. Working alongside an established system still requires permission to use the information, appropriate access controls, and an accountable owner. A pilot that creates uncertainty about client data or decision rights has introduced another problem for the business to manage.
The comparison should include the full effort required to deliver an acceptable result. If drafting takes less time but review and correction take more, the apparent saving may disappear. Keep track of completion time, errors, rework, and whether the client receives something more useful. Staff experience matters too; a process that saves management time by creating confusing exceptions for everyone else is unlikely to hold up.
Decide in advance what would justify continuing. Perhaps the firm wants reports delivered sooner with no decline in accuracy, or less preparation time without increasing the review burden. The target should come from the business's actual needs. If the pilot doesn't meet it, the findings can still be valuable, provided someone uses them to revise or stop the work.
Keep enough control to change direction
A working system needs more than a successful demonstration. Someone has to maintain it when a source changes, an integration fails, or a supplier updates its service. The business should know where its information is stored, how the process works, and who can restore service when something goes wrong. Documentation earns its place when another competent person can use it to keep the operation running.
The ability to change suppliers deserves attention, although it doesn't require using several vendors from the outset. Adding alternatives too early can make a modest system expensive to maintain. Start by preserving usable copies of the business's data, documenting the rules, and understanding what would need to be rebuilt if a service became unavailable. Those are practical steps toward keeping a supplier relationship from becoming an obligation the business cannot escape.
The same reasoning applies to the commercial arrangement. Recurring fees can make sense when they pay for monitoring, maintenance, and ongoing improvement. They are harder to justify when the client cannot tell what continuing value is being provided. A provider should be able to explain the result it supports and the work required to sustain it, while the client should retain clear rights to its information and a workable route to transition.
For Hinson Consulting Group and CREVOX, the focus is the constrained process: what is holding up the work, what can reasonably be improved, and how the business will know whether the change helped. A useful engagement leaves the client with a system it understands and a result it can evaluate. That is a more durable basis for the relationship than asking the client to keep buying into a prediction.
There is no need to treat every delay as a failure of ambition. Some projects should wait because the information is poor, the process is unsettled, or the expected benefit is too small. But once a recurring problem is understood and a controlled test is feasible, postponement has a cost of its own. The staff continue doing the work, the customer continues experiencing the delay, and the business learns nothing about whether a better approach would hold up.
The next step can be quite ordinary: choose one recurring problem, assign someone who understands it, and establish what an acceptable improvement would look like. Give the test enough time to encounter real work, then examine the result honestly. A business that develops that habit gains something useful beyond any single application of AI: experience making changes it can explain, maintain, and build on.