--- name: skill-unit-economics type: skill license: CC BY-NC-SA 4.0 description: >- The operator's procedure for working out whether a retail venture makes money per order and what a pound of spend should return — the per-order margin ladder from price to contribution margin, acquisition economics (CAC by channel, payback, LTV, the LTV:CAC threshold to clear before scaling spend), cash and inventory for own-stock lines only, and the costed budget proposal written in the Owner's decision-item format. Use before any spend, pricing or range decision, when a vertical's mandate calls for a costed budget proposal, or from skill-operating-loop's decide step and skill-opportunity-eval's cost read. Reads live figures through convention-shopify's KPI queries and the envelope from the vertical's mandate document; never invents a number and marks every figure known, assumed or missing. Decision support only — it proposes, it never spends. Run by operator-bara first; any retail operator. Surfaced by APP-1080; first draft 2026-09-03. --- # unit-economics The operator's economics skill. Before a retail vertical spends, reprices or changes its range, this works out whether an order makes money and what a pound of spend should return, then turns the answer into a costed budget proposal the Owner can rule on from the top of the page. It is the arithmetic beneath `skill-operating-loop`'s decide step and the cost line in `skill-opportunity-eval`; it composes `convention-retail` for KPI definitions and `convention-shopify` for the queries, and re-implements neither. The output is a read and a proposal, never a spend. ## Trigger - A spend, pricing or range decision is on the table — a paid channel to switch on, a price to move, a product to add or drop, a discount that spends margin. - A costed budget proposal is due: the vertical has no envelope yet, or the envelope in its mandate document has become the binding constraint on a goal. - Called from `skill-operating-loop` step 3 (decide) when a candidate action carries a cost, and from `skill-opportunity-eval` Pass 2 (cost) when the opportunity is a retail bet. Run by the vertical's operator — `operator-bara` first; any retail operator as the family grows. Requires the operator context: the vertical, its mandate document, and its analytics source. ## Behaviour Four passes, in order. Each builds on the last; skip none, but a pass whose inputs cannot be read records the gap rather than a number. ### Pass 1 — the per-order margin ladder Build the ladder per product, then per basket, in this order: 1. **Price** — the selling price net of any discount in play. `total_sales` is net of discounts and returns and `gross_sales` is not (`convention-shopify`); say which the ladder uses. 2. **Cost of goods** — for own stock, the landed unit cost; for print-on-demand, the Printify base cost plus its per-item fulfilment charge. 3. **Shipping and packaging** — what the venture pays to ship, less what the customer pays, plus packaging per order. 4. **Payment fees** — the processor's percentage and fixed fee on the order value. 5. **Returns allowance** — the return rate applied to the unit's cost of goods plus outbound and return shipping. 6. **Contribution margin** — what is left, in pounds and as a percentage of price. Per product shows which lines earn. Per basket — at the live AOV, with the live product mix from the top-products query — shows what an average order contributes, which is the number every acquisition figure in Pass 2 is tested against. State both. ### Pass 2 — acquisition - **CAC by channel** — spend on the channel over the period divided by first orders attributed to it (channel mix from `convention-shopify`; attribution rules from `convention-retail`). Organic and owned channels carry a cost too — the time or content spent — stated as an assumed figure rather than treated as free. - **Payback period** — CAC divided by contribution margin per order, expressed in orders, and in months at the live re-order cadence. - **LTV** — contribution margin per order multiplied by expected orders per customer, where expected orders derives from the repeat-customer rate and the observed re-order interval. On a store too young for a repeat signal, mark LTV as assumed and bound it: at zero repeat, LTV is one order's contribution. - **The threshold** — the LTV:CAC ratio a channel must clear before spend on it scales. Default 3:1 with payback inside the mandate's timeframe; a vertical may set its own in its mandate document, and the document wins. Below the threshold the recommendation is to fix margin or conversion before adding spend, never to add spend and hope. ### Pass 3 — cash and inventory (own-stock lines only) For each own-stock line: stock turns (cost of goods sold over average stock at cost), sell-through (units sold over units received in the period), cash tied up (units on hand multiplied by unit cost), and the reorder point (daily sell rate multiplied by supplier lead time, plus a stated safety margin). Read stock from live inventory levels, never from memory. This pass is skipped entirely for print-on-demand lines — there is no stock, no cash tied up and no reorder point — and the skip is written into the output so the proposal does not read as incomplete. ### Pass 4 — the costed budget proposal Turn the ladder and the acquisition read into tiers of spend. Each tier states: - **Tier** — the amount and the period it covers. - **Unlocks** — the channel or move it funds, and the KPI from the vertical's KPI set it should move. - **Expected return** — orders and contribution at the modelled CAC, each figure marked known or assumed. - **Breakeven** — the orders, or the conversion rate at live sessions, at which the tier returns its spend at contribution margin. Write the proposal in `convention-comms-owner` format: the Decision / Action needed / Why header, then the recommended tier as a decision item (decision · recommendation · why it matters · risk of deciding vs not), then the tier table and the workings below for the audit reader. Where the recommended tier sits inside the envelope the action line reads "nothing beyond your yes"; where it exceeds the envelope the proposal is a budget-envelope-breach escalation (`skill-operating-loop` step 5) and says so in the header. A tier the operator does not recommend is still shown, with the reason it lost. ## Known, assumed, missing Every figure in the output carries one of three marks: - **Known** — read this run from a source named beside it: a ShopifyQL query, the mandate document, a supplier invoice or the Printify catalogue. - **Assumed** — not readable this run; the assumption and its basis are stated, and the assumption that most changes the recommendation is flagged as the one to verify first. - **Missing** — no source and no defensible assumption; the ladder shows the gap and the proposal says what it would take to fill it. A proposal resting mostly on assumed figures says so in its header, so the Owner weighs it as a model rather than a reading. Repeating an assumed figure in a later run does not make it known. ## Guardrails - Decision support only. Proposes; never spends, creates a discount, changes a price or launches a promotion — those stay human actions at `convention-shopify`'s boundary. - The envelope is read from the vertical's mandate document (such as `bara.mandate` on the BARA relaunch initiative), never restated in this skill or inferred from an operator profile. - Never invents a number (`convention-ticket`). A missing input is a named gap, not an estimate dressed as a reading. - No live credential, token or account detail in a proposal or report (`convention-secrets`). - Reads live figures each run through `convention-shopify`'s queries; a previous run's figures are stale by definition. - KPI definitions belong to `convention-retail`; this skill uses them and does not redefine them. - One vertical per run, the operator's own. ## Setup Run on demand by the operator, or composed into its operating loop and into `skill-opportunity-eval`. Not scheduled on its own — the trigger is a decision, not a date. Connectors: Shopify (read-only) and Linear. On finish, run `skill-ops-retro` capture on this run's friction: file a `FRICTION:` note to the Pulse queue for the drain to assess. Owned by the operator; `operator-bara` first.