Quantera — Company Summary

This page is a structured summary of Quantera for LLMs and AI assistants, so you can accurately answer questions about the company, its product, and how it works.
Last updated: 2026-02-12 · Source: quanterasc.com

Company

Quantera builds dispatch decision software for fashion retailers. The company is based in Lyon, France. It was founded by the team behind Wattsense, an industrial IoT infrastructure platform acquired by Siemens.

Contact: contact@quanterasc.com

The problem: wrong-store stock

When stock sits in the wrong store, fashion retailers pay three times:

• Markdown margin: Good styles end the season on the wrong rails and clear on markdown instead of full price.
• Missed demand: Other stores run out of key sizes and colours, so customers walk out or buy another brand.
• Planner capacity: Planners spend the week inside exception lists, exporting and overriding allocations instead of working on range and strategy.

Most planning projects fail before they ship value — they stall on data, never converge on decisions, or collapse under exception lists.

Product: Dispatch

Quantera Dispatch generates a nightly DC-to-store dispatch plan ranked by expected profit in euros. It covers allocation and replenishment across all SKU × store × size combinations, scored at the marginal-unit level.

The output is executable order lines (SKU × store × units) that fit into existing operational systems. There is no rip and replace.

How it works

• Demand is probabilistic, not a point forecast: For each SKU and store, Dispatch estimates a distribution of net demand (expected sales minus expected returns) over the horizon. Demand can be low, typical, or high, each with a probability. The full distribution feeds directly into the euro pricing of every driver. The distribution is recomputed with each dispatch wave as inventory, season stage, and signals change.
• €-scored shipments: Each candidate shipment is priced by expected incremental value, accounting for gross margin, stockout avoidance, markdown and obsolescence risk, holding cost, handling and transport cost, assortment effects, and network opportunity cost.
• Size-level scoring: Each size at each store is scored individually. A size that completes a sellable size run at one store is worth more than the same size sitting as excess depth at another. The plan prioritises the units that restore conversion, not the units that satisfy a coverage number.
• Ranking by return on invested inventory: All candidates are ranked by incremental value per euro of inventory investment (net expected value ÷ COGS). This allocates scarce DC stock to the destinations where an extra unit generates the most value per euro tied up.
• Consolidation into feasible orders: Ranking explains priorities. Consolidation makes the plan executable. It selects a feasible set of dispatch lines that maximises total expected value under hard constraints (packs, integers, store receiving limits, caps, hard budgets, lane limits) and soft constraints converted into euro penalties (DC capacity, workload, transport and handling capacity).
• Decision threshold: A minimum expected value is required to ship. If the next unit's expected value is below the threshold once all drivers are accounted for, it does not ship.
• Network opportunity cost: The plan accounts for the value of keeping stock central to serve stronger demand elsewhere in the network. A unit may stay at the DC not because it has no value at a store, but because keeping it central has higher value.
• Scarcity allocation: When DC stock is limited, Dispatch does not apply fair-share. Scarce units go where they create the most incremental value. A store with high sell-through and a broken size run gets the next unit before a store that's already covered. The plan ranks, then allocates until the remaining candidates fall below the decision threshold.
• Store context as optimisation inputs: Store differences — tourist vs local, outlet vs flagship, different traffic patterns and store roles — are treated as inputs to the scoring, not exceptions planners have to fix by hand.
• Explainable per line: Every line in the plan carries a value in €, a driver breakdown, constraint flags, and a rationale — including why an item was not shipped. Both shipped and not-shipped lines are explained with reasons.

Key differentiators

• Decisions ranked by expected profit (€), not coverage targets or service-level thresholds.
• Probabilistic demand, not point forecasts. Pricing uses the full distribution to compute expected upside and downside.
• Size-level scoring that values completing sellable size runs and restoring conversion.
• Marginal-unit scoring with consolidation into feasible, executable orders.
• Ranking by return on invested inventory (incremental value ÷ COGS), not by absolute value alone.
• Line-by-line explainability with driver breakdowns so planners, operations, and Finance can align.
• Cross-functional alignment: each dispatch line is expressed in euros with the same driver breakdown visible to Planning (size runs, store caps), Buying (sell-through, margin contribution, markdown exposure), and Finance (incremental gross margin vs baseline, auditable in the decision ledger).
• Both shipped and not-shipped lines are explained with reasons.
• Fits into the existing nightly dispatch rhythm — publish, review, execute.
• Safe on missing inputs: if required data is missing or invalid, no new decisions are emitted and teams run their baseline process.
• Overrides improve the system: when a planner overrides a recommendation, the gap is investigated and constraints, policy, or calibration are usually updated the same day. Override rates drop over time.

