Every board now asks the same question in different words. What does it cost to serve one customer, process one claim, resolve one ticket or run one AI-assisted interaction? The number usually exists, and it is usually wrong for one of three reasons.
A cost per unit taken from the cloud bill leaves out the largest cost, the people who built and run the service.
Someone built the model in a spreadsheet and it was right on the day. It has not been refreshed nor tied to actuals ever since.
Shared cost divided by headcount or revenue gives a figure nobody being charged will accept, because they did not cause it.
Business improvement is hard to judge. Total spend isn’t an indicator of efficiency. A cost per customer is something a board can act on.
True product and customer margins that include the technology cost. A product P&L without Tech included is wrong from the start.
A unit rate connected to the plan, so stakeholders can see what happens to margin when volume grows.
Cost per unit as the end point of the practice, calculated where the labor and the platform are and not only where the cloud bill is.
The denominator for every AI and modernization business case, such as cost per AI-assisted outcome against the human-assisted equivalent.
FinOps teams call it unit economics. Finance calls it cost to serve. Consultancies call it multi-dimensional profitability. It is the same allocated cost, read at a different dimension.
Five MagicOrange capabilities carry unit costing. Supported by a foundation of Data Studio, Analytics and AI Studio.
The engine. Direct attribution where the link is known, consumptive volume-based drivers where cost is shared and percentages only where nothing better exists. Cost anything, such as a product, a customer or a line of business.
Cloud and business unit economics, such as cost per transaction, customer or inference, calculated in the same model as everything else.
Service and application cost comprised of infrastructure, labor, licensing and cloud. The technology layer of the unit cost.
The labor in the number. Captured effort becomes allocated cost against the product or service the people built.
Future unit costs under different scenarios, such as cost per inference if the licensing changes or cost per claim if volume doubles.
Direct and volume-based allocation bases that are commercially accurate can be relied upon. Even spreads and arbitrary drivers like revenue or headcount cannot. Every cost moved from a weak driver to commercially consumption driven is a step towards greater trust and business buy in.
That split turns a unit cost from a reporting exercise into something people can govern. Buyers are accountable for the volume they consume and service / provider owners are responsible for the price their services are supplied at. The same logic applies to AI, where the rate is the price per token and the volume is consumption.
A unit cost built from only the cloud bill is a cloud unit cost. One built from all spend, with the labor, on-prem, cloud and the platform included, is a cost to serve, and is the source of truth for margin analysis.
Unit metrics are natively calculated from the allocation model, each rate generated at the dimensions the business manages by.
Broken down by service or subsidiary.
Sliced by product, line of business or segment.
Split by site, operation or brand.
Read by model, use case or agent.
Separated at any cost definition level, eg: with the labor and the platform as components.
The FinOps Framework names unit economics as the end point of a mature practice. In MOTEF, the economic model layer is where the unit cost is calculated.
