Industrial
Three-warehouse inventory and requisitions in Notion for an industrial company
An active Notion build: inventory across 3 warehouses, a requisition form wired into the data, and 3 area dashboards for an industrial company.
3
warehouses unified into a single inventory system
3
area dashboards, each showing what its team needs
Sprint 2
training starts before the build wraps up
Project in active implementation; kickoff in July 2026.
An industrial company running three warehouses hired us to build its inventory and requisition system on Notion: connected databases for all three warehouses, a requisition form that feeds those databases directly, and three area dashboards, each showing exactly what its team needs. The project is in active implementation — kickoff was July 2026 — and that is how we present it: real scope, real status, no invented results.
The challenge
Three warehouses means three versions of the truth. When material comes in through one door, leaves through another, and every department requests supplies through its own channel, the simplest question — what do we have, and where is it? — ends up costing phone calls, emails, and the memory of whoever “just knows.” This project exists to fix exactly that: one source of truth for stock and requests, visible by area, with no middlemen.
How it will work, in three acts
Act 1 — A requisition stops being a message. Someone on the floor needs material. They open the requisition form — not a chat, not an email — and the request lands in the database, tied to the right warehouse, with requester, date, and status visible from the first second. Nothing gets buried in an inbox.
Act 2 — Every area gets its own board. The warehouse lead opens their dashboard and finds stock levels and pending requisitions without asking anyone for a report. Three custom dashboards, one per area: each team sees what concerns them, at the depth that concerns them. The full picture stops depending on stitching spreadsheets together by hand.
Act 3 — The team keeps the keys. Training begins at the close of Sprint 2 and goes beyond “here’s how to use it”: it includes hands-on creation of custom views — a delivery calendar, for instance — so the team can adapt and extend the system without calling us. That expanded training scope was the client’s own request, and we read it as the best possible signal: they want to own their tool.
How it is being built
The project runs in sprints on Notion Enterprise, which the client activated from the start; admin access was granted during the kickoff session itself, with no weeks of paperwork in between. The scope was closed in writing: inventory databases for the three warehouses, a requisitions database, the integrated form, three area dashboards, and an initial data load bounded to a known volume (up to ~200 records per database). Working in sprints keeps the build inspectable: the client sees functioning databases as they land, not a big reveal at the end.
What the project does not include was written down just as clearly: integrations with external systems and post-delivery support are explicitly out of scope. We would rather commit to an honest, deliverable scope than to an elastic promise nobody can audit later.
Where it stands
Under construction — and we are not shy about saying so. Kickoff was July 7, 2026; the system is being built sprint by sprint, and training is already scheduled inside the plan itself. Once measured results exist — requisition turnaround, inventory accuracy — we will update this case with those numbers and their dates.
Publishing a project in progress, with its real scope, strikes us as a better calling card than three metrics no one can verify. If any fact on this page changes, the page changes.
Running more than one warehouse?
If your inventory is spread across warehouses and requisitions travel by message, there is a design that can bring it to order. Book a 30-minute session and we will look at your case — with explicit scope, like this one.