How to build a TDABC model: a 7-step guide

Start by grouping the resources that do the work into a small number of resource groups (sometimes called resource pools). A resource group is a set of people and assets that share roughly the same capacity cost and perform a coherent set of tasks. Keep the number small. Three to a dozen is normal; hundreds is a warning sign.

Pull the total annual cost of each group from your ledger. Include the fully loaded cost: salaries, on-costs, supervision, the equipment and space those people use, depreciation and a fair share of support. The goal is that the sum of your resource groups equals the operating cost you are trying to explain.

CaP is a mid-size B2B distributor with revenue of EUR 4,500,000 across 10 client accounts. Its cost to serve those clients is organised into three resource groups.

This is the step most people get wrong, and getting it right is the heart of TDABC. You must divide cost not by the time people theoretically could work, but by the time they can practically deliver useful work.

A full-time employee is paid for, say, 8 hours a day, but nobody picks orders or drives for 8 productive hours. There are breaks, training, meetings, set-up, cleaning, arrivals and departures. Kaplan and Anderson recommend taking practical capacity at roughly 80% to 85% of theoretical capacity for people, and around 85% for equipment, to leave realistic room for downtime and maintenance.

CaP uses practical capacity = 85% of theoretical.

Why not 100%? Because if you divide cost by theoretical capacity you will understate the true cost of every minute, and the "missing" cost vanishes. Dividing by practical capacity does something powerful: any capacity you supply but do not use shows up explicitly as the cost of unused capacity. That number is a management signal, not a cost to be smeared across customers. This single discipline is what separates a credible TDABC model from a misleading one.

Now the first of the two parameters falls out with one division:

This gives you the cost of a single minute of available capacity.

The second parameter is the time equation: a formula that predicts how many minutes a transaction consumes from a given resource group, as a function of the transaction's characteristics. This is where TDABC absorbs real-world complexity. Instead of forcing every order into one average, you add a term for each thing that genuinely drives time, including conditional terms that only fire when a special condition is present (a return, a hazardous item, a manual order, a fragile drop).

CaP uses three time equations.

Warehouse pick time (minutes per order)

Pick time = 4 + (1.5 x order lines) + (6 x return lines)

• 4 minutes is the fixed set-up to handle any order: retrieve, stage, confirm.
• 1.5 minutes is added for every order line picked.
• 6 minutes is a conditional term: it only adds time when a line is a return, which is far more labour-intensive than a normal pick.

Delivery time (minutes per drop)

Drop time = travel minutes + 1.5 + (0.33 x cases)

• travel minutes is the route time to reach the customer (from the routing system).
• 1.5 minutes is the fixed park-and-unload time at every drop.
• 0.33 minutes is added per case delivered.

Account management time (minutes per customer per year)

Account time = monthly minutes by service intensity x 12

• Each customer is tagged with a service intensity (light, standard, heavy) that maps to a number of minutes per month; multiply by 12 for the annual figure.

The logic to remember: fixed terms capture the cost of simply showing up; variable terms capture volume; conditional terms capture the expensive exceptions that averages hide. Kaplan and Anderson stress that this is what lets one equation cover thousands of varied transactions without a separate cost pool for each.

Now you run the engine. For every transaction, the time equations produce minutes; multiply each block of minutes by its capacity cost rate; sum across all of a customer's orders, deliveries and service touches; and you have that customer's cost to serve.

Worked detail for one customer, Online pure-play G, shows how a small account can quietly destroy value:

Online pure-play G generates a gross profit of only EUR 46,800 (revenue EUR 260,000 at 18% gross margin), but its cost to serve is EUR 43,312. That leaves a net profit of just EUR 3,488, a 1.3% net margin. The driver is structural: 1,400 tiny orders a year, 320 return lines, and only 6 cases per delivery drop. The customer looks fine on gross margin and is almost worthless on net. Only TDABC surfaces that.

Run the same engine over all 10 accounts and the full picture emerges:

Rank the customers from most to least profitable, then plot the cumulative net profit. The line climbs steeply through the good accounts, flattens as the marginal ones add little, peaks, and then bends downward as the loss-makers eat into the total. The shape resembles a whale surfacing, which is why it is called a whale curve.

Cumulative profit peaks at EUR 753,137 after the eighth account (Independent F), then the loss-making tail (Small accounts I and New account J) drags it back down to the reported EUR 736,929. The tail destroys EUR 16,208 of profit that the rest of the business has already earned.

Note what this means commercially: 2 of 10 accounts are loss-making (20% of the customer base), they represent only about 4% of revenue, yet they actively destroy value. This is the pattern Kaplan documented again and again: a small group of customers can quietly erase a large slice of profit, and it is invisible at gross-margin level because every one of these accounts shows a positive gross margin.

A model that only describes is half a model. The point of TDABC is to change decisions. There are three levers, and the right move is usually a blend of all three rather than firing customers.

Lever 1 - Reprice the tail. The loss-makers (Small accounts I, New account J) and the near-zero accounts (Independent F, Convenience E, Online pure-play G) are loss-making because of how they buy, not whether they should be served. CaP would introduce a small-order surcharge, a minimum order value, or a delivery charge below a case threshold, so that price reflects the cost driven.

Lever 2 - Reduce the cost to serve. Many of those costs are self-inflicted by ordering patterns. CaP would consolidate Online pure-play G's 1,400 tiny orders into fewer, fuller drops, move it to a lower-cost delivery slot, and tackle the 320 return lines at source (better product data, fewer wrong picks). Each minute removed flows straight back to net profit at the capacity cost rate.

Lever 3 - Re-mix. CaP knows precisely what a profitable account looks like (Wholesaler C and Contract H, both above 22% net). It would steer sales and marketing toward that profile and away from chasing revenue that arrives with a negative tail.