Procurement software with budgets and approvals, from discovery to shipped screens

The situation

The distributor's customers are dental practices and multi-location groups. In each, an owner wants to control spending without approving every order by hand, staff want to order what they need without waiting, and both have to trust the same number.

The software had to carry budgets, approval rules and orders split across several suppliers. It was being built on an existing product whose brand was half-finished and whose problem and users were only loosely understood, and the distributor was rebuilding its database, order connections and warehouse system at the same time.

Decisions, and why

1. Three ways to show a budget, compared before anything was built. Each was drawn within budget, near the threshold and over it. A budget that looks fine until it is suddenly over teaches people to ignore it. Five days later, two options were revised and the over-budget state was settled.
2. The approval rules written down before a screen was drawn. Which orders pass on their own, which wait for a person, and what a manual approval looks like. With the rules settled, each screen had one purpose: to show the person waiting where the order stands. The cost was time up front.
3. Work within what was already built. The styling was fixed and many components were hard-coded, so a cleaner redesign was possible on paper and not in the code. Every screen used the existing styles, and the effort went into hierarchy and wording.
4. The common path designed well, with room for the rest. The more specific the product became, the more groups it would leave out by accident.
5. The notification emails designed in their templates. The emails were coded templates filled from data, so pictures of emails would not have been enough.

What was made

Discovery findings, option walkthroughs, the logic the approval engine follows, the notifications, and an acceptance test cycle. Sandbucket also trained the distributor's sales team and its customers on the software.

Screens

1. The practice dashboard, with recently ordered and recommended products
2. Optimizing an order, with each item's chosen supplier, the price at other suppliers and suggested alternatives
3. The budget overview for a period: the budget, the total spent and what remains
4. Approvals
5. A purchase order split by supplier, with each supplier's status, shipments and invoices
6. Purchase history, searched to build a practice's own supply list
7. Tracking an order from submit to ship

Images of these screens are added later, with names masked.

Against the four tests

• Ready to compete. Not this project's part.
• Ready to sell. A practice's staff find what they need, see their own prices and other suppliers' prices, and order without calling or waiting.
• Ready to run. An order is split by supplier and tracked from submit to ship, with its shipments and invoices, so no one rebuilds it by hand.
• Ready to scale. Orders within budget pass on their own, so more locations and more orders do not mean an owner approving each one.

What shipped

The software shipped as designed, and its screens are public. Results appear only with the client's written permission.

Not shown: the client's name, its customers and their data, internal figures, and anything not yet released.

See the Build offers