3 min read

Case Study: Converting a Real Sales Workbook to a Web App

This is a case study, not the general how-to. For the full guide on how to convert excel to a web app, covering every step, the FAQ and when it isn't the right fit, start there instead.

This post walks through one real conversion end to end — a messy 6-sheet sales workbook with three years of regional data — and calls out the parts that actually went wrong, so you know what to expect before you start.

The Starting Point

The workbook had three problems that are common in real spreadsheets, not the clean demo files most tutorials use:

Two sheets had the same metric calculated with slightly different formulas (one included tax, one didn't).
Dates were stored as text in one sheet and as real dates in another.
A "notes" column had free text mixed into what should have been a status field.

None of this is unusual. It's also exactly what breaks naive "upload and auto-generate" conversions, so it's worth fixing before building anything.

What We Fixed Before Building the App

Picked one formula as the source of truth for the metric that disagreed between sheets, and documented which one (tax-inclusive) in a comment on the column header.
Converted every date column to a real date type in the grid rather than leaving mixed text/date formats — this alone fixed three broken chart groupings.
Split the "notes" column into a clean status field plus a free-text comments field, so filters could actually use the status values.

This cleanup took longer than building the dashboard itself — which matches what most teams experience. The full process for a clean workbook is covered on the Excel to Web App page; this is what it looks like when the workbook isn't clean.

Building the App Layer

With the data fixed, the App Builder step was fast: three KPI cards (revenue, margin, units), one trend chart per region, and a filter bar for quarter and product line. We deliberately left the raw sheet out of the published view — the team doing the import needed it, the people viewing the app didn't.

One thing worth calling out: because each original sheet became its own table, the three years of history and the current-quarter sheet stayed as two separate tables instead of one, which made trend charts across years slightly more setup work than a single flat table would have been. Flattening multi-year data into one sheet before import would have saved a step.

What Changed After Publishing

The team went from emailing an updated .xlsx every Monday to publishing a link that refreshes on re-import. Two side effects we didn't anticipate:

Regional managers stopped asking for custom pivot breakdowns by email, because they could filter the app themselves.
One stakeholder initially missed having full row-level access to audit a number — we solved this by keeping a separate, access-restricted raw-data view for the two people who needed it, rather than exposing it to everyone.

Try the Same Process on Your Workbook

For the full step-by-step reference — import, App Builder, publishing, FAQ, and when this approach isn't the right fit — see the Excel to Web App tool and guide.