Fulfillment
Order approval, manual fulfillment and service-order lifecycle for MSPs who sell hardware and services to their clients from one system.
The problem
A client emails asking for eight laptops. Someone prices them in a spreadsheet, someone else approves the spend in a reply-all, the order goes to a distributor, and the tracking number lands in a technician’s inbox. Two weeks later, nobody can say whether that order was ever invoiced — because the only record that it shipped is a sentence in a thread. The same fog covers services: the managed service was sold, delivered, and never billed, because “sold” lived in a CRM and “delivered” lived in someone’s head.
What Solidlio does about it
Solidlio makes the order itself the record. A client places an order in the MSP’s own store; it arrives as PENDING_APPROVAL and the MSP approves or rejects it in one click. From there the MSP walks it forward — Processing, Shipped, Delivered — attaching a carrier and tracking number as they go, and every step is visible to the client on their own order page in real time. Reaching Delivered is what makes a net-terms order invoiceable, so the nightly invoicing run bills exactly the orders that actually arrived, once each. Service sales run the same way through a single ServiceOrder record covering direct sales, marketplace resales, support blocks, projects, managed services and escalations, with revenue and platform fees calculated as the order moves.
Capabilities
| Capability | What it does |
|---|---|
| Order approval queue | Client orders arrive awaiting approval; approve or reject with a reason that is written to the order |
| Forward-only fulfillment | Advance an order through Processing → Shipped → Delivered; no step can be undone or skipped backwards |
| Carrier and tracking capture | Attach a carrier and tracking number at the shipping step; both surface on the client’s order page |
| Client-visible order timeline | Placed, Approved, Processing, Shipped, Delivered — with dates — in the client’s own portal |
| Mobile order tracking | Customer and Organization users can review their web order status, items, carrier, tracking number and delivery milestones |
| Automatic milestone stamping | Ship date and delivery date are recorded the first time an order crosses each line, never overwritten |
| Delivered-triggers-invoice | The nightly run invoices every delivered net-terms order; a unique invoice link makes double-billing impossible |
| Tax-hold safety | An order whose Canadian tax jurisdiction cannot be resolved is held, never invoiced at zero tax |
| Service order lifecycle | Draft → Approved → Completed for direct sales, marketplace resales, support blocks, projects, managed services and escalations |
| Server-side pricing | Subtotal, discount, tax, total and platform fee are computed on the server and floored at zero |
| Revenue analytics | Revenue by month, by order type, by service and by client, plus a full platform-fee ledger |
| Buyer isolation | A client sees only their own organization’s orders; a sibling client’s order returns “not found” |
| Fulfiller attribution | Every fulfillment step records the user who performed it |
Built for MSPs and their clients
Fulfillment is two-sided by design. The client places and watches; the MSP decides and moves.
| Client organization | MSP | |
|---|---|---|
| Placing an order | Places orders from the MSP’s store | Sets the catalogue and the client’s prices |
| Approval | Waits — sees “Pending approval” on their order | Approves or rejects with a recorded reason |
| Fulfillment | Watches the timeline advance | Advances Processing → Shipped → Delivered and attaches tracking |
| Visibility | Own organization’s orders only | Every order in the account; can filter to any client org |
| Billing | Receives the invoice once the order is delivered | Delivery is the trigger; the invoicing run does the rest |
How it works
- The order arrives. A client places an order in the MSP’s store. It lands as Pending Approval with its currency and exchange rates snapshotted, so it re-prices identically forever.
- The MSP decides. Approve, or reject with a reason. Rejection cancels the order and records why.
- The MSP fulfills. Start processing, mark shipped — entering the carrier and tracking number — then mark delivered. Each transition is validated server-side against a forward-only graph.
- The client watches. The order page in the client’s portal shows a five-step timeline with the dates the MSP’s actions produced, plus the carrier and tracking number. The same organization-scoped, read-only lifecycle is available in Solidlio Mobile under Orders & Delivery.
- The order’s invoice link is unique, so it cannot be billed twice.
- Services follow the same shape. A service order is drafted, submitted — which approves it and records the platform fee in the same transaction — and marked complete when the work is delivered.
Compliance and audit
- Approval records who approved the order and when; every fulfillment step records the user who advanced it.
- Rejection reasons are written into the order record, not into a chat thread.
- Ship and delivery dates are stamped once, on first crossing, and are never rewritten by a later call.
- The order-to-invoice link is a unique database constraint, so the claim “this order was invoiced exactly once” is enforced by the schema rather than by convention.
- Dry runs of the invoicing job are verified end to end: if the downstream service does not echo back that it ran read-only, the run is reported as a failure rather than as a clean rehearsal.
- Buyer isolation fails closed — a caller with no organization context is refused, and a sibling client’s order is indistinguishable from one that does not exist.
Editions
Fulfillment and service orders are included in every plan — MSP Free, Starter, Growth, Scale and Enterprise. There is no feature gate on any tier. Who can approve, fulfill or raise an order is decided by role: administrators act, technicians and clients read.
An order that shipped is an order that gets billed, once.