SmartLink
AI & automation

Demand forecasting and analytics models in Pakistan

Demand forecasting in Pakistan is usually bought after a season where the warehouse held the wrong stock and everybody agreed something should be done. SmartLink Services builds forecasting and analytics models from Karachi in Python, on your own transaction history, and every model ships with a backtest against a stated baseline plus an accuracy report that keeps running after handover. Below is the commercial detail. Why a price cannot be quoted from a brochure, what a pilot costs and settles, how long the work takes once the history is extracted, and the case in which the naive baseline already beats anything we could build for you.

Discuss this service
Cases
Demand \u00b7 inventory \u00b7 cash
Validation
Backtest on history
Tracking
Accuracy vs actual
Overview

A forecast that has not beaten the naive one is not yet a forecast.

Forecasting projects fail in a specific way. A model is built, it produces plausible numbers, everyone is impressed by the charts, and nobody ever checks whether it is better than what the planner was already doing. Months later the planner is overriding it routinely and the model has become an expensive suggestion. The remedy is unglamorous and it is the first thing we do: establish the naive baseline and hold every subsequent model to beating it.

The baseline is usually last period repeated, or the same period last year, or a moving average. It costs nothing to compute and it is surprisingly hard to beat on noisy, short or intermittent series. If a complex model cannot beat it on a fair backtest, that is a finding worth having, because it means the honest answer is to keep the simple rule and spend the budget on data quality, lead times or a process problem instead.

Where a model does earn its place, it ships with the apparatus that keeps it honest: a backtest on held out history using rolling origins, error measured with a metric appropriate to the series, documented assumptions, and continuing comparison against actuals once it is live. Forecasts degrade as conditions change, and a model nobody is measuring will keep producing confident numbers long after it stopped being right.

Scope

What Forecasting & analytics models covers

Everything below is agreed in writing before any ai solutions work starts, so both sides know what is in and what is not.

What the work covers

  • Historical data assessment and feature preparation
  • Baseline statistical model before any complex approach
  • Model training, backtesting and error analysis
  • Scenario and sensitivity analysis for planners
  • Integration of output into planning systems
  • Ongoing accuracy monitoring and drift alerts

What you get at handover

  • Backtest report with error metrics
  • Deployed forecast pipeline
  • Planner-facing scenario dashboard
  • Model documentation and assumptions
  • Accuracy monitoring dashboard

Typically involves

scikit-learn Prophet SQL
Discuss this service
01

The baseline and a fair backtest

A backtest that looks good is usually a backtest with a leak. The model saw a future value through an aggregated feature, or the training and test periods overlapped, or a promotion flag was populated retrospectively in a way that would never be available at prediction time. Each of these produces flattering results that evaporate in production, and each is easy to introduce by accident. The discipline is to reconstruct exactly what would have been known at the moment of forecasting.

Rolling origin evaluation is the practical form of that. Fit on data up to a point, forecast forward over the horizon you actually need, step forward and repeat across the history, then compare against the naive baseline over the same windows. Metric selection matters too: mean absolute percentage error behaves badly around small and zero values, which is precisely where intermittent demand lives, so a scaled or weighted absolute measure is usually more informative.

The comparison has to happen at the grain and horizon that matter. A model accurate at national level in monthly buckets tells you nothing about whether it can support weekly replenishment at a single location. Accuracy generally improves as you aggregate, which is why aggregate figures are the ones that get presented in review meetings. We report at the grain the decision is actually taken, even when the number is less comfortable to show.

  • A naive baseline computed first and used as the standard every model must beat
  • Rolling origin backtesting that reconstructs only what was known at prediction time
  • Feature availability checked, so nothing leaks information from the future
  • Error metrics chosen for the series, avoiding percentage errors on small or zero values
  • Accuracy reported at the grain and horizon of the real decision, not a flattering aggregate
02

History that lies: stockouts, promotions and restated master data

Sales history is not demand history. When an item was out of stock, sales fell to zero while demand did not, and a model trained on that data learns to forecast the stockout rather than the demand. Substitution hides it further, because the customer bought something else and that line now looks stronger than it is. Unless stockout periods are identified and handled, the model will confidently recommend holding too little of exactly the things that sell.

