Case study. Warehousing and fulfillment
PFG (Precision Facility Group)
- Industry
- Warehousing and fulfillment
- What they were on
- Smartsheet, Make.com, Extensiv WMS, FedEx APIs
- Work
- Project management, Integrations
- Engagement
- 2024 to 2025
- Company size
- 100-249 people
The situation
Precision Facility Group runs warehousing and fulfillment operations. The operational picture lived in three places that did not talk to each other. Extensiv, the warehouse management system, held inventory, receivers, and adjustments. FedEx carried the outbound shipments. Smartsheet was where the team actually worked. Order sheets had columns for carrier, tracking number, and shipping status, but someone had to look each shipment up to fill them in. The inventory sheet was supposed to mirror the WMS and did not. It had thousands of rows, SKUs mapped to the wrong identifier, and a pallet-level field (the movable unit label) that had never been set up at all. We had supported their Smartsheet environment since early 2024, and in February 2025 a change order took on the integration work properly.
What we built
Two Make.com integrations, both feeding Smartsheet.
The Extensiv integration syncs the inventory sheet from the WMS. Getting it right meant working through the Extensiv API endpoint by endpoint (receivers, returns, adjustments, stock details) against a spec of several hundred fields, correcting the SKU mapping from the internal database ID to the actual SKU, refreshing thousands of existing rows that had been written with the wrong identifier, and hunting down the movable unit label, which Extensiv does not expose where you would expect. By August 2025 the sheet was updating with pallet identifiers alongside the rest of the inventory data, and every SKU in the sheet had been verified against the API.
The FedEx integration writes shipping status into any sheet that follows the team's column convention of carrier, tracking number, and status. It fetches each undelivered row, checks it against FedEx, and updates the sheet until the shipment delivers, then leaves it alone. FedEx's API had no webhooks available to us, so each run touches every open record. With more than three thousand undelivered rows in the live sheet, run frequency had to be balanced against the Make plan's operations budget, and we laid the numbers out for the client so the schedule was their informed choice rather than a surprise on an invoice. Setting up the connection also meant a long back and forth with FedEx developer support to stand up the developer account and credentials.
What changed
Shipping status stopped being a lookup job. Rows update themselves until delivery, on a schedule the client chose knowing exactly what it costs in automation operations. The inventory sheet became trustworthy, with correct SKUs across the full history, pallet identifiers present, and a documented list of the handful of SKUs the API itself could not return. The team kept working in Smartsheet, which is where they wanted to be, and the systems around it came to them.
What we would do today
Given the same problem now, we would build PFG a small, owned integration service instead of metered automation scenarios, with direct connections to Extensiv and FedEx, event-driven where the APIs allow it, polling where they do not, with no per-operation pricing deciding how often the data can be fresh. The Smartsheet front end could stay, or be replaced with an operations view built around their sheets' actual workflow. The Make build works and is documented. An owned service removes the operations meter and the middleware account from the middle of their warehouse.
The services behind this build
Where this work comes from
If your operations team is copying tracking numbers into a spreadsheet, book a strategy call and we will map out what one connected system would look like.
A strategy call is a conversation about your work, not a pitch. If a build is not the right answer, you will hear that first.
