How to track AI margin by customer and feature

A team crossing a wide office lit by a single warm glow

The measure ai margin by customer shows whether revenue covers AI use for each customer and feature. To judge it, join model-provider usage to revenue, preserve lineage for each cost, then review negative-margin customers alongside the proposed fix.

What does AI margin by customer need to include?

A company-wide AI cost total cannot answer whether a particular customer is profitable. It combines usage from different customers and features, then compares that total with revenue that may not cover the same work. The result can look acceptable while an individual account costs more to serve than it earns.

For ai margin by customer, bring together model-provider usage records and the revenue records you want to analyze. Each record needs a reliable way to associate it with a customer and a feature. If either side lacks that detail, keep the gap visible instead of treating the total as a complete answer.

Both dimensions matter. Customer-level results show which accounts need review; feature-level results help locate where usage and revenue differ. A customer total can hide a costly feature, while a feature total can hide an account with unusual usage.

Cost lineage matters because a margin result is only as useful as its trace back to inputs. A reviewer should be able to follow a cost to its source record and understand what revenue it was compared with. Brainis joins model-provider usage and revenue into per-customer, per-feature margin, with lineage for every cent and negative-margin customers flagged with a proposed fix. The Cortex product page and AI finance overview describe that work.

How do you join AI usage to revenue?

Start by defining the records and period you want to examine. On the usage side, gather model-provider records that show the costs being analyzed. On the revenue side, identify the customer revenue records that correspond to the same period and work. A total from one period should not be compared with usage from another without making that difference clear.

Next, match both sets of records to the same customer and feature. Use consistent identifiers where possible, and document how you handle records that do not match cleanly. A name that looks similar is not enough evidence that two records refer to the same account or feature.

Keep unmatched or unclear records visible for review. If you silently drop them, the joined result may omit costs or revenue and give a misleading margin. Record how many items remain unresolved only when the source records support that count; otherwise, describe the issue without guessing.

Retain the path from each result to its usage and revenue inputs. That lets someone review the match, spot a wrong attribution, and correct the analysis without rebuilding it from memory. For more checks before relying on an analysis, see the AI analysis checklist.

Example: A fictional small scheduling company reviews a calendar feature for one customer. Its records show $18 of model-provider usage and $30 of related revenue for the same period, while a second feature has $42 of usage and $25 of revenue. The company keeps both feature records and their sources visible, then checks whether the revenue was assigned to the right customer before treating either margin as settled.

A person looking out over a city at night from an office window

How should you read a customer and feature margin?

Read the result at both levels. Start with a customer’s overall margin, then inspect the features that contribute to it. A positive customer result does not prove that every feature earns more than it costs. A negative feature result does not, by itself, explain the customer’s full relationship.

Follow cost lineage before treating an apparent negative margin as settled. Check that the usage belongs to the customer and feature shown, that the revenue comparison covers the same work, and that the records cover compatible periods. If any of those links are uncertain, the result is a reason to investigate, not a final explanation.

A traceable result answers where its inputs came from. It does not necessarily answer why the margin occurred. High usage might reflect a real service need, a temporary workload, or an attribution problem. The records can help distinguish these possibilities only if they contain evidence that bears on them.

Treat a flagged negative margin and its proposed fix as a prompt for review. Ask which source records support the finding, what change the fix suggests, and what result would indicate that the change helped. The acquisition channel profitability guide offers another example of reading results at a useful level of detail.

What might a negative margin reveal?

A combined result can hide differences across customers and features. If one account uses a costly feature heavily, its negative margin may disappear inside revenue from other accounts. If a feature is expensive for only one customer, an overall feature total may hide that account’s situation.

The useful question is not whether a negative number looks alarming. It is whether you can trace it to the usage and revenue records that produced it. Then separate what the records establish from what still needs checking. The result may point to an attribution error, a pricing question, or a service pattern, but the margin alone does not prove which explanation is right.

Example: A fictional tutoring company reviews two features for one customer. The lesson-planning feature has $24 in usage against $20 in revenue, while the practice feature has $6 in usage against $30 in revenue. The combined result is positive, but the lesson-planning feature appears negative. The team follows the usage records to confirm they belong to that feature, then checks the revenue allocation. It considers a proposed limit on lesson-planning usage, but does not assume the limit will improve margin until later records show what changed.

A proposed fix should be judged against the evidence behind the finding. If the records point to misallocated revenue, changing usage may address the wrong problem. If usage is correctly attributed, a change to the feature or its pricing may be worth considering. Keep the reason for the choice alongside what you expect to observe afterward.

A modern office team using technology in a dark, open space

What should you do with the margin findings next?

Choose a defined set of customers and features to review. Set the scope before joining records so the result answers a clear question. Keep the time period and any known gaps visible, and avoid extending the finding to customers or features outside that scope.

Join usage and revenue records at the customer and feature level, then retain the lineage behind each result. Review unmatched records instead of hiding them. For every negative-margin finding, inspect the source inputs and the proposed fix before deciding whether to act.

Write down the change you choose, the reason for it, and what evidence would show whether it helped. That makes the next review a check against an expectation rather than a fresh argument from memory. If the records do not show a change, do not claim that the fix worked.

You can begin with the records and review process you already have. The company state page describes how Brainis maintains a live model of company state with sources, freshness, and confidence. Keep the scope narrow, trace the result, and make the next decision from what the records support.