Choose the object from the action the reader can take
A denominator is useful when it matches the thing being priced, accepted, improved or stopped. Use a job when scope and delivery resources are committed per project. Use an order when fulfilment and transaction events repeat per checkout. Use a customer when acquisition, support, returns or payment behaviour accumulate across that relationship.
| Decision question | Primary object | Required bridge before comparison |
|---|---|---|
| Should this scoped project be quoted or repeated? | Job or project | Tasks, labour, materials and job-specific overhead |
| Does this sales channel retain enough per transaction? | Order | Orders per customer and channel-specific fulfilment/fees |
| Is this relationship costly to acquire and serve? | Customer or cohort | Orders, support events, returns and relationship period |
| How should one shared pool be recovered? | The object that consumes the pool driver | Activity count and reconciliation to the pool |
Choose and validate a decision denominator
Prerequisites, sequence and checkpoints
- Name the decision and the pool being explained. (not complete)
- Choose job, order, customer or another object that matches the decision. (not complete)
- Define the count, period and inclusion rules before division. (not complete)
- Allocate shared cost explicitly and reconcile object rows to the pool. (not complete)
- Test zero and low counts, then hand the basis to the object-specific planner. (not complete)
See why unlike denominators are not interchangeable
| Object | Count and arithmetic | Use |
|---|---|---|
| Job | 12 jobs; 12,000 ÷ 12 = 1,000 CU/job | Quote or job review |
| Order | 400 orders; 12,000 ÷ 400 = 30 CU/order | Order contribution |
| Customer | 80 active customers; 12,000 ÷ 80 = 150 CU/customer | Customer economics |
Restate before comparing
Reproducible user scenario
The three results describe the same pool through different objects; their magnitudes cannot be ranked directly.
| Step | Input or arithmetic | Decision meaning |
|---|---|---|
| Pool reconciliation | 12 × 1,000 = 400 × 30 = 80 × 150 = 12,000 CU | All views reconcile |
| Non-comparability | 1,000/job versus 30/order | Different objects; no higher-cost conclusion |
| Zero-count case | Pool 12,000; object count 0 | Division is undefined; change horizon or decision basis |
Restate the figures before choosing an action
The example’s 1,000 CU per job, 30 CU per order and 150 CU per customer all reconcile to the same 12,000 CU pool. None is larger or smaller in an economic sense because the objects differ. To connect them, record how many orders belong to a job or customer and how the relevant costs move through that relationship.
Check denominator drift
- Stable numerator, falling count: investigate unused capacity or a temporary volume trough before repricing every object. (not complete)
- Growing numerator, stable count: separate unit-rate, usage and scope changes. (not complete)
- Growing count, falling average: confirm the total pool and service quality did not increase elsewhere. (not complete)
- Zero or tiny count: extend the horizon, use a capacity denominator or keep the pool unallocated; do not divide by an arbitrary one. (not complete)
Limitations, evidence and next action
Use the calculation owner for the next step
- Job Costing & Margin Planner
Compare quoted and actual job economics and identify overruns
- Ecommerce Order Profitability Planner
Test order contribution after the full fee stack
- Customer Profitability Diagnostic
Diagnose customer profitability after service costs
Questions and boundaries
- Which denominator is best?
- The one that matches the named decision and can be defined consistently; there is no universal denominator.
- Can per-order cost be compared with per-customer cost?
- Only after both are restated through a common volume and period bridge.
Sources and scope
- Cost drivers — OpenStax: Supports cost-pool and driver selection; allocation is not proof of causation.