Margin comes from hours removed

Go back to Serai's two big fee lines from session 1. Retainers: 48 brands at $6,000 a month, $864,000 a quarter. GMV share: 2 percent of $45 million, $900,000 a quarter. Nearly half of Serai's money does not move when a brand sells more, and the half that does moves by $2 on every extra $100. Meanwhile the whole cost base is people: the content studio, the service desk, the store operators, the ad buyers. Every hour on the rota costs Serai about $18 loaded (constructed), and every hour that a machine takes over is $18 that stays in the bucket.

Now put a data use case on each route. A pricing model that lifts a brand's GMV by two percent is a fine thing for the brand. On Serai's fee split, two percent of $100 is $2 of GMV, and Serai's share of that is four cents. A content engine that drafts listing copy in five languages does nothing for anyone's GMV directly, but if it removes 420 of the studio's 1,200 hours a week, that is $7,560 a week that stops leaving. The routes are not close, and the reason is structural: Serai is paid mostly for effort, so the lever that pays Serai is effort.

This is why an enabler's data roadmap should not start where most data roadmaps start. Forecasting, pricing and the single customer view are the first three slides in almost every vendor deck, because they were built for businesses that own the goods or the buyer. An enabler owns neither. Its first slide should be the rota.

The general form of tonight's argument is one line in the ship playbook: which use cases pay depends on how the business makes its money. Session 5 of that course, The revenue model decides, walks it across several revenue models; tonight applies it to exactly one, the fee-plus-share model of an enabler. Read that session for the frame, then come back here for the arithmetic.

Be straight about what kind of statement the rule is. It is a working heuristic: a rule practitioners find useful and can explain, not a finding from a study, and it is uncited in the playbook for that reason. Nothing tonight upgrades it. What the bench in Part 2 adds is a model in which the rule can be watched working and, more usefully, watched failing. A heuristic you can break on purpose is worth more than a law you have to take on trust.

Hours removed is a rate, in hours a week: the people on a task, times the hours a week each spends on it, times the share of that work a machine can take over. For Serai's content studio, 40 people x 30 hours x 0.35 automatable = 420 hours a week. Multiply by the loaded hour and subtract what the tool costs to run and you have the value of the use case in dollars a week. Every figure in that chain is an assumption you can argue about, which is the point of writing it down.

What it does not mean is headcount cut. An enabler that removes 420 hours from the studio and dismisses 14 people has turned a scaling advantage into a one-off saving and a morale problem. The margin case is that the same 40 people now carry more brands: the next twelve brands need almost no new content hours, so retainers grow and the drain does not. Hours removed is capacity for more brands at the same cost, and it compounds; a redundancy does not.

The honest caveat: the automatable share is where every sizing lies to its author. Thirty-five percent of a content studio's week is a defensible number for repetitive listing copy, resizing and cutdowns; it is not a defensible number for creative direction or brand negotiation. In the build-along you will estimate that share for your own teams, and the instruction is to be mean with it.

Pricing optimisation is the use case with the largest number on the page and the smallest bar. At the defaults it lifts brand GMV by 2 percent, which on $45 million a quarter is $69,230.77 a week of extra sales for the brands. Serai's 2 percent share of that is $1,384.62. Add the six hours a week it removes from three pricing analysts ($108 at $18 an hour), subtract $500 a week to run the model, and Serai nets $992.62 a week. Ninety-eight cents in every dollar of the uplift is the brand's.

None of that makes pricing a bad product. It makes it a product for the brand, and a brand should pay for it. The moment there is a payer, an attach fee for pricing moves its bar up like any other line in the block. Without one, an enabler that builds pricing first with its own money has spent fourteen build weeks lifting somebody else's GMV. That is the whole of the anti-lever, and it is why the four roadmap orders below end the way they do.

The bench runs the same ten use cases in four orders, one build squad at $9,000 a week, eight quarters, and prints the net to Serai. The single customer view is blocked in every order, because the identity gate in session 4 does not clear a customer grain; the bench builds it and it returns nothing.

Read the two ends first. Pricing first adds the most GMV of any order, $7,310,769, and returns $511,972 less to Serai than hours first, paying back two quarters later. It pays the brand. Single customer view first spends sixteen build weeks on a use case the gate blocks and ends lowest of the four.

