Why I Was Tired of Watching Good Forecasts Lose to Gut Feel

Forecasting usually means waiting on data science or trusting a number in a spreadsheet nobody can reproduce. This puts a real time-series model behind a form: a planner enters a category, a measure and a horizon, and a forecast comes back — running in the warehouse, on governed data.

A planner deciding how much to reorder has two options today, and both are bad. Trust a forecast buried in a spreadsheet that someone built months ago and nobody can quite reproduce. Or file a request with data science and wait days for a model run that’s stale by the time it lands. So most planning happens on gut feel, and the sophisticated model the company invested in sits in a notebook only a few people can touch.

The forecast isn’t the hard part anymore. Getting it into the hands of the person making the reorder decision is.

The Stock Inventory Forecasting app in the Astrato gallery closes that gap. A planner enters a product category, a measure and a time frame, and behind the scenes a Snowpark model returns an advanced forecast — no notebook, no ticket. Here’s what it does, how it’s built, and why running the model in the warehouse is what makes it safe to hand to the business.

Where forecasting gets stuck

Most companies have a forecasting capability. What they don’t have is a way for the people who plan to actually use it.

• The model lives in a notebook. Data science owns it. Planners see an output, weeks later, with no way to run it for the category or horizon they actually care about right now.
• The spreadsheet forecast can’t be reproduced. Someone built it once. The logic is undocumented, the assumptions are baked in, and nobody’s confident enough to change it.
• You can’t ask a different question. Want the next quarter instead of the next month, or one category instead of all of them? That’s a new request, not a new click.
• So planning defaults to gut feel. The sophisticated model the company paid for goes unused, and reorder decisions get made on instinct because instinct is available and the model isn’t.

It’s not a modelling problem. It’s an access problem: the forecast and the planner live on opposite sides of a queue.

See it work

Pick a product category and the measure you want to forecast. Set the time frame. Submit. Behind the form, a Snowpark model runs Prophet — an additive time-series model that fits yearly, weekly and daily seasonality plus holiday effects, and handles missing data and outliers — and the forecast comes straight back into the app. The planner runs an advanced forecast on demand, without writing a line of code or waiting on anyone.

How it’s built

Four steps, on the data you already have:

1. Connect to live warehouse data. Point Astrato at your sales and inventory history in Snowflake. The forecast is trained on live data, not a stale extract, so it reflects what actually just happened.
2. Model the inputs in the Semantic Layer Editor. Define the dimensions and measures a planner chooses from — product category, units, revenue, period — once, so every forecast starts from the same governed definitions.
3. Add the input form. Give the planner an input form to choose the category, the measure and the horizon. The parameters they set drive the run — no code, no config file.
4. Run the model with Snowpark, in place. On submit, a Snowpark UDTF runs the Prophet forecasting procedure inside Snowflake against those inputs and returns the result to the app. The data never leaves the warehouse, and the model isn’t a notebook someone has to babysit — it’s wired into the form.

What changes when forecasting is a self-service data app

Put the model behind a form on live warehouse data and forecasting stops being a data-science deliverable and becomes something planners do for themselves.

• Planners run their own forecasts. Inventory and merchandising teams get an answer for the exact category and horizon they care about, without a ticket.
• It’s reproducible. The same inputs run the same governed model — not a one-off spreadsheet nobody can rebuild.
• “What about next quarter?” is a click. Change the horizon or the category and re-run, instead of filing a new request.
• The model runs where the data is. Snowpark executes inside Snowflake, so a serious time-series model runs on governed data with nothing copied out.
• The investment gets used. Advanced forecasting stops being shelfware and starts informing the reorder decisions it was built for.

Why it holds up

Handing forecasting to planners only works if the result stays trustworthy, and that’s the point of running it this way. The model executes with Snowpark inside Snowflake, so there’s no export and no second copy of the data to secure or let drift. The inputs a planner chooses come from measures defined once in the semantic layer, so every forecast is built on the same governed definitions rather than whatever a spreadsheet happened to contain. And access is inherited from the warehouse, so a planner only forecasts on the data they’re allowed to see. A non-technical user runs a serious model, and the governance underneath never moves.

Make it yours

Open the Forecasting app in your workspace, point it at your own sales history, and give your planners a model they can run themselves. It’s the same input-form-plus-Snowpark pattern behind the Churn Risk app — a business user sets the inputs, a model in the warehouse does the maths, and the governance stays put.

Key takeaways

• A forecast only creates value when the planner making the reorder can run it — the barrier is access, not modelling.
• An input form plus a Snowpark model turns forecasting from a data-science ticket into a self-service click.
• Running Prophet inside Snowflake keeps a serious model on governed data — nothing exported, nothing copied.
• Inputs defined once in the semantic layer make every forecast reproducible and consistent.