How I Built a System That Turns Raw Sales Data Into Business Decisions in A Day

Sai Sarvaja Boominathan — Sun, 12 Apr 2026 17:55:33 +0000

Most companies I've talked to have the same problem. They collect sales data religiously — every transaction, every product, every region — and then it sits in a folder somewhere as a CSV file that nobody opens. Decisions get made based on gut feeling, last quarter's meeting notes, or whoever spoke loudest in the room.
I wanted to fix that. Not with a dashboard that takes six months to deploy. Not with a BI tool that requires a data team to configure. Something anyone could use — upload your data, get answers.
So I built SalesIQ.

What SalesIQ Does
SalesIQ is an end-to-end machine learning system for sales forecasting and business intelligence. You drag and drop a CSV file onto a web dashboard. Within 60 seconds, five real ML models have trained on your data, the best one has been selected automatically, and you're looking at:

Which product generates the most revenue
Which region and sales channel perform best
Which month is your peak sales period
A 30-day forecast of predicted revenue
Downloadable output files for every result

No configuration. No data science knowledge required. No six-month BI implementation.
The system is built on a Flask backend, a Python ML pipeline using scikit-learn and XGBoost, and a plain HTML/JavaScript frontend. Everything runs locally — your data never leaves your machine.

The Problem With Most ML Projects
Here's what bothered me about most machine learning tutorials and projects I'd seen. They train a model. They print accuracy scores. They stop there.
That's not useful to anyone outside a Jupyter notebook.
A business manager doesn't know what R² means. They don't care which algorithm won. They want to know: should I order more inventory next month? Which product should I push in my next marketing campaign? Where am I losing money?
I decided the output of my ML system had to answer those questions directly — in plain English, from the user's actual data columns — not just print model metrics on a screen.

How the Pipeline Works
The system runs eight steps in sequence every time a file is uploaded.
Step 1 — Data ingestion. Flask receives the CSV upload and saves it. Any existing output files are cleared so the new data gets a completely fresh analysis.
Step 2 — Cleaning. The pipeline strips currency symbols, removes negative values, parses dates in any format, and validates required columns. Real sales data is messy. This step handles that without asking the user to pre-clean anything.
Step 3 — Exploratory Data Analysis. The system calculates total revenue, mean, median, standard deviation, and outliers using the IQR method. It groups sales by month and by category and saves summary CSVs automatically.
Step 4 — Feature engineering. This is where raw data becomes something a model can actually learn from. From a single date column and revenue column, the pipeline creates 33 features:
python# Lag features — what were sales 1, 7, 14, 28 days ago?
for lag in [1, 2, 3, 7, 14, 21, 28]:
feats[f'lag_{lag}'] = daily[target].shift(lag)

Rolling statistics — moving averages and volatility

for window in [7, 14, 30]:
feats[f'roll_mean_{window}'] = daily[target].shift(1).rolling(window).mean()
feats[f'roll_std_{window}'] = daily[target].shift(1).rolling(window).std()

Cyclical date encoding — so December and January feel close together

feats['month_sin'] = np.sin(2 * np.pi * feats['month'] / 12)
feats['month_cos'] = np.cos(2 * np.pi * feats['month'] / 12)
The cyclical encoding was something I spent time thinking about. If you encode month as a raw integer (1 through 12), the model sees December (12) and January (1) as far apart. But seasonally they're adjacent. Sine and cosine encoding fixes that.
Step 5 — Model training and evaluation. Five models train on 80% of the data and are tested on the remaining 20% — in time order, without shuffling. Shuffling would be cheating. If you train on future data and test on the past, your accuracy scores are meaningless.
python# Time-series split — NO shuffling
split_idx = max(int(len(X) * 0.8), len(X) - 50)
split_idx = min(split_idx, len(X) - 10)
X_train, X_test = X.iloc[:split_idx], X.iloc[split_idx:]
y_train, y_test = y.iloc[:split_idx], y.iloc[split_idx:]
The five models are Linear Regression, Ridge Regression, Random Forest, Gradient Boosting, and XGBoost. Each gets evaluated on R², MAE, RMSE, and MAPE. The best one is selected automatically.
Step 6 — Forecasting. The best model generates predictions for the next 30 days using recursive forecasting — each day's prediction becomes a lag feature for the next day's prediction.
Step 7 — Business insights. This is the part I'm most proud of. Instead of showing R² scores to a business user, the system reads the actual columns from their data and generates plain-English insights:
python# Top product from real data
cat_rev = df.groupby(cat_col)[sales_col].sum().sort_values(ascending=False)
insights['top_product'] = {
'name': str(cat_rev.index[0]),
'revenue': round(float(cat_rev.iloc[0]), 2),
'pct': round(float(cat_rev.iloc[0]) / total * 100, 1),
}
So instead of "MAPE = 84.5%", the dashboard shows "Electronics generated $1.2M — 34% of your total revenue." That's something a manager can act on.
Step 8 — Output files. Eight files are saved automatically: predictions CSV, model scores, feature importance, 30-day forecast, a full JSON payload for the dashboard, EDA charts, ML result charts, and a plain-text business report.