Now read the two at the top, carefully. Hours first and brand intelligence first land within 3.2 percent of each other, $43,451 apart. That gap is made entirely of attach revenue the assumptions block stipulates: how much a brand would pay for a SKU view or a creator scorecard is a number somebody typed, not a number anybody measured. So the bench does not rank hours first above brand intelligence first, and neither should you on its evidence. The argument for starting with hours is a different kind of argument: certainty. Removing hours needs nobody's permission and no buyer. Selling intelligence needs both, and session 5 is about earning them.

The assumptions block is the small set of inputs every number on this page is computed from. Company-wide: the loaded hour ($18), GMV a quarter ($45,000,000), Serai's GMV share (2 percent), the build squad's weekly cost ($9,000), thirteen-week quarters, an eight-quarter horizon, and the identity gate's threshold (0.90). Per use case: people, hours a week, automatable share, build weeks, run cost a week, attach fee a quarter where a payer exists, and GMV uplift where the use case lifts sales. Ten rows, one block, and the value of every use case falls out of the same formula:

hours removed x loaded hour + attach a week + GMV a week x uplift x Serai's share - run cost

The usual alternative is ten business cases in ten spreadsheets, each built by the team that wants the use case, each with its own loaded hour, its own quarter length and its own idea of how much brands will pay. They cannot be compared, which is convenient for whoever is loudest. One block makes every case share every assumption, so when the studio lead says the automatable share of content is 50 percent and not 35, the argument is about one cell and everybody can see what it does to every bar. The block is a governance device dressed as a calculator.

Two rules for keeping it honest. First, a stipulated number stays labelled as one: the attach fees in Serai's block are guesses until a brand signs, and the bench's refusal to rank on them is the model for how to treat every such cell. Second, the block is edited in the open, with a date and a reason, so that when a bar moves everybody knows why. The analyst track turns that second rule into code in session 7.

Open the assumptions block in the bench and change one input: Serai's GMV share. At the default 0.02, hours first returns $1,372,287 and pricing first $860,315. Set the share to 0.06 and the pricing uplift to 0.06, and pricing first prints $1,900,438 against $1,612,656 for hours first. Set the share to 0.10, and pricing first wins from an uplift of only 0.04: $2,068,254 against $1,659,180. Nothing about the use cases changed. What changed is how the business is paid.

So the first question for your own roadmap is not "which use case" but "what is our split". Take last quarter's revenue and divide it into money that moved with brand GMV and money that did not. Session 1's homework asked your finance lead for exactly those two numbers. If most of your revenue arrives whatever the brands sell, you are a fee-based enabler and hours come first. If most of it arrives as a share of sales, you are closer to a brand, and the use cases that lift GMV are your lever, pricing among them. Hybrids sit in between, and the honest move is to run your own share through the block rather than to guess which side you are on.

One caution that carries over from the 3.2 percent finding: the crossover cells are as constructed as everything else, and an uplift of 6 percent from pricing is an assumption, not a promise. What the crossover establishes is the shape of the rule, not the exact share at which any real business should flip. That share is yours to compute from your own block.

Three constructed, generic cases, no real company behind any of them. Each put pricing optimisation at the top of its roadmap. Judge each by its revenue model, not by the outcome.

• The house-brand operator. A company that sells its own brands on the marketplaces and keeps the goods margin. Its revenue is a share of GMV in the purest sense: all of it. Pricing first was right for it, and the hours-removed argument was close to irrelevant, because its cost base was stock and marketing, not a rota. On the grid it lives at the bottom row, share near 1.0.
• The fee-based enabler that copied the operator's deck. Retainers made up most of its revenue, its GMV share was small, and it built pricing first because the operator down the road had. It spent its first three quarters of build capacity lifting brand GMV it kept two percent of, while its content studio kept growing headcount with every new brand. Pricing first was wrong for it, for exactly the reason in Part 2: no payer. The fix was not to abandon pricing but to sell it, with an attach fee, to the brands who wanted it.
• The performance-fee agency. Paid a large share of incremental GMV above a baseline, with a small fixed fee. Pricing first was right for it, and its roadmap looked like the operator's despite it owning no goods, because its fee split put it on the same row of the grid. This is the case that shows the rule is about the split, not about the business's label.

The same use case was right twice and wrong once, and the one thing that predicted it every time was the share of revenue that moved with GMV. Nothing else on the roadmap did.