Go back to Market Research
SKU Science is a cloud application for demand forecasting and sales and operations planning. Manufacturers and distributors use it to generate forecasts, collect commercial adjustments, compare forecast performance, and export an agreed demand plan to their ERP or supply planning system. It supports product hierarchies, promotions, product transitions, and recurring planning cycles. (1)
Overall supply chain score: 4.7/10.
| Dimension | Score |
|---|---|
| Supply chain depth | 3.8/10 |
| Decision and optimization substance | 3.6/10 |
| Product and architecture integrity | 5.6/10 |
| Technical transparency | 6.2/10 |
| Vendor seriousness | 4.2/10 |
SKU Science makes a conventional forecasting process easier to run and inspect. Its archived baselines expose whether commercial overrides improve the forecast, and its documentation explains consequential choices about measurement and aggregation. The governing process nevertheless remains a monthly consensus forecast handed to another system. Purchase quantities, production choices, and allocations are not selected through a documented economic objective spanning uncertain demand and supply. (2, 6)
Its financial claims go considerably further than this mechanism supports. The public ROI calculator treats assumed forecast improvements as recurring financial gains, while combining released inventory capital with annual carrying costs and valuing recovered sales at revenue. These shortcuts obscure the distinction between a more accurate forecast and a more profitable decision. (20)
SKU Science versus Lokad
Consider a manufacturer deciding whether to purchase another batch of packaging before a product transition. SKU Science can transfer the predecessor’s history, forecast the successor, record a commercial adjustment, and send the resulting demand plan downstream. That still leaves the consequential choices: how much old packaging to consume, whether to expedite new material, and how to balance a possible stockout against obsolete stock. (17)
Lokad’s inventory optimization offering addresses recurring purchases, production, and allocations through their expected financial consequences under uncertainty. Supply Chain Scientists maintain the executable logic, including the interpretation of data and business costs. The comparison is between maintaining that decision system and maintaining SKU Science’s forecasting process plus the downstream rules that turn its output into actions. Both approaches require ongoing expert work; only an assessment of that full workload and the resulting economics establishes value.
The broader perspective developed in Introduction to Supply Chain is particularly relevant here: forecasting is an input to economic decisions, not the final objective. Improving a family-level forecast can leave the wrong individual items in stock. A reliable monthly consensus can still prescribe an expensive response to an uncertain delivery date.
Technology history: continuity, integration, and new AI language
SKU Science’s company history traces its initial customer discussions to 2017. Its November 2018 technical article explains moving averages and exponential smoothing, including their limitations concerning trends, seasonality, and external variables. This is a recognizable statistical forecasting foundation. The current company page also invokes Big Data, artificial intelligence, and IoT, but does not identify a corresponding IoT decision mechanism. (4, 15)
| Date | Documented development | Technical significance |
|---|---|---|
| November 2018 | Explanations of statistical methods and automatic selection | A forecast-model selection service, with candid descriptions of simple models’ limitations. |
| March 2023 | Aggregate forecasting promoted for reducing stockout effects and forecast error | Greater emphasis on smoothing and disaggregation; the treatment of censored demand remains consequential. |
| September 2023 | Forecasting embedded in Demand Driven Technologies’ Intuiflow | The announcement specifies 644 statistical combinations and optional custom machine-learning models. Supply planning belongs to the partner product. |
| September 2024 | External forecast import documented | Customers can compare external forecasts, substitute them for the baseline, or use them as adjustments. |
| January–August 2026 | Product lifecycle automation and forecast-archive guidance | Concrete improvements to maintaining product history and measuring overrides. |
| Current offering | AI baseline generation and API/MCP imports | Machine learning and connectors are Enterprise-tier features; the published operating process still ends with a reviewed forecast. |
Sources: 15, 16, 14, 10, 17, 18, 3.
This history shows sustained development of a fairly coherent forecasting application. It also narrows what the newer AI language establishes. Automatic model selection predates the recent agentic wave; a connector adds another route for moving data into the application. Neither changes the objective from forecast agreement to financial optimization. The useful engineering advances are identifiable in lifecycle handling and forecast evaluation, while evidence of a new autonomous supply chain decision engine is absent.
What the engine calculates
The current product selects among hundreds of statistical and machine-learning combinations using historical backtests, with selection repeated each cycle. Users can forecast individual items or aggregate groups. The public description does not specify the complete model families, validation design, selection loss, or treatment of intermittent and censored demand. Model count alone says little about the improvement over a well-chosen simple baseline. (1)
The September 2024 import guide clarifies that an external forecast can replace the application’s own baseline. That matters when interpreting customer results: a successful planning deployment can validate the application around a forecast without validating the vendor’s forecasting engine. It also gives customers a practical way to compare alternative methods without discarding the surrounding workflow. (10)
Forecast uncertainty is primarily exposed through retrospective errors and bias. The KPI guide recommends selecting a forecast lag corresponding to replenishment or production lead time. This is a useful timing discipline, but a selected lag is not a probability distribution of future lead times. The product documentation supplies no joint distribution of demand, delivery delays, yields, or substitutions feeding a financial ranking of actions. (6, 2)
Aggregation also embeds a specific allocation assumption. The forecast editor distributes an aggregate override using the existing underlying forecast weights for each period, rounds the results, and assigns the rounding remainder to the highest-weight item. This preserves a total. It does not establish which SKU will be wanted, whether customers substitute, or which stock position deserves scarce working capital. (9)
Accuracy: cancellation, stockouts, and decision resolution
SKU Science documents two materially different ways to calculate aggregate error. One sums absolute errors from the lower level; the other aggregates demand and forecasts before calculating error. In its example, the same underlying forecasts produce 607 units of error, or 17%, with the first method and 477 units, or 14%, with the second. The second figure benefits from errors cancelling across items. (7)
Pooling can match a real decision when interchangeable demand draws on the same resource. It becomes misleading when an excess of one product cancels a shortage of another that customers cannot substitute. The deciding question is whether the aggregation preserves the action and its costs. A smaller number on a dashboard does not answer it.
The aggregate-forecast help page says accuracy always improves with larger volumes. Its March 2023 article goes further, promoting aggregation to reduce the effect of stockouts and reporting up to 20% fewer errors for some datasets. Yet a lost sale is missing demand, not symmetric noise. Adding sales from an available location does not reconstruct what customers would have bought at an unavailable one. Grouping can conceal this bias while producing a smoother, easier-to-predict series. (8, 16)
The vendor’s more recent product FAQ recognizes that errors cancel at higher aggregation and that orders are placed on individual SKUs. That is the appropriate constraint on its accuracy proposition. Evaluation should retain the actual item, location, decision horizon, and availability conditions, then measure the financial effects of the downstream decisions. (2)
Forecast Value Added provides another useful control. SKU Science compares manual adjustments against its baseline, preserves the relevant forecast vintages, and exports the underlying actuals and forecasts. However, a positive FVA establishes an improvement over that baseline under the selected metric. It does not establish superiority to a naive alternative or a financial gain after ordering costs, stockouts, and obsolescence. (6)
Productivity, configuration maintenance, and ownership cost
The product automates model selection and administrative work around forecasts. The January 2026 lifecycle module transfers predecessor history and associated segments to successors, including separate channel forecasts. This removes repetitive copying. The relationship still has to be economically appropriate: an apparent replacement can change pack size, customer preference, demand cannibalization, or remaining-stock value. A history transfer does not resolve those changes. (17)
SKU Science’s August 2026 guidance retains the conventional sequence of data collection, demand planning, supply planning, a preparatory meeting, and executive agreement. Its archived forecasts make that process more accountable, but the recurring labor remains centered on reviewing and reconciling forecasts. MCP imports do not remove those meetings or turn their output into automatically selected economic actions. (18, 2)
Configuration includes aggregation rules, KPI thresholds, forecast horizons, access scopes, product relationships, and the interpretation of incoming data. Administrators control data uploads, database resets and restoration, global settings, and forecast launches; standard users can adjust and approve forecasts within their assigned scope. Maintaining these choices requires business ownership, particularly when products or supply arrangements change. The public material describes forecast archives and backups, but no corresponding regression framework that replays operational failures against revised decision logic. (19, 6)
Current annual-billing prices are $349 per month for Launch and $625 for Core, each with one user and 2,500 forecast units; Enterprise has custom pricing. Machine learning, API/MCP access, and advanced user controls sit in Enterprise. Support and onboarding are included. The two-day promise concerns obtaining an initial forecast from uploaded data; a maintained ERP interface and dependable downstream execution add work beyond that milestone. (3)
What customers actually substantiate
Bridgestone Australia describes using SKU Science for a three-year budget across products, customers, and channels. It uploaded its own machine-learning forecasts and used the application for aggregation, editing, and reporting. Data supplied on a Friday was configured by Monday, and training reportedly took less than an hour. This supports rapid deployment of a budgeting workspace; the case gives no measured inventory return attributable to SKU Science’s forecasting engine. (11)
Ocean Spray International Services Australia describes demand forecasting, comparison of sales adjustments, and IBP support. The story includes testing with a sales manager before wider implementation with business partners. It claims improved planning and lower stock and labor requirements without a quantified baseline or evaluation period. Its historical reference to a monthly subscription without commitment also differs from the current annual-billing pricing. (12, 3)
Software materials and security architecture
The published technical inventory is limited but concrete in several places:
| Component or mechanism | Documented role | Assessment |
|---|---|---|
| AWS, Ireland | Hosted application and replicated database | European hosting and replication are specified; database engine and service topology are not. |
| bcrypt; optional two-factor authentication | Password protection and sign-in | Relevant controls; mandatory privileged-user authentication is not described. |
| Six-hour backups | Recovery copies | Recovery time, retention, resistance to administrator compromise, and restore testing are unspecified. |
| Excel/CSV and Enterprise API/MCP | Forecast-data exchange | Integration methods are identified; public connector authorization and operation specifications remain sparse. |
| Application roles and customer-generated support token | User and support access | Scope controls are documented; the support token’s precise authority and lifetime are not. |
The public founder biographies mention previous JavaScript and C++ experience. They do not establish the application’s implementation languages. No current product engineering publication or accessible detailed hiring specification exposes a larger runtime, database, or orchestration inventory. Infrastructure mass and duplication therefore remain unmeasured. (4)
The security page leads with certification and broad assurances. The material engineering questions concern what happens after a user, support account, or service credential is compromised. Multi-user documentation restricts destructive administrative operations, while allowing every role, including read-only users, to generate a support access token. Whether that token preserves the caller’s data and write limits is consequential and unexplained. (5, 19)
The documented customization surface consists of data, forecasts, and configuration rather than practitioner-authored general-purpose code. Its narrower scope avoids the maintenance burden of a customer Python runtime. The remaining concern is whether access and recovery boundaries survive a mistake or compromised credential; encryption and audit badges cannot establish that property. (19, 5)
Financial claims and responsibility for results
The ROI calculator’s default $50 million business has $7.5 million of inventory and a 25% annual holding rate. It presents annual gains of approximately $581,000–$1.969 million. The embedded code calculates recovered sales as 0.6%–3% of revenue and its inventory benefit as 3%–5% of inventory principal plus one year’s carrying cost. No actual forecasting error, margin, replenishment rule, or supplier delay enters this calculation. (20)
This mixes distinct economic quantities. Releasing inventory produces a cash movement once; avoiding carrying costs produces a recurring benefit. Recovered revenue must also pay the costs of the goods sold. Adding these amounts as annual gains overstates what follows from the entered facts. The calculator further omits software and implementation costs. Its reference to a minimum 15%–20% forecast-error improvement does not supply the missing causal model from forecast to action to profit.
The public terms limit aggregate liability to the lower of one monthly subscription or $1,000, exclude lost profits, and disclaim a guarantee that results meet customer requirements. These terms make the asymmetry concrete: the marketing model attributes substantial economic gains to the product, while the published commitment is primarily access to the service. The trial offers a way to inspect forecasts before purchasing, but does not establish responsibility for a disappointing economic outcome. (13, 3)
Supply chain score
Supply chain depth
| Criterion | Score |
|---|---|
| Economic framing | 3/10 |
| Decision end-state | 3/10 |
| Conceptual sharpness on supply chain | 5/10 |
| Freedom from obsolete doctrinal centerpieces | 4/10 |
| Robustness against KPI theater | 4/10 |
Average: 3.8/10.
Economic framing — 3/10. The output is a forecast, while the financial calculator bypasses the actual order policy and conflates capital release with recurring savings. This leaves the economic objective outside the numerical engine. (20)
Decision end-state — 3/10. The documented handoff is an agreed plan to another system. The customer still needs machinery that chooses purchases, allocations, or production quantities and checks their execution. (2)
Conceptual sharpness on supply chain — 5/10. Forecast lag and item-level error are recognized, and the documentation exposes alternative measurement conventions. The stockout argument is weaker: smoothing recorded sales does not recover censored demand. (6, 7, 16)
Freedom from obsolete doctrinal centerpieces — 4/10. Monthly S&OP consensus remains the organizing principle. Better records make that process auditable but preserve its recurring coordination burden and the separation between forecasting and action. (18)
Robustness against KPI theater — 4/10. The published error example exposes aggregation effects rather than hiding them. Claims about improved accuracy and financial gains nevertheless lack a demonstrated bridge to economically better decisions at the operative resolution. (7, 8, 20)
Decision and optimization substance
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 2/10 |
| Distinctive optimization or ML substance | 4/10 |
| Real-world constraint handling | 3/10 |
| Decision automation and labor productivity | 5/10 |
| Resilience under real operational complexity | 4/10 |
Average: 3.6/10.
Probabilistic modeling depth — 2/10. Historical error measurement does not supply the joint future distributions required to price stockout, delivery, and obsolescence risks. The public mechanism remains centered on point forecasts and a selected lead-time lag. (6)
Distinctive optimization or ML substance — 4/10. Automatic historical model comparison is useful and the statistical foundation is intelligible. Model-selection validation and incremental performance over simple alternatives remain insufficiently exposed to establish a distinctive numerical advantage. (1, 15)
Real-world constraint handling — 3/10. The application handles forecast hierarchies and product transitions, but these do not enforce economic trade-offs among shared capacity, order minimums, and material availability. Its partner integration supplies a downstream planning boundary. (9, 14)
Decision automation and labor productivity — 5/10. Lifecycle automation and the Bridgestone budgeting deployment substantiate reductions in repetitive planning work. The evidence does not quantify the remaining total labor of reviewing forecasts and operating the downstream decision process. (17, 11)
Resilience under real operational complexity — 4/10. Forecast vintages permit retrospective diagnosis, and external baselines support method changes. Revising and retesting the economic decision model after an operational failure remains outside the documented improvement loop. (18, 10)
Product and architecture integrity
| Criterion | Score |
|---|---|
| Architectural coherence | 6/10 |
| System-boundary clarity | 7/10 |
| Security seriousness | 4/10 |
| Software parsimony and ownership cost | 6/10 |
| Compatibility with programmatic and agent-assisted operations | 5/10 |
Average: 5.6/10.
Architectural coherence — 6/10. The application has a consistent scope around forecast creation, editing, evaluation, and export. Its modestly documented internals prevent a stronger assessment of data ownership, dependencies, and failure propagation. (2, 5)
System-boundary clarity — 7/10. The external-forecast guide makes clear which numbers can originate elsewhere, and the Intuiflow announcement identifies the complementary supply-planning product. This helps distinguish forecast governance from the system that selects actions. (10, 14)
Security seriousness — 4/10. Administrative restrictions and explicit support-token creation offer concrete controls. Token authority, compromise-resistant recovery, and enforced privilege boundaries need more engineering detail than the certification-led security page provides. (19, 5)
Software parsimony and ownership cost — 6/10. Published subscriptions, included support, and a bounded configuration surface make part of the ownership cost visible. Customer-maintained settings and downstream integration still require testing and staff time; infrastructure costs are not exposed. (3, 19)
Compatibility with programmatic and agent-assisted operations — 5/10. Enterprise connectors and external forecast imports enable automated exchange. Publicly specified agent permissions and operations are sparse, and connecting an assistant does not remove the manual decision stages. (3, 10)
Technical transparency
| Criterion | Score |
|---|---|
| Public technical documentation | 7/10 |
| Inspectability without vendor mediation | 6/10 |
| Portability and lock-in visibility | 6/10 |
| Implementation-method transparency | 7/10 |
| Evidence density behind technical claims | 5/10 |
Average: 6.2/10.
Public technical documentation — 7/10. The help center explains allocation rules, metric choices, role permissions, and baseline replacement in operational detail. Forecast-engine internals and deployment boundaries receive much less treatment. (9, 7, 19, 10)
Inspectability without vendor mediation — 6/10. An advertised self-service trial and accessible guides permit an initial assessment before a sales-led project. Enterprise integrations and numerical validation are not comparably inspectable from the public documentation. (3, 1)
Portability and lock-in visibility — 6/10. Forecast and KPI exports preserve important outputs, while external methods can supply the baseline. Reproducing the full engine and application configuration elsewhere would require additional work. (6, 10)
Implementation-method transparency — 7/10. The editor and multi-user guides describe the mechanics of adjustment and administration. The product also distinguishes an initial forecast from the later path to go-live, making the implementation boundary reasonably clear. (9, 19, 2)
Evidence density behind technical claims — 5/10. Named customer stories substantiate specific planning uses, including imported forecasts. They provide little quantified evidence linking the vendor engine to inventory economics, and public algorithm comparisons remain limited. (11, 12)
Vendor seriousness
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 4/10 |
| Technology roadmap integrity | 6/10 |
| Conceptual sharpness | 5/10 |
| Economic accountability | 2/10 |
| Defensibility in an agentic-software world | 4/10 |
Average: 4.2/10.
Technical seriousness of public communication — 4/10. The statistical explanations are useful, but the aggregation guidance and calculator turn restricted numerical claims into much broader economic promises. The accounting shortcuts are material to the value proposition. (15, 16, 20)
Technology roadmap integrity — 6/10. The historical record shows identifiable developments in integration, lifecycle maintenance, and forecast evaluation. Current AI language is broader than the demonstrated change in decision machinery, but product continuity is clear. (14, 17, 18)
Conceptual sharpness — 5/10. Measuring the value of human intervention is a sound product discipline. Treating forecast performance as the principal target leaves the harder problem of valuing constrained actions and their uncertain consequences unresolved. (18)
Economic accountability — 2/10. The financial proposition is not tied to a measured net-return baseline or an explicit remediation obligation. The public liability limit is very small relative to the gains advertised. (13, 20)
Defensibility in an agentic-software world — 4/10. A maintained forecasting workflow and accumulated domain details have practical value. The strongest opportunity is eliminating recurring decision labor; the current offer largely organizes that labor and adds new data-access routes. (1, 17, 18)
Sources
Source. Accessed November 4, 2026.
[2] Product and operating workflow
Source. Accessed November 4, 2026.
Source. Accessed November 4, 2026.
[4] Company history and founders
Source. Accessed November 4, 2026.
Source. Accessed November 4, 2026.
[6] Forecast KPIs and lead-time lag
Source, 2026-09-16. Accessed November 4, 2026.
[7] Two methods for aggregate forecast KPIs
Source. Accessed November 4, 2026.
Source. Accessed November 4, 2026.
[9] Forecast editor and disaggregation
Source. Accessed November 4, 2026.
Source, 2024-09-24. Accessed November 4, 2026.
[11] Bridgestone Australia customer story
Source. Accessed November 4, 2026.
[12] Ocean Spray Australia customer story
Source. Accessed November 4, 2026.
Source. Accessed November 4, 2026.
[14] Demand Driven Technologies partnership
Source, 2023-09-19. Accessed November 4, 2026.
[15] Choosing a forecasting method
Source, 2018-11-15. Accessed November 4, 2026.
[16] Stockouts and aggregate forecasts
Source, 2023-03-17. Accessed November 4, 2026.
Source, 2026-01-19. Accessed November 4, 2026.
[18] Forecast archiving and S&OP
Source, 2026-08-14. Accessed November 4, 2026.
Source. Accessed November 4, 2026.
[20] ROI calculator and embedded calculation
Source, 2026-09-04. Accessed November 4, 2026.