One off events cause the same trouble in the other direction. A large tender, a promotion, a price change, a competitor's supply failure, a packaging change that split one product into two records. Each leaves a spike or a discontinuity a model will happily extrapolate. Somebody who was there has to annotate them, which is why this part of the work is done with your planners rather than from the data alone. They remember what the table cannot show.

Master data changes are the quiet version of the same problem. Product hierarchies get restated, locations merge, a customer is reorganised into two accounts, and the history for a level of the hierarchy becomes discontinuous with no obvious sign. We check for it before modelling, because a forecast built across a restatement is wrong in a way that is very hard to diagnose later, and the usual conclusion drawn is that the model is bad rather than the history.

  • Stockout periods identified and treated, so censored sales are not read as true demand
  • Promotions, tenders and price changes annotated with help from the people who remember them
  • Product and location hierarchy restatements checked before any model is fitted
  • Series with short or intermittent history flagged and handled differently from stable ones
  • Data problems reported as findings in their own right, since some are worth more than the model
01

What a forecasting model costs in Pakistan

There is no published price band for this work and there should not be, because the effort is set by the state of your history rather than by the number of items you sell. Forecasting weekly demand for four hundred stable products with six years of clean transactions is a straightforward engagement. Forecasting the same four hundred through two system migrations, a rebranding that renamed half the catalogue and a year when the plant closed for six weeks is a data archaeology project with a model at the end.

Rates are the honest comparison. Published figures for Pakistan put full stack development at PKR 3,500 to 8,000 an hour with senior specialists at the top of that band, and junior work at PKR 500 to 1,000. Where the engagement is scoped as a project rather than staffed by the hour, custom web application pricing at PKR 200,000 to 1,000,000 and upwards is the nearest published comparator, and it fits because most of the delivery is software: an extraction, a pipeline, a dashboard planners actually open, and monitoring that keeps reporting error against actuals.

Three things move the figure. History quality is the first and the largest, since features cannot be prepared from a table where a promotion was never recorded and a stockout looks identical to genuine low demand. The decision the forecast serves is the second: a number that sets a purchase order needs different confidence from a number that informs a conversation, and one of those requires far more validation than the other. Delivery of the output is the third, because a forecast that lives in a notebook on an analyst's laptop changes nothing, and pushing it into a planning system is integration work with the usual costs.

Two lines continue after go live. Retraining on a cadence somebody owns, and the monitoring that says when the model has drifted away from reality. We scope a pilot on one category or one site first, price the build once the backtest exists, and quote a real figure only after discovery.

  • Effort set by the state of the history rather than by the number of items forecast
  • Rates compared against published PKR 3,500 to 8,000 full stack figures for this market
  • Promotions, stockouts and master data changes identified before features are prepared
  • Delivery into a planning system costed as integration rather than assumed
  • Retraining and drift monitoring budgeted as a continuing line after handover
02

How long a forecasting project takes

Reported timelines give six to twelve weeks for a focused single scope go live, and a forecasting pilot on one category or one site fits that band. Three to six months is the honest range once several categories, a planning system integration or a second data source are in scope.

Extracting the history is the first item and it is rarely quick. Several years of transactions from a production database needs a named owner, an agreed window and sometimes a legal view on what may leave the environment. Where the ERP was replaced at some point, the older years live somewhere else in another shape, and joining the two is a decision about what to trust rather than a technical exercise.

Understanding the history is the second and it is where the weeks actually go. The six weeks the plant was closed. The quarter a discount code was miscoded so revenue looks like demand. The item created twice under two codes and sold under both. A model trained without that context learns your accidents and forecasts them faithfully into next year.

Then the backtest, which cannot be hurried because it has to be honest. Walk the model forward through history the way it would have been used, compare it against the naive baseline on the same periods, and report the error rather than a chart of fitted values. We say plainly when the answer is that the history cannot support a model, and we say it before the invoice rather than after.

  • Six to twelve weeks reported for a focused pilot on one category or one site
  • Three to six months once several categories or a planning integration are in scope
  • History extraction scheduled with an owner, a window and a view on what may leave
  • Promotions, closures and miscoded periods identified before training rather than after
  • A walk forward backtest against a stated baseline, reported as error rather than as a chart
