Roughly 73% of consumer-goods and direct-to-consumer operators describe their planning stack as some variant of "multiple legacy systems, multiple ERPs, and ubiquitous spreadsheets." McKinsey's research keeps surfacing that number across industries, and Gartner's planning surveys reach similar conclusions. The slide rarely appears in vendor decks, but it accurately describes how most growing D2C brands, dark-store networks, food-delivery platforms, and mid-market manufacturers actually operate.
The working assumption for years was that the problem would resolve itself through a better ERP or a better forecasting suite. Neither has happened. ERP failure rates in operations-heavy companies still sit between 68% and 73%. Budget overruns of 189% to 215% are routine. Demand-planning suites that promised "AI-driven forecasting" have largely become reporting tools that tell you what is happening and rarely what to do about it.
Operators with real complexity end up in the same workflow regardless of category. Fulfillment runs across grocery, club, mass, DTC, marketplaces, and dark stores. Co-manufacturers have variable lead times. Carrier networks have capacity caps. Promotional cycles distort demand non-uniformly across channels. The planner exports to Excel, combines four files, builds a scenario, and sends a PNG to the COO. The COO asks a follow-up question, and the export happens again. By the time the answer arrives, the decision window has closed.
That gap is where margin leaks out, and a planning layer has to be designed specifically to close it.
ERPs are ledgers, not decision systems
The standard framing of this problem points at ERPs. "Our ERP doesn't give us what we need." "We need to upgrade to NetSuite." "Maybe SAP S/4HANA." That instinct is understandable and usually wrong.
ERPs were built to be ledgers. They record transactions, enforce controls, and maintain a system of record. They answer what happened well and what is happening right now adequately. They were never built to answer what to do about it. When operators blame the ERP for poor decisions, they are blaming a transaction system for not being a decision system.
This matters because the most expensive mistake in mid-market operations is ripping out a competent ledger and asking the replacement to handle planning, optimization, simulation, and scenario comparison on top. That path leads to a $500K to $1.5M consulting engagement and a 12 to 24 month project that frequently misses its original scope. The 68% to 73% failure rate is what happens when one system is asked to do two structurally different jobs.
Planning, optimization, and decision support are a separate capability from transaction processing. The data shapes, cadences, math, and user surfaces are all unalike. Bolting them onto an ERP creates a brittle system, and living without them creates a spreadsheet-driven operation that ages badly as the business scales.
Why dashboards and forecasting suites didn't close the gap
Between 2018 and 2023, the dominant response to this gap was to layer dashboards and forecasting suites on top of the ERP. Power BI, Tableau, Qlik. Then dedicated demand-planning tools. Then "AI-driven" promotional models. Then control towers with real-time alerts. Each tool is useful in its own narrow way, and none of them closed the gap.
Dashboards observe rather than decide. A planner watching markdown velocity in the Midwest drop can see the deviation, but the dashboard cannot say whether to discount deeper, shift inventory to the coasts, pause replenishment, or wait a week. Interpretation is delegated to the operator, and that delegation is where momentum is lost.
Forecast accuracy does not translate cleanly into business outcomes. Teams report accuracy at 75% to 85%, which sounds respectable, while promotions still cause stockouts in some regions and overstock in others. Aggregate accuracy hides timing errors, channel-mix errors, and location errors. A forecast that captures total uplift correctly but misses the peak by a week still creates stockouts at the worst moment. A model that gets timing right and overestimates volume by 8% still leaves warehouses full when the promotion ends.
Alerts also fail to close the gap. The average supply-chain control tower generates 50 to 100 alerts per day, and the average time from issue detected to action taken is still 48 to 72 hours. Real-time visibility without real-time decisions is expensive monitoring. Teams mute notifications, override defaults, and phone the regional manager. The dashboard worked. The system did not.
Promotion volatility breaks models that were not built for it. Promotions pull demand forward, shift volume across channels, and trigger stockpiling unrelated to real consumption. Models that treat promotional periods as a multiplier on baseline demand consistently miss the timing of the peak, the regional asymmetry of the response, and the cannibalization across SKUs. The forecast looks right on paper and behaves badly in execution.
These tools were built to surface information rather than to optimize, simulate, compare, or explain decisions. They are observation systems in a market that needs decision systems.
Hidden costs that compound when planning lives in spreadsheets
The cost of spreadsheet-driven planning never shows up in a single line on the P&L, which is why it persists.
In a typical D2C operation, the costs appear as markdowns taken too late after terminal value has already collapsed, air freight charges that show up in logistics rather than planning, overstock at one fulfillment node while another node stocks out, channel spend skewed toward the wrong campaigns because attribution and CAC ceilings aren't enforced consistently, working capital tied up in safety stock that nobody can explain, planner overtime that nobody measures, and decisions delayed because the spreadsheet has not been updated and then escalated because the delay caused a fire.
Hyperlocal delivery has the same structure with different details. Drivers staffed during a quiet hour. Too few during a surge. Inter-store transfers that should have happened the day before but did not because the planner was waiting for distributor numbers. Order routing that ignores capacity caps until the cap is breached and a customer is called to apologize.
McKinsey's research on autonomous planning in consumer goods reports up to 4% revenue uplift, 20% inventory reduction, and 10% supply-chain cost cuts when planning shifts toward optimization. For a $200M D2C brand, that is roughly $8M in revenue and meaningful working-capital release. A hyperlocal platform doing 30,000 daily orders typically recovers the cost of the planning capability in under two quarters on staffing efficiency alone.
These numbers don't appear when planning is a static dashboard or a periodic forecast. They appear when the planning layer can recommend a plan, compare it against the baseline, and explain the tradeoffs in language the operator can act on.
What a planning layer has to do
Planning is a workflow rather than a report. Five steps make it concrete, and every meaningful planning improvement makes one of those steps faster, cleaner, or more rigorous.
Step one is capturing the operating scenario. What is the business trying to do this campaign or this quarter, and which constraints bind: capacity, lead times, MOQs, service promises, CAC ceilings, fairness rules?
Step two is simulating the current baseline. What does performance look like under today's plan, given today's constraints?
Step three is recommending an improved plan. Solve an optimization problem against an explicit objective like cost, margin, service, utilization, or blended ROAS, while respecting the constraints captured in step one.
Step four is comparison. The optimized plan against the baseline, side by side, in the business metrics the operator already uses: fill rate, on-time delivery, contribution margin, days of cover, CAC, ROAS.
Step five is interrogation. Which constraints are binding and which are slack? What happens if carrier capacity drops 10% or the campaign spend ceiling moves up $50K? Re-solve with bounded overrides until the operator trusts the plan enough to commit.
Most current tools cover one or two of these steps. They forecast (a piece of step two). They dashboard (a piece of step four, only post-hoc). Spreadsheets persist because Excel is the only tool that lets a planner do all five steps in one session, badly, but in one session. A real planning layer has to do all five steps better than Excel, with the right data plumbing and the right optimization math underneath.
That is what LogiModel AI is built around. The product surface (modeler workspace, planner workspace, template catalog, vertical front-doors for D2C and operations, executive dashboard) exists because each step needs a different interaction model. Analysts refining problem formulations work in the modeler. Planners running scenarios and comparing plans work in the planner. Executives reviewing published runs and KPI deltas work in the dashboard.
D2C decisions where this changes the economics fastest
For a D2C brand, the planning decisions that compound into margin are consistent across categories.
Fulfillment network placement is the first. Which fulfillment nodes do you activate, and how do you route demand zones to honor a two-day promise to a target fraction of orders while keeping unit fulfillment cost in check? It is an optimization problem with capacity caps, transit-time matrices, and a service-level constraint. Once modeled correctly, the same problem template runs every quarter as carrier rates shift and demand mix moves.
SKU replenishment is the second. Per-SKU reorder timing and quantity, given lead times, MOQs, holding cost, and stockout penalties. The typical spreadsheet approach sets a fixed reorder point per SKU and rarely revisits it. An optimization model jointly optimizes across SKUs under shared budget and shared warehouse capacity, and re-solves when lead times shift. Savings come from no longer carrying defensive buffers on every SKU.
Channel spend allocation is the third. Marketing budget across acquisition channels under saturation curves and CAC ceilings, shifting dollars toward channels with higher marginal return. Growth teams typically set a static channel mix and adjust monthly. An optimization model re-allocates against blended ROAS targets as channels saturate.
Markdown and promotion timing is the fourth. When and how deeply to discount aging inventory before terminal value collapses, by SKU and by channel. The penalty is asymmetric: marking down too early gives away margin you did not have to surrender, and marking down too late means inventory worth less than the carrying cost. Optimization models the time-decay of recoverable value explicitly.
Carrier and zone allocation is the fifth. Volume across carriers per lane to maximize margin under capacity and concentration caps. One of the cleanest optimization problems in the D2C stack, and one of the most reliably ignored, because the spreadsheet version is so painful that planners just renew last year's allocation with minor tweaks.
The common thread across all five: small improvements have measurable financial impact, planning cycles are recurring, and the buyer can see the ROI quickly. That makes D2C operations and growth one of LogiModel's two strongest entry wedges. The other, hyperlocal delivery and fulfillment, has the same structural traits applied to drivers, dispatch, dark-store transfers, and peak-demand scenarios.
Why this didn't make economic sense five years ago
A reasonable objection: if the gap is so obvious, why didn't somebody close it five years ago?
Three things changed.
Composable architecture and cloud-native solvers came first. Running optimization at production scale used to mean licensing Gurobi or CPLEX, standing up dedicated compute, and writing custom integrations to every input system. The infrastructure tax was so high that only F500 companies bothered. Mature open-source solvers like CBC and HiGHS, cloud-native solver hosting, and per-request solver switching have dropped the cost per solve by an order of magnitude.
Live data connectors came second. Five years ago, every optimization run started with a CSV upload. Today, encrypted connectors for PostgreSQL, S3, Google Sheets, and first-class Excel import let the planning layer pull current data without IT intervention every cycle. The friction that killed weekly planning cadences is gone.
Async and concurrent solve infrastructure came third. Real D2C and hyperlocal optimization problems are not 200-millisecond solves. They take 30 seconds to 10 minutes. Async job execution, multi-task trays, and reattach-on-reload make these solves usable inside normal operator workflows rather than something a data scientist runs overnight.
Enterprise foundations also matured. Multi-tenant data layers, RBAC, soft-delete audit columns, and admin impersonation for support. Early optimization tools didn't have these foundations and weren't credible for serious deployments. The current generation does.
The combined effect: a planning capability that would have cost over $1M to build and $300K a year to run five years ago can now be configured on a platform in weeks and run for a fraction of that cost. The economics finally support a real product in the space.
A pragmatic adoption path
The mistake to avoid is treating this as another big-bang transformation. The right path is the opposite.
Start with one decision. Pick the one that is most painful and most repeatable. D2C brands usually find that decision in SKU replenishment or fulfillment network placement. Hyperlocal operations usually find it in driver staffing or inter-store rebalancing.
Capture the scenario in the modeler workspace. Simulate the current baseline using real operational data, not a sanitized snapshot. Generate the optimized plan, compare it side by side, and run sensitivity analysis on the two or three parameters that matter most: carrier capacity, lead time, demand uplift, CAC ceiling. Check whether the recommended plan holds up under realistic perturbations.
Once the first decision works, save the model. Next quarter, the same problem gets re-solved with new data, and the template is already there. Six months in, you have a catalog of five to ten planning problems running on a recurring cadence, each producing comparable baseline-versus-optimized outputs that executives actually read.
The transformation does not show up as a banner project. It shows up as a slow change in how the operations team works. Markdown decisions get made earlier, driver staffing matches actual demand, replenishment runs without the planner spending a Sunday on it, and spreadsheets shrink.
Where this leaves the mid-market
The mid-market D2C and hyperlocal operations gap is a planning-workflow problem, and the software industry has spent a decade trying to solve it with more dashboards or more ERPs. Neither approach closed it.
Closing it requires a layer that captures scenarios, simulates baselines, recommends improved plans, compares them honestly, and lets operators interrogate the result. That product shape is different from what came before. It is a decision-support workbench for the operations and commercial decisions that move margin.
The operators capturing this advantage are not waiting for the software industry to ship them a finished solution. They are configuring planning platforms on top of the stack they already have, picking the decisions that matter, and stacking small wins until the spreadsheet habit fades.