What the Dashboard Shows
The frontend is split into two sections deliberately.
The top section is for business users. It shows KPI cards (total revenue, average transaction value, 30-day forecast total, trend percentage), six business insight cards pulled from the real data columns, a monthly revenue trend chart, a category revenue donut chart, and the 30-day forecast table.
The bottom section — hidden by default behind a collapsible toggle — is the technical detail. Model comparison bars, feature importance, actual vs predicted chart, download buttons. It's there for internship evaluators and technical stakeholders. Business users never need to open it.
I made this decision deliberately. A dashboard that shows R² scores to a sales manager is a dashboard that doesn't get used.

What I Learned
Feature engineering matters more than model selection. On clean, well-featured data, Linear Regression often outperforms XGBoost. The model is only as good as what you feed it. I spent more time on lag features and cyclical encoding than on model tuning, and that was the right call.
The output layer is the hardest part. Training a model takes 10 lines of code. Making the output actually useful to someone who isn't a data scientist took most of the project. The business insights builder — the code that reads actual column names and generates plain-English summaries — was the last thing I built and the thing I'm most satisfied with.
Time-series splits are non-negotiable. Every tutorial I found used random train-test splits. That's fine for image classification. For time-series data it's completely wrong. If your model trains on data from March and tests on data from January, the accuracy score you report is fictional. The split has to respect temporal order.
Real data is messy in ways synthetic data isn't. The generated demo dataset worked perfectly on the first run. The first real CSV I tested had currency symbols in the revenue column, dates in three different formats, and two completely empty columns. The cleaning step had to handle all of that gracefully before a single model could train.
Separation of concerns between business and technical output is a design decision, not an afterthought. I almost shipped with the model comparison table as the primary output. I changed it because I thought about who would actually use the system. That question — who is this for, and what do they need to see — should come before the first line of code.

Results
On the 2,000-row sales dataset I generated for testing, Random Forest achieved the highest R² score and was selected as the best model automatically. The full pipeline — upload, clean, feature engineering, train five models, generate forecast, extract business insights — completes in under 60 seconds on a standard laptop.
The 30-day forecast generates predictions with confidence scores that decrease incrementally over the forecast horizon, which is honest — uncertainty compounds the further out you predict.

What's Next
The system currently runs locally. The next step is deploying it as a hosted service so anyone can upload a CSV without setting up a Python environment. I also want to add anomaly detection — flagging weeks where sales dropped significantly and explaining likely causes based on the feature importance scores.
If you want to see the code, it's all straightforward Python — Flask, pandas, scikit-learn, XGBoost, matplotlib. No exotic dependencies. The whole system runs on a standard laptop with 8GB of RAM.
The gap between "we have sales data" and "we make data-driven decisions" is mostly a tooling problem. SalesIQ is my attempt to close that gap for teams that don't have a data science team.

Built with Python, Flask, scikit-learn, XGBoost, and plain HTML/JavaScript.``

Forem: Sai Sarvaja Boominathan

How I Built a System That Turns Raw Sales Data Into Business Decisions in A Day

Rolling statistics — moving averages and volatility

Cyclical date encoding — so December and January feel close together