A Snapshot of Our Work in AI Practice Building
What connects them
What these engagements have in common is not the technology.
In each case the client had a functioning technical capability and a gap in translating what it produced into terms the finance organization could act on. The AI element changed the vocabulary and made consumption harder to predict, and in several cases a meaningful portion of the cost never appeared in the billing data at all. The underlying work was recognizable from years of cloud engagements.
FinOps for AI is an extension of the FinOps practice rather than a separate discipline. A practice built around interpretation and cross-functional facilitation extends to AI without much rebuilding. One built primarily around cloud cost reporting does not.
A snapshot of the portfolio, and what each engagement involved.
Assessing AI-enabled FinOps tooling
Case Study 1
Assessing AI-enabled FinOps tooling
Industrielle Alliance
The business context. The organization was evaluating cloud management platforms. Several vendors were positioning AI capability as a differentiator, and there was internal pressure to purchase rather than build. The decision carried an annual subscription in the hundreds of thousands, in perpetuity, plus deployment cost.
The problem. Leadership could not tell whether the AI capability being marketed was substantive or presentational, and the FinOps team had no neutral basis on which to advise them.
What we did. We assessed the landscape and delivered a point-of-view document covering the maturity of AI features across the commercial platforms, the build-versus-buy trade-off framed on total cost of ownership rather than feature count, and where AI in FinOps is likely to become genuinely useful.
The finding. The landscape was moving quickly enough that a multi-year commitment to any one vendor's AI approach carried real lock-in risk. The organization was already extracting significant value from AI through query drafting and code generation against its existing stack. The recommendation was to build on native and off-the-shelf capability and revisit when agentic and predictive functionality matured beyond announcement.
Building unit economics that include AI spend
Case Study 2
Building unit economics that include AI spend
Trimble
The business context. More than thirty revenue-generating cloud-hosted products across multiple business units, several with AI components, and active decisions pending on new capabilities, AI-powered subscription tiers, pricing models, and monetization approaches.
The problem. Evaluating those opportunities was taking over six months each. Business units could not model what a decision in one unit would cost another, and could not run scenarios to challenge a proposal on financial terms.
What we did. We worked across several business units over six months, alongside engineering, product, and finance in each. The method was question-driven: identify the most important question a team could not answer, determine what was missing to answer it, build that, then move to the next question.
The unit metric frameworks covered cost per product, per named user, per user per sub-customer, per production state, and per incremental AI service within Bedrock, such as Claude and open-source models, linked to revenue.
What was built into the organization. The metrics were implemented in Domo, Trimble's existing cost platform, which required work on the ingestion pipeline and the relational backend behind it rather than delivering an external model. Costing data has a single source of truth in a system Trimble already owned and already knew how to operate.
What Trimble owned at the end. The metric definitions and the logic behind them, running in their own platform. The methodology for extending metrics to products outside the initial set. Named owners in each participating business unit who understood the constructs well enough to use them in a review without us present.
The outcome. Cloud project investment decisions fell from over six months to roughly one.
AI readiness and the FinOps operating model
Case Study 3
AI readiness and the FinOps operating model
A large financial services organization
The business context. A technically capable FinOps team with sound allocation and optimization work, inside an organization beginning to scale AI adoption.
The problem. The team could not articulate the value of its work to Finance and senior management, or explain the strategy behind it in terms the business recognized. Separately, AI spend was growing without governance, visibility, or traceability in place ahead of it.
What we did. We assessed the current FinOps capability, operating model, and AI readiness: the maturity of operational processes including AI agent adoption, the state of AI-enabled automation, AI governance readiness, and the capability gaps between current and future-state operating model.
The approach. Two problems addressed together. The cultural gap, where technical output was not translating into a financial narrative leadership could act on. And the control gap, where AI spend needed governance before it scaled, delivered through early wins rather than added workload on a stretched team.
Building a business case for AI deployment
Case Study 4
Building a business case for AI deployment
Gaming, anti-cheat detection
The business context. A ninety-day proof of concept on an AI-powered anti-cheat system had achieved strong detection accuracy and a significant reduction in false positives.
The problem. Leadership needed a financial assessment before committing to production, and the technical results did not answer the financial question.
What we did. Modelled full cost including the categories that generate no invoice, developed revenue scenarios with the commercial team, ran sensitivity analysis to identify break-even, and quantified downside exposure.
The finding. Returns were roughly twice as sensitive to churn improvement as to infrastructure cost, which moved the decision away from cost optimization and toward product and community validation. The recommendation was a conditional go, structured as a phased rollout with numeric gate criteria that capped downside exposure while preserving the full upside.