Why do so many organisations struggle to turn enterprise AI adoption into financial impact and what are the few that succeed doing differently?
The latest evidence shows that adoption is no longer the main hurdle. McKinsey’s 2026 State of AI survey found that nearly nine in ten organisations now use AI regularly in at least one business function. Yet only 37% reported a positive impact on earnings before interest and taxes, while just 6% qualified as AI high performers. The gap is increasingly between using AI and redesigning the business around it.
The problem, increasingly, isn’t access to AI. Almost any company can experiment with powerful models today. The harder part is stitching AI into the messy reality of an operating business, its existing systems, data, workflows and people in a way that actually produces results.
Some companies are beginning to crack that problem.
The Independent spoke with TriSeed, an enterprise AI and data engineering company and certified member of Anthropic’s Claude Partner Network, about what it takes to move AI beyond the pilot stage and into the everyday operations of a business.
With its technology centre in the Philippines, TriSeed has built capabilities around Claude implementation, data engineering and enterprise workflow automation. Its engineers work directly with businesses to connect fragmented systems and turn the data already sitting inside an organisation into infrastructure that AI can actually use.
One recent engagement with a multi-brand restaurant group offers an interesting look at how that works in practice — and some useful lessons for any enterprise embarking on its own AI transformation.
What It Really Takes to Make Enterprise AI Work
Three weeks into the build, a source file arrived with its columns in a different order than the week before. Nothing upstream had changed. Same system, same export button, same person running it every morning. Only the shape of the file had drifted, the way a file drifts when a process depends on someone repeating the same manual steps by hand, day after day. That file was the moment the design changed.
The client was a multi-brand restaurant group. Like many multi-site operators, it ran its business across several systems that had never been built to talk to each other: an enterprise resource planning platform for finance, a point-of-sale system for each brand, a human resources system, and a handful of operational tools besides. None of them offered a direct connection, an interface, or a warehouse feed. To get anything out, someone had to log into each system in turn and run a manual export every day, across every brand.
The cost of that was not only the hours spent extracting files before anyone could look at them. Operations, finance and the brand teams each built their own consolidation from the same exports, so the same measure could read differently depending on who calculated it. Reports arrived describing a period that had already closed. And because every file was produced and combined by hand, its structure was never guaranteed to hold from one day to the next.
Where the design changed
That drifting file is what led the team to add a layer that a standard data architecture does not call for. The usual approach, landing raw data, cleaning it, then modelling it for reporting, assumes the source is a reliable feed. This source was a spreadsheet, produced by hand, from a system that could not be queried directly, and it would keep changing shape without warning.
So file standardisation became its own layer, sitting before the raw data ever lands. Every structural inconsistency is absorbed there. Everything downstream works against a single, predictable format. It is not a dramatic decision. It is the one that keeps the platform stable in production: when a source format changes again, which it will, one layer changes, not the whole pipeline.
Forward Deployed Engineers from TriSeed, certified on Claude and embedded with the client’s operations and finance teams for the length of the build, made that call from inside the client’s own process, not from a specification document. The detail that mattered, that this particular export drifted in this particular way, was never written down anywhere. It came from watching the file arrive.
TriSeed is a certified member of Anthropic’s Claude Partner Network, and is also a partner of Databricks, Snowflake, Oracle Cloud, and n8n, giving the company end-to-end capability across data infrastructure, workflow automation, and intelligent applications. That stack is what let a small embedded engineering team cover ground that would ordinarily need many more people and much more time.
What Claude did inside the build
The platform runs on Databricks, with Claude used throughout the build rather than brought in afterwards to speed up a delivery in difficulty. Every table needs a notebook at each layer, and every notebook needs a schema, merge keys and validation logic. The shape of that work repeats. The business rules inside it do not. Given a sample of the source and an existing pipeline as the pattern, Claude produced the full set for review, cutting the build time for a new pipeline by roughly 85 to 90 per cent, from multiple days down to a matter of hours.
That change is what let the platform grow from around twenty pipelines to more than one hundred, a nearly fivefold increase, covering seven source areas (point of sale, finance, workforce, operations, forecasting, reference data and maintenance) without adding a single person to the team. Claude was also set to work parsing source files that would not behave, header rows in different places, inconsistent date formats, drafting the long analytical SQL behind the group’s core metrics, writing documentation as the pipelines were built rather than afterwards, and turning job failure logs into a diagnosis in minutes rather than the better part of an hour.
One further change reduced friction on the client side directly: error messages were rewritten for the people who actually see them. Instead of a technical trace, an operational team now reads what went wrong and what to do about it. Escalations to the engineering team dropped noticeably.
Architecture, data modelling and the definition of each business measure stayed with the engineers throughout. Claude produced within patterns the engineers set, and every generated component was reviewed and reconciled against source figures before it reached production, under the same deployment process that governs any other change.
What the business can now see
The group now measures every outlet the same way: net sales after discount, guest count, average spend per guest, seat utilisation, and organic growth compared like for like against the same day the year before. Average spend and seat utilisation are the two levers that move revenue at outlet level, and neither could be managed with any confidence while every brand calculated them differently.
Forecast and actual sales, previously recorded against different identifiers and impossible to line up without manual reconciliation, can now be compared directly, which feeds two decisions with a direct cost attached: staffing against expected demand, and inventory planning to reduce waste. Margin, previously invisible because sales data and cost data lived in separate systems, is now visible by product, by outlet and by channel, so that pricing and promotion decisions can be pointed at profit rather than at volume. Dine-in, takeaway and delivery are reported separately, because delivery carries a different margin profile and blending the three would hide whether that channel is actually contributing.
Taken together, the reconciliation work that used to consume a meaningful share of finance and operations time each week, chasing down mismatched figures across brands before anyone could act on them, has been largely absorbed into the platform itself. Teams that once spent hours a week just agreeing on a number now spend that time deciding what to do about it.
Where this applies beyond one restaurant group
None of this is specific to hospitality. The pattern- several systems that were never built to talk to each other, no practical way to query them directly, and reporting held together by manual exports- is common wherever a business operates across multiple sites, brands or subsidiaries. It shows up in retail, logistics, healthcare groups and professional service networks in equal measure. Restricted or indirect access to source systems, often treated as a blocker, is a design constraint TriSeed builds around rather than waits on.
The revenue was never missing. It was just split across systems that had never been asked to agree with each other.
Organisations evaluating enterprise AI can book a consultation at triseed.co, specifying which product or problem is under review.
About TriSeed
TriSeed Inc. is an enterprise AI and data company built around a data engineering-first, AI-second, cloud-third approach, headquartered in Chicago, Illinois, with a technology centre in the Philippines. It is a certified member of Anthropic’s Claude Partner Network and a partner of Databricks, Snowflake, Oracle Cloud, and n8n. Its product suite includes Earnest, AxisFleet, Foley, NEOSERVE and Zentra, serving accounting and advisory firms, fleet operators, HR teams and enterprise developers across Asia-Pacific. Learn more at triseed.co.
Follow Google News
Join us on WhatsApp
Follow us on Telegram