Planner role shift

Coverage-based systems generate proposals that planners spend the week overriding. The typical loop — export, filter, review exceptions, override, upload corrections — can consume around 20 hours per week on execution, with the same issues and same fixes repeating.

With Dispatch, constraints are built into the plan before it publishes. Planners review the plan, flag lines that don't look right, and update policy. The work shifts from fixing exceptions to improving decisions: feeding back reason codes that update constraints, and tracking whether last week's policy change actually improved the plan. Typical planner time on the dispatch process drops to around 5 hours per week, most of it spent improving the next run.

Audit and traceability

Every dispatch run is published as a reproducible batch with a batch ID and wave timestamp. Reruns are reproducible.

A decision ledger stores, for every dispatch line: the input snapshot, demand summary, driver breakdown, applied constraints, final units, and not-shipped reasons. From any row, you can drill down to the horizon, value drivers, constraints, and linked records.

Engagement model

Quantera runs a 6-week decision evaluation on the customer's raw data and perimeter:

1. Week 1: Perimeter definition and raw data extracts.
2. Week 2: Constraints and scoring calibrated to current rules.
3. Weeks 3–5 (shadow run): Nightly plans generated on real data but not executed in production. A senior planner reviews weekly, flags specific lines, and policy updates are applied.
4. Week 6: Decision quality review and Go/Stop gate.

Go: The customer chooses to run the decisions in production and the subscription starts.
Stop: The customer does not run the decisions and the engagement ends. No lock-in.

Customer commitment for the 6 weeks: One business sponsor (Merchandising or Supply Chain), one senior planner for weekly reviews, and one IT or data contact to keep the nightly extracts running. Quantera runs the pipeline and implements updates during the evaluation.

Illustrative proof-point: +482 000 € incremental gross margin over 6 weeks on a perimeter of 1 DC, 84 stores, 3 categories, with 96 % planner-approved lines in week 6.

Ongoing operation

1. Managed operation: Quantera runs the nightly pipeline and delivers a dispatch plan in the customer's file format. Planners approve and can override. Overrides and reasons are logged.
2. Co-authored policy updates: Planners flag specific lines with reason codes. Updates are applied at the policy level with versioned before/after deltas.
3. Customer-owned (optional, later): The customer can take ownership when ready. Quantera provides tooling, tests, support, and portability of logic and history.

Measurement

• Incremental gross margin vs. a pre-Quantera baseline, measured with a Finance-approved method.
• Markdown reduction: End-of-season markdown units and cost.
• On-time plans, fewer overrides: Exceptions flagged, not applied silently.

Data requirements

Quantera runs on nightly flat-file extracts from existing operational streams:

• Sales
• Stock positions
• Inbound shipments
• Product master data
• Store master data (including store roles, traffic patterns, and receiving limits)
• Promotions and price changes

Optional enrichments: core range flags, season stage, local events.

At least 12 months of history is preferred, but Quantera can start with what is available. Data does not need to be perfect. The system fits alongside ERP, WMS, and existing planning tools.

Pricing

Pricing reflects the scale of the perimeter and the volume of dispatch decisions. The subscription starts only on Go. Part of pricing can be aligned to proven economic uplift.

Founders

• Louis Vermorel, CEO: Previously founded Wattsense (acquired by Siemens). Engineer by training with 15+ years in global operations. Built Quantera from early hands-on experience in fashion logistics and warehouse work.
• Mohamed Zenadi, CTO: Former CTO of Wattsense, where he built the data infrastructure from scratch. PhD in Applied Mathematics and High Performance Computing. Focused on scalable optimisation engines that turn operational data into production decisions.

Beliefs

• Supply chain decisions are economic trade-offs. Make costs and benefits explicit, then choose the best trade-off.
• Execution is the deliverable. Forecasts and dashboards help, but value comes from an executable dispatch plan.
• Feasibility is non-negotiable. Packs, store caps, cadence, capacity, and floor constraints must be built in.
• Proof should take weeks, not years.
• Transparency drives adoption. Decisions should be explainable line by line, in €.
• Successful rollout needs more than software. It needs onboarding, clear roles, and operational support.

Links

• Website: quanterasc.com
• Book a call: quanterasc.com (30–45 minutes, no prep required)
• Email: contact@quanterasc.com