We measure one portfolio-company workflow, compare AI with simpler options, and specify a pilot you can test before funding a wider rollout.
We follow one recurring task with the company team and measure the time and corrections it takes today. We then compare ways to improve it, including changes to existing software. The findings explain which option we recommend, what it would cost to implement, and what still needs to be checked.
We document the trigger, steps, systems, handoffs, exceptions, and final decision. We measure task volume, active handling time, elapsed time, rework, and reviewer effort on real examples, and record the period and sample limits so a later comparison is fair.
We review existing licenses, integration options, data rights, and the cost of changing the process. We compare a vendor feature or ordinary automation with an AI approach, and name the missing prerequisites and the evidence that would change our recommendation.
The pilot covers one company, one workflow, and a named group of users. The specification sets inputs, allowed actions, validation rules, review thresholds, acceptance cases, operating costs, and a path. It is kept separate from any later rollout to other companies.
We put the remaining work in order: access, data repair, application changes, testing, training, and handover, each with an owner and dependencies. The backlog shows what you can approve now and which decisions wait on further discovery.
We review a recently completed task with the person who did it and inspect approved sample inputs. We compare the documented process with the workarounds staff actually use. An interview with the sponsor alone cannot establish the baseline.
Before recommending a build, we test the riskiest part: source access, a representative integration, or a difficult document. A demonstration that works once does not show that the permissions, quality, and support needed for everyday use are in place.
We review the findings with the company owner and sponsor, who decide whether to build, configure, fix prerequisites first, or stop. If a build follows, the accepted specification and test cases define what it must deliver.
Illustrative workflow, not a client result. A services platform wants to reduce the time between receiving an invoice and resolving a mismatch.
We sample a representative period, including invoices that already go through cleanly. We separate hands-on time from days spent waiting for an approver, and record each invoice’s type and exception reason. Comparing easy pilot cases with all past invoices would overstate the improvement.
The prototype fills in the required fields and suggests a match against approved vendor and purchase records. Duplicate checks and financial calculations use fixed rules, not an AI model. Mismatches and uncertain fields go to a reviewer, and the software cannot pay an invoice on its own.
The pilot passes only if it keeps source references and access controls, handles representative exceptions, and reduces combined operator and reviewer effort. We weigh the observed change against build and running costs. Freed-up staff time becomes a cash saving only if the company has a credible plan to change its spending.
A sponsor can set priorities, but each portfolio company needs its own business owner, technical owner, and reviewer. Before release, we agree who holds code and deployment access and who handles integration upkeep, model changes, incidents, and support. Reusing a pattern in another company does not give either company access to the other’s data.
No. A shared set of intake questions helps compare opportunities, but companies differ in volume, system access, staff capacity, and priorities. We start where a company has an owner and a problem we can observe.
Yes. We can take on a focused build, work with the company’s engineering team, or hand over the specification for someone else to build. Commissioning an assessment does not commit you to a build.
As one focused piece of the plan. The assessment settles one operational dependency and defines a realistic first release, with access and staff time agreed. Deal deadlines do not remove the need to check data rights, integrations, and acceptance criteria.
Yes, for most of it. Discovery, workflow reviews, software delivery, and acceptance testing can run through remote sessions and controlled access to your environment. Watching the work in person or meeting a security requirement may need an on-site visit. We agree on participants, access, time zones, and any visits during scoping.