Most companies don't decide to build an order portal because someone had a vision. They build one because the spreadsheet finally broke under its own weight. This guide walks through why that happens, what a portal actually replaces, and how to roll one out without stalling on data cleanup. It draws on an anonymized build Pacific Media Marketing did for a US office-hardware manufacturer.
The before state: Excel, SharePoint, Outlook, repeat
Before the build, each order moved through three tools and several people. A sales rep took the order and typed it into an Excel sheet. That sheet got uploaded to SharePoint so design and logistics could see it. Questions and approvals happened over Outlook threads, often forked across multiple emails with slightly different subject lines.
At each handoff, someone retyped part of the order — into a new Excel tab, into a separate tracking sheet, into a shipping label. Retyping is where errors enter: a transposed digit in a part number, a dropped custom spec, a quantity that gets rounded differently by the second person who touches it.
Two problems compound from there:
- Status questions cost real time. "Where is order 4021?" has no single answer, because the order lives in someone's inbox, a SharePoint version, and maybe a sticky note on a warehouse desk. Answering that question means pinging three people.
- Version conflicts happen constantly. SharePoint keeps file versions, not order versions. If sales edits a spec while logistics is packing from an older copy of the sheet, nobody notices until the wrong item ships.
None of this is a failure of the people involved. It's what happens when a process outgrows the tool it started on.
"The spreadsheet wasn't the problem. Five people editing five copies of it was."
Design decisions, and why we made them
A portal isn't just "the spreadsheet, but a website." Every design choice below exists to remove a specific failure mode from the old process.
Single order record as the system of record. Instead of a file that gets copied and edited in parallel, each order is one row in one database, with one current state. Sales, design, logistics and inventory all look at the same record. There is no "which version is correct" question, because there is only one version.
Roles vs. permissions, not one shared login. Sales, design, logistics, inventory and admin each get their own login and see only what their job requires. This isn't about restricting people for its own sake — it's about making the interface simpler for each team and making the audit log meaningful (see below).
Auto-resolving part numbers instead of free text. In the old process, part numbers were typed by hand into Excel. A smart product picker looks up real catalog entries and resolves the part number automatically, instead of letting someone type "similar to last time" into a cell. This is the single biggest source of order errors we see in manual systems, and it's fixable with a picker tied to a real catalog.
Splitting standard from custom routing. Standard orders and custom orders have different approval needs. Routing them differently means standard orders move fast with minimal friction, and custom orders get the extra design and engineering review they actually need — without slowing down the 80% of orders that don't need it.
Approval gates as explicit states, not email chains. Each team's sign-off is a one-click action tied to a specific state on the order (submitted, approved by design, approved by logistics, packed, shipped). This replaces the Outlook thread where approval is implied by someone replying "looks good."
An audit log for accountability. Every state change, edit and approval is logged with who did it and when. This isn't about blame — it's what lets someone answer "who approved this and when" in ten seconds instead of digging through email.
No-code catalog admin. Products, options and prices change. If every change requires calling the developer, the catalog goes stale and people go back to editing it in Excel "just this once." A CSV import/export screen means the client's own team keeps the catalog current without being dependent on us.
What replaced what
| Old step | Who did it | What replaces it in the portal |
|---|---|---|
| Type order into Excel | Sales rep | Order entry form with product picker |
| Look up part number by memory or old sheet | Sales rep | Auto-resolving part picker tied to catalog |
| Upload sheet to SharePoint | Sales rep | Automatic — order is already in the system |
| Email design/logistics for sign-off | Sales rep, design, logistics | One-click approval gate per team |
| Track "did they see it yet" | Whoever is waiting | Order status visible to all roles in real time |
| Build packing list by hand | Warehouse staff | Packing list with QA and packed columns |
| Update inventory sheet after shipping | Inventory admin | Inventory dashboard with low-stock flags |
| Answer "where's my order" emails | Anyone available | Shipment tracking visible on the order record |
| Reconcile who approved what | Admin, after the fact | Full audit log |
A phased rollout that doesn't stall the business
Trying to launch a portal for every product line and order type at once is how these projects stall for months. A phased rollout works better:
- Phase 1 — narrow scope. Pick 3 products and one order type (usually standard, not custom). Run the portal in parallel with the old Excel/email process for those orders only. Done means: every order of that type, for those 3 products, goes through the portal end to end, and the team trusts the status shown is accurate.
- Phase 2 — widen the catalog. Add the rest of the standard catalog. Keep custom orders on the old process a little longer if custom routing needs more approval logic. Done means: all standard orders run through the portal, and the old spreadsheet is no longer the source of truth for them.
- Phase 3 — add custom routing and reporting. Turn on the custom-order path with its extra approval gates, and turn on reporting for management. Done means: no order type still depends on the old Excel/SharePoint/Outlook loop.
Each phase should have an exit condition someone can actually check — not "when it feels ready."
What to prepare before the build starts
The single biggest source of delay on a project like this is not the software. It's the parts list.
- A full parts export: every part number, every option, every price. If this lives in three sheets that don't agree with each other, resolve that before development starts, not during it.
- A role list: who needs a login, and what team they're on (sales, design, logistics, inventory, admin).
- Approval rules: who needs to sign off on what, and in what order.
- Email templates: what notifications should say, so they don't get built twice.
- A sample of historical orders: enough real orders to test the picker and routing against real-world messiness, not a clean demo case.
A messy parts list delays everything downstream, because the product picker can only auto-resolve part numbers that are accurate and unambiguous in the source data. Cleaning this up is unglamorous work, but it's cheaper to do before a build than during one.
Common mistakes to avoid
- Rebuilding the spreadsheet exactly. If the portal just recreates every column and quirk of the old sheet, it inherits the old sheet's problems.
- Too many required fields. Every mandatory field is a reason sales stops using the tool and goes back to email.
- Skipping the audit log. It feels optional until the first dispute about who approved what.
- No low-stock rules. An inventory dashboard without alert thresholds is just a nicer-looking spreadsheet.
Where to start
If your team recognizes the before state above, the fastest low-risk next step is an Ops Teardown: a 60-minute recorded review of your current workflow, with a map of the three highest-ROI automations and a fixed-price quote, delivered in 5 business days and credited toward a build if you move forward. You can see how this played out in a related build at /work/order-approval-portal, and read more about how we scope this kind of project at /services/custom-software. If you're ready to talk specifics, contact us.
Notes
This article draws on an anonymized build by Pacific Media Marketing for a US office-hardware manufacturer. No outcome figures, client names or third-party statistics are cited.