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.

Six people and their equipment do that work: two on the pick face, three drivers with their vehicles, and one person covering customer service and account management. Supervision, racking, vehicle leases and warehouse space sit inside these three cost pools, because what you want at the end is a fully loaded cost for every minute of front-line capacity.

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.

CaP counts a full resource-year at 110,000 theoretical minutes. Two pickers give 220,000, three drivers give 330,000, and one service and account manager gives 110,000. Apply the 85% rule to each.

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.

The service intensity ladder. CaP tags every account light, standard or heavy, and each tag maps to a fixed number of minutes per month:

• light 180 minutes a month: an account that orders and rarely calls.
• standard 600 minutes a month.
• heavy 1,200 minutes a month: weekly reviews, promotions, claims.

One more convention keeps the model readable: CaP makes one delivery drop per order, so order counts and drop counts are the same number.

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.

Before the costs, here are the driver volumes the equations run on. Every figure in the next table comes from these seven columns and the three rates, so you can reproduce any line of it with a calculator.

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

Read the last column as the pool less what the accounts absorbed. Warehouse supplies 160,000 EUR of capacity, the ten accounts absorbed 132,622 of it, and 27,378 stayed on the shelf. The assigned column adds up to 364,989, which is the cost to serve total in the table above.

Now the model closes. Gross profit of 966,200, less the 364,989 of resource the ten accounts actually used, leaves 601,211. Take off the 87,511 of unused capacity and CaP's operating profit is 513,700, or 11.4% of revenue. Used plus unused is 452,500, which is the cost base from Step 1 to the euro. A TDABC model that cannot close this loop is not finished, and the gap is usually the most interesting number on the page, because it is capacity you are paying for and nobody is buying.

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 617,974 after the eighth account (Online pure-play G), then the loss-making tail (Small accounts I and New account J) drags it back down to the reported EUR 601,211. The tail destroys EUR 16,763 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 close to 20% net). It would steer sales and marketing toward that profile and away from chasing revenue that arrives with a negative tail.