What is the e-commerce Digital Workforce?
The e-commerce Digital Workforce is the set of Digital FTEs on ftes.ai built for online stores: thirty roles across nine departments — Office of the Owner, Finance, Merchandising, Product Quality, Customer, Demand, Operations, Retail and Supply — each of which owns one recurring store function end to end. A store hires the roles it needs, manages each like a direct report in a workspace with Today, Approvals, Performance and Targets tabs, and can dismiss any of them in one click.
The category matters commercially, not cosmetically. Business intelligence, e-commerce analytics and assistants describe things that report. A workforce describes roles that work. A merchant comparing analytics tools compares dashboards and picks the cheapest that looks good; a merchant deciding whether to hire compares the cost against a salary and the output against a job description. The second comparison is the one a Digital FTE wins, and it is the comparison this whitepaper is written for.
Who is it for, and who is it not for?
The e-commerce Digital Workforce fits brands holding real inventory at a size where the money in the seven leaks is material and nobody is employed full time to chase it; apparel, footwear and anything with sizes, where fit and stock decisions are hardest; any store with more than one place stock can sit; brands buying ahead of demand, where the buy is irreversible; and operators who already own the tools and still do the work by hand. They have the data and the frustration. They do not need another screen.
It is not for pre-revenue stores, where a spreadsheet is honestly fine; for pure dropshippers holding no stock, because half the workforce is about inventory cash; for anyone wanting a support bot, which the Order Support FTE integrates with rather than replaces; for anyone wanting an ads agency, since media buying is being given away by the platforms and the workforce measures it honestly rather than selling it; or for anyone who wants software to run the business without them. Every role here works for a human, reports to a human, and stops when a human says stop.
Why is this a profitability problem rather than a growth problem?
The problem the workforce exists for is profitability, not growth. A store's gross margin as the platform reports it is revenue minus the supplier's price; it ignores everything that happened between the factory and the customer's door. Freight, duty and the brokerage cost per customs entry, shrinkage, the discount actually given including stacking, the returns each product generates, outbound shipping, payment fees, the cost of acquiring the customer and the cost of carrying the unit until it sold are all real, all recurring, and mostly absent from the number the owner quotes.
The consequence is that the products a store promotes because they look like bestsellers can be the products losing it money at volume, and the cash a store believes it has is sitting on a shelf. None of this shows in a growth chart. It shows in a margin that was never really there, which is why the first layer of the workforce is a ledger and not a dashboard.
What are the seven leaks the workforce works on?
The seven leaks are recurring, quantifiable losses every store of size carries, each of which maps to roles in the org chart. They are stated here as mechanisms rather than as market statistics, because the ftes.ai content standard publishes a figure only when it is a product mechanic, a labelled worked example, or a named public source the reader can open.
- Cash frozen in stock: inventory at landed cost sitting for months, with the markdown-versus-hold decision living in a spreadsheet. Owned by the Cash Officer FTE, with the Allocator and the Buyer.
- Margin that was never really there: costs never loaded into the margin the owner quotes. Owned by the Controller FTE, fed by the Landed Cost & Compliance FTE.
- Returns, and fit as their cause: a return costs both shipping legs, processing and support, and a returned unit may never resell at full price; fit is a data problem whose evidence already exists. Owned by the Fit Officer and Returns Officer FTEs.
- Discounting nobody can see: stacked codes, automatic discounts and shipping subsidy produce a realised discount rate no report shows. Owned by the Pricing Officer FTE.
- Shipping, duty and the cost of crossing a border: the fixed brokerage cost per customs entry, paid per parcel instead of per consolidated entry. Owned by the Logistics and Landed Cost & Compliance FTEs.
- Money left on the floor: disputes nobody had time to contest before the deadline. Owned by the Disputes & Fraud FTE.
- Being invisible to the new front door: catalogue defects that disqualify products from AI shopping surfaces and answer engines. Owned by the Visibility Officer FTE, with the Product Catalog and Content Officer FTEs.
What does one leak look like in arithmetic?
A labelled worked example, illustrative only, with every input stated. A store earns twenty million a year at a forty-nine percent gross margin, so cost of goods is roughly ten million two hundred thousand. If that store carries one hundred and twenty-nine days of inventory, the stock on hand at cost is about three million six hundred thousand. At an all-in carrying cost of twenty-five percent a year — capital, storage, obsolescence and opportunity, which is the rate the owner sets in the Cash Officer FTE's Setup tab — carrying that stock costs about nine hundred thousand a year, or four and a half percent of revenue.
Every thirty days taken off the stock cycle at those inputs releases roughly eight percent of annual cost of goods in cash and saves about two points of revenue in carrying cost: at this store, about eight hundred thousand of cash and four hundred thousand a year of profit from one operating change. The numbers are the example's, not a claim about any store; the arithmetic is the Cash Officer FTE's, run on the store's own figures and shown on every proposal.
Why cannot the existing stack fix it?
A store of this size already runs ten or twelve apps and often an agency: a commerce platform, attribution, email and SMS, a help desk, reviews, returns, forecasting, loyalty, testing. Each is good at the half of the job that ends with a chart. Attribution and analytics report on marketing and never touch inventory, landed cost or cash. Unified reporting is a reporting layer. Warehouses give a warehouse, not an answer. Forecasting tools forecast units, not cash, on a Gregorian calendar. Returns platforms see the online channel and do not price a return or attribute it to a vendor. Help desks are solved and do not know why the tickets exist. Agencies are priced per month regardless of outcome and use the same tools with the same blind spots.
The seven gaps nobody fills follow directly: no single true-contribution-margin engine; diagnosis everywhere and execution nowhere; cash as an orphan; discount leakage unmeasured; chargeback recovery manual; fit untouched; and the sprawl itself as the pain. The budget is not missing. It is allocated to reporting.
What will the store platform give away free, and what is the honest answer?
Any product sold to these merchants must answer one question honestly: what does it do that the commerce platform will not do for free within twelve months? The platforms are shipping assistants that surface next-best actions from store data, native testing and automatic enrolment into AI shopping surfaces, all improving, all with zero integration cost. A generic dashboard, generic chat over platform data, or another report is an indefensible answer.
The defensible answers, and the only ones the e-commerce Digital Workforce uses: cross-system data the platform does not hold — landed cost, supplier terms and lead times, warehouse performance, help-desk history, returns reason codes, footfall, tills, marketplaces and carrier invoices; true fully-loaded unit economics, which need cost data the platform has never seen; cash and working-capital decisioning, which needs supplier terms, receipt dates and a carrying-cost policy; depth of reasoning over one merchant's own history of decisions and outcomes; and doing the work and being measured on the result, which a platform has no commercial incentive to publish when its own advice was wrong.
Layer one: the Ledger — one honest number
The Ledger is the Controller FTE's costing and contribution engine: per order line it loads supplier cost in its original currency at the rate on the day, inbound freight, insurance and handling allocated across the shipment, duty and the brokerage cost per entry, a shrinkage provision, the discount actually given, returns actual for closed periods and provisioned from the product's own rate for open ones, outbound shipping and payment fees, fully-loaded acquisition cost, and carrying cost for every day the unit sat. It rolls up by product, variant, size, colour, vendor, category, channel, location, campaign, discount code, customer and cohort.
Two disciplines make it trustworthy. Costs are dated, so changing a cost today never silently rewrites last quarter's margin. And coverage is always shown: if only sixty percent of a category's cost is known, the page says sixty percent rather than presenting a complete-looking number. The honest part is that landed cost needs data the merchant has to supply — freight invoices, duty, supplier terms — and the Controller FTE starts from category-level assumptions and sharpens as invoices arrive. The cost data is the upgrade, not the entry fee.
Layer two: the Workforce — capability with an owner
The Workforce is the org chart. Software organised as features becomes a menu, and a feature with no owner has no accountability: nobody can say whether the inventory module is doing a good job because a good job was never defined. On ftes.ai every capability is a named Digital FTE with the five things a human employee has: a job description in plain English, a scope of authority stating what it may do alone and what needs a signature, a shift, a manager — a named human who approves and is accountable — and one number it is judged on, agreed up front and shown above the fold on its page.
Grouped into nine departments, the customer does not browse a feature list; they read an org chart and decide who to hire. Every role's page also states what it does not do, because the limits line is the most trust-building text on the page. The Chief of Staff FTE is the department the others report to: every night it reads what every role produced, ranks it by money at stake, resolves conflicts between roles with both sides' arithmetic, and writes one morning page in five sections — Done, Decide, Watching, Measured, Attention. A quiet page is a legitimate outcome.
Layer three: the Proof — prediction before, measurement after
The Proof layer answers the failure every advice-giving tool shares: none of them comes back to say whether the advice worked, so the customer decides on feel whether the subscription is worth it. Three mechanisms work together. Prediction capture: no recommendation can be displayed unless it declares what it expects to happen, over what period, measured how, with what confidence. Outcome measurement: when the horizon arrives the system runs the declared measurement, records the actual result, computes the error, updates that role's accuracy and publishes it whether or not the news is good. The value ledger: a running double-sided record of opportunity identified and value realised, each entry tied to a specific action and its measurement, plus a fourth figure most vendors would never show — forgone, the value of opportunities the owner declined or let expire.
Four rules keep it honest. Only measured value is ever reported as realised, never identified, predicted or estimated. Where a range exists, the ledger records the low end. Opportunity converts to realised and never adds to it, so double counting is structurally prevented rather than policed. The methodology is published, and the owner can dispute any entry. Where a holdout is practical it is used, so the difference is causal; where it is not, the measurement is labelled observational on the page. On ftes.ai this ledger is how roles report; billing is metered work from one organization wallet with a hard stop at zero, and the site does not claim a value-based invoice the platform does not run.
Layer four: the Memory — it learns your business, and nothing else's
The Memory is the per-organization record of every recommendation, its prediction, its outcome, the owner's decision and the stated reason. Generic advice does not know that you will never drop a vendor because of a twenty-year relationship, that you mark down later than most because your customer waits for it, or that the last three transfer recommendations you accepted all landed. From the record, the workforce learns your thresholds, calibrates its confidence against its measured error, and stops re-proposing what you have declined three times — or explains why it still disagrees.
Two hard rules apply. Nothing is learned silently: an inferred preference must be confirmed by the owner before it takes effect. And memory never crosses between organizations: your history improves your workforce and nobody else's. This is the only moat that compounds. A competitor can copy a feature in a quarter; it cannot copy three years of measured decisions on your data.
How does control work: the autonomy ladder and the hard limits
The biggest reason merchants refuse automation that acts is that they cannot see what it will do, cannot bound it and cannot undo it. On ftes.ai autonomy is earned per role and per class of action on the approval record, never switched on globally. Level 0 proposes only: every draft, launch, send or spend waits in Approvals. Level 1 allows low-risk actions the owner has approved many times. Level 2 acts inside caps — pausing losers, scaling winners, publishing scheduled work, always inside the budget and rules the owner set. Level 3 runs the week on a schedule while the owner reviews the brief, the exceptions and the numbers. Any level can be taken back at any time, and most owners run most roles at Level 0 or 1 indefinitely, which is a perfectly good outcome.
Above the ladder sit written limits no level unlocks: price floors, refund and goodwill limits, ad caps, frequency caps, the cash ceiling, purchase-order approval, and an always-escalate list for anything sensitive. An action that would exceed a limit is refused and queued, never quietly trimmed to fit. Everything is logged with who, what, when, on what evidence and under whose approval; everything reversible is reversible in one click, and irreversible actions look different at the moment of approval; one button stops a role or everything. The Data Trust FTE adds the rule that sounds small and is not: no role acts on a degraded source, and nothing is shown as zero when the truth is 'could not read'.
How do you apply this in thirty and ninety days?
In the first thirty days, hire the role whose failure you can already see in your numbers and record its baseline before it starts: days of inventory and cash in stock for the Cash Officer FTE, cost coverage and the platform margin for the Controller FTE, fit-driven return rate for the Fit Officer FTE, open disputes and recovery for the Disputes & Fraud FTE. Connect the store, confirm the limits in Setup, review the role's day-one audit, approve its first proposals, and hold the day-thirty review in Performance against the baseline. Promote nothing yet; read the approval record.
By ninety days, add the Chief of Staff FTE so the roles report through one morning page, add the Data Trust FTE so no role acts on a degraded source, and hire the neighbours the first role keeps handing work to — the Buyer beside the Cash Officer, the Returns Officer beside the Fit Officer, the Pricing Officer beside the Controller. Promote the classes of action with a long, clean approval record to Level 1, keep the limits where you wrote them, and read the first quarterly ledger: opportunity, realised at the low end, forgone, and each role's prediction accuracy published whether or not the news is good.
What are the objections, and what are the honest answers?
'The platform will do this for free.' Some of it, yes, and the whitepaper says which parts are indefensible. It will not load your landed cost, read your supplier terms, price your returns, contest your disputes, or publish that its own advice was wrong. 'We already have an agency.' Keep it for judgement, creative and relationships; the workforce runs the daily function inside the limits and reports the numbers the agency's tools cannot see. 'It will act on bad data.' The Data Trust FTE exists so that it cannot; a degraded source withholds the proposals that depend on it and says so. 'It will overspend or discount below cost.' The caps, floors and ceiling sit above the autonomy ladder; an action that would breach one is refused, not trimmed.
'How do we know it earned anything?' Every proposal declares its prediction before it runs, every outcome is measured after, the low end of any range is what gets recorded, and forgone value is counted too. 'What if it is wrong?' It says so, by role, monthly, and recalibrates; the approval record is what decides whether it earns more autonomy. 'Can we stop it?' In one click, per role or globally, with everything reversible reversed. The whole proposition is that the workforce tells the truth about its own results; a page that exaggerated would destroy that before the first hire.