03

When the naive baseline already wins

Every forecasting engagement should start by building the dullest possible forecast and measuring it. Last week repeated. The same week last year. A moving average over the last eight weeks. These take an afternoon, they cost nothing, and on a surprising share of real product ranges they are hard to beat. A model that cannot beat them is not a forecast, it is an expensive way of saying the same thing with more confidence.

Certain patterns favour the baseline and it is worth recognising them before spending anything. Demand that is genuinely stable week to week. Ranges with very few items and very long intervals between orders, where each sale is close to an event rather than a trend. Products launched this quarter with no history to learn from at all. A business whose ordering is driven by two large customers whose plans are known in advance, in which case the correct instrument is a telephone call rather than a model.

There is a second case that gets missed. Sometimes the forecast is accurate and nothing improves, because the decision it feeds was never actually made on the forecast. Where a buyer orders in supplier minimums, or a container size sets the quantity, or the lead time is longer than the horizon you can predict, a better number changes nothing at the point of decision. We ask which decision improves and by how much before scoping anything, and if that question has no clear answer the honest recommendation is to stop.

So the baseline is where we start and it stays in every report afterwards, including the ones written a year later. The value of a model is only ever what it adds over that baseline, measured on periods it never saw during training, and that difference is what we report to a client rather than a headline accuracy figure that flatters everybody. Where the difference is small, we will say so and recommend spending the money on cleaner master data or a shorter replenishment cycle instead, both of which tend to improve a plan more reliably than a better forecast does.

  • A naive baseline built and measured first, and kept in every report afterwards
  • Stable demand, sparse ordering and new products recognised as poor candidates
  • The decision the forecast serves identified before any model is scoped
  • Model value reported as the gain over the baseline on periods it never saw
  • Master data or a shorter replenishment cycle recommended where the gain is small
How we deliver

Delivering Forecasting & analytics models

One process, a cost in hours today, and a target that can be measured afterwards. These six steps add something the other practices do not need: an evaluation set built before anybody writes a prompt.

  1. 01

    Discover

    Volume, consistency, how an answer would be checked, and what a wrong one costs. We also give a capable person the same documents as a control, because if they cannot produce the answer, no model will.

  2. 02

    Blueprint

    A few hundred real cases with agreed correct answers, assembled with the people who do the work now. Where two experienced reviewers disagree, that is an undocumented rule, and it gets settled here.

  3. 03

    Build

    Extraction, validation against the purchase order or master record, confidence thresholds and the exception queue are built together. Retrieval is filtered by the asking user's existing permissions, never after the answer is generated.

  4. 04

    Test

    The evaluation set is run and scored against the human baseline, per document type, so you can see where accuracy holds and where it does not. Thresholds are set from that, not from a default.

  5. 05

    Go live

    Live on one process, with cost budgets and alerts already configured, exception owners named, and a written route back to the manual process that the people who would use it have rehearsed.

  6. 06

    Run

    Re-run the evaluation set on a schedule and after any model or prompt change, because a supplier redesigning an invoice can degrade accuracy quietly. Below the agreed threshold, the automation pauses.

Working together

When the answer is not a model

A good share of forecasting enquiries are better answered without a model. If master data is unreliable, if lead times are recorded as an aspiration rather than as observed fact, if two systems disagree about what was sold, then no algorithm will produce a trustworthy number from that input. We would rather spend the first engagement establishing that and fixing the data than build something which inherits the problem and disguises it behind a chart.

Where the data supports it, the work is straightforward and the discipline is what matters: an honest baseline, a fair backtest, an output shaped around the decision, and measurement that continues after go live. That produces a forecast a planner will actually use, which is a considerably more useful outcome than one that scores well in a presentation and is quietly ignored by March.

Credentials

Accreditations behind AI solutions

AI work reads from systems that already exist, so most of what follows is about the data platform underneath and the terms under which data moves.

Oracle

Partner

The data an assistant or forecast reads usually sits in Oracle. We build the extract views, document the schema, and use AI Vector Search in 23ai where retrieval belongs next to the data.

Microsoft

Partner

Azure hosts the processing where residency requires it, Power BI carries forecast output to the people who act on it, and SQL Server is often the source the model reads history from.

Google

Partner

Document AI handles the first pass on scanned and photographed invoices where layout varies, and Google Cloud gives a stated processing region when a document set cannot leave a jurisdiction.

FBR digital invoicing

Compliant integrations

Supplier invoices read automatically still have to reconcile to what was reported. Extracted sales tax values are checked against the purchase order and the return, with mismatches routed to a person.

HIPAA

Compliant practices

Clinical and claims documents are processed under a business associate agreement, with identifiers redacted where the task does not need them and provider terms that exclude training on your content.

Client words

What AI solutions clients say

Comments from people who run ai solutions systems day to day.

  • The handover was the part I judged them on. Configuration decisions documented with the reasoning, our administrators trained properly, and a checklist we actually worked through. We run it ourselves now, and calling them is a choice rather than a necessity.
    Head of Shared Services Multi site manufacturing group
  • What sold us was that they argued with our brief. We asked for a reporting layer and they came back saying the reporting was fine, the batch data underneath it was not, and fixing that first would cost less. That turned out to be right. Our first mock recall after go live took an afternoon instead of the better part of a week.
    Finance Director Food manufacturing group, Karachi
  • We had been through one failed implementation already, so we were sceptical of the whole category. The difference here was the migration work. Two full rehearsal loads before the real one, with a reconciliation pack we could check ourselves. Nobody had ever handed us evidence like that and asked us to sign it.
    Head of IT Wholesale distribution business
Questions

Questions about Forecasting & analytics models

There is no published band, because effort follows the state of your history rather than the number of items. Rates give the comparison: full stack work here is quoted at PKR 3,500 to 8,000 an hour, and custom web application pricing of PKR 200,000 to 1,000,000 and upwards is the nearest project comparator, since most of the delivery is software. We price a pilot first, then the build.

Reported timelines give six to twelve weeks for a focused pilot on one category or one site, and three to six months once several categories or a planning system integration are involved. Extracting the history and then understanding it take most of that. Promotions, closures and miscoded periods have to be found before a model is trained on them.

Enough to see the pattern repeat, which for seasonal demand means several complete cycles rather than a number of rows. Two or three years of weekly transactions is a reasonable starting point for most product ranges. More matters less than clean: three tidy years with promotions and stockouts recorded beat seven years that were migrated twice and never reconciled.

Nobody can answer that before seeing your data, and a supplier who does is guessing. Accuracy is measured against a naive baseline on periods the model never saw, and reported as the gain over that baseline rather than as a headline figure. Some ranges improve substantially and some barely move. We report both, including the categories where our model lost.

Not from its own history, because there is none. What can be done is forecasting by similarity: attributes, category behaviour and the shape of previous launches, treated as an estimate with wide uncertainty rather than a number to order against. That is worth having and it is worth labelling honestly, so a planner knows which figures on the screen deserve their confidence.

Reports describe what happened and are usually accurate. A forecast estimates what will happen and is always wrong by some amount, so the useful question is by how much and whether that beats the assumption you use today. The other difference is accountability: a forecast ships with a measured error and a monitor that says when it has drifted.

More in AI solutions

More AI solutions services

AI & automation

AI document processing

Invoices, purchase orders, delivery notes and forms read automatically into your ERP.

Open service page → AI & automation

AI assistants over enterprise data

Question-answering assistants grounded in your documents and ERP data, with permissions respected.

Open service page → AI & automation

Process automation

Rule-based and AI-assisted automation of the approvals and reconciliations that eat staff time.

Open service page → AI & automation

AI integration & governance

AI capability connected into existing applications, with cost, access and audit control.

Open service page →

Planning against a number nobody has tested?

Tell us what you run today and where forecasting & analytics models is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All ai solutions