I rebuilt our purchasing workflow on the Aspire API. Here's what I learned.
TL;DR: Our purchasing workbook was a hand-maintained spreadsheet that lived or died on one person. I replaced it with a SharePoint List that populates itself from Aspire, so the purchasing team spends their time sourcing instead of transcribing.
One person held it together
Every plant we sell has to get bought. For years that meant one person, our Purchasing Manager, reading through newly won proposals in Aspire and hand-typing every line item into an Excel workbook. Property, ticket, item, size, quantity, cost, account manager. Then tracking status on each one: sourcing, reserved, picked up, in the yard.
It worked, and the person doing it was good at it. It also had every problem you'd expect:
- One person held the whole process. The judgment about what mattered, what to skip, what to chase: none of it was written down anywhere.
- Silent drift. Finished jobs stayed on the list for months. Nobody clears rows they aren't thinking about.
- No account manager visibility. The person who sold the job couldn't see whether their material had been captured correctly, let alone whether it had been ordered.
- Transcription gaps. If a line item never made it into the workbook, nothing anywhere would tell you. You found out when the crew showed up without the plants.
I wanted the same workbook (familiar shape, same columns people already knew) but populated from Aspire automatically, with humans doing judgment instead of data entry.
What I built
Four scheduled jobs against the Aspire API, writing into a SharePoint List:
- Ingest: pulls material from newly won opportunities and creates rows. Nobody types anything.
- Schedule sync: keeps scheduled dates current as jobs move, and surfaces material as it gets close.
- Fail-safe: audits both directions daily. Anything in Aspire that should be on the list but isn't, and anything on the list that's been removed or changed in Aspire since. Emails whoever needs to know, in plain language.
- Archive: retires rows once the work is genuinely done, so the live list stays live.
The part that actually changed the workflow
The old workbook had tabs: a current list, seasonal tabs, a pickup list, a today's-jobs tab. Every tab was a copy, and copies drift.
Now it's one dataset with saved views over it, each pointed at a different person's job:
- Purchasing works the full list and decides what gets ordered versus shopped for in person.
- Field pickup has a view filtered to just what they're personally sourcing, sorted by what's needed soonest.
- Warehouse and receiving has a view of stock items (mulch, soil, burlap, ties) to verify we actually have them before a job needs them. Consumables get flagged automatically so nobody wastes time approving them.
- Account managers and PMs see their own material, and get an email when new material lands on one of their jobs. They reply in plain language: "all approved," or "all approved, but make the begonias red blooming." The notes land on the right line items.
That last piece is the one I'm most interested in. Material used to get purchased on the assumption the proposal was right. Now there's an actual checkpoint with the person who sold it, and it costs them a one-line email reply instead of learning a new system.
Aspire data lessons that mattered
These cost me real time to figure out. If you're building anything similar, they might save you some.
Line items get added late. On a large install, the proposal gets won and then items could keep landing on tickets for weeks or months due to change orders. If you trigger off "won in the last N days," you'll miss material on your biggest jobs. CreatedDateTime on the work ticket item is the honest signal.
Crew leader assignment isn't a scheduling signal. I assumed a crew leader meant a ticket was really on the board. It isn't: crew leaders get assigned while the date is still a placeholder.
Where we are
Honest status: the list is populated and the jobs run nightly, but the approval loop is in pilot with a handful of account managers. The real test is adoption, not code: this is the first internal tool I've built for 15–20 people instead of two or three.
The question I want to ask
The shift for me wasn't automating a report. It was having something sit between Aspire and the places our work actually lives (SharePoint, Drive, email, our own server) and move between them without a person copying data across.
So: what's the task you wish would just handle itself?
Not "what report do you want," but the thing where you are the integration: the recurring job where you export from Aspire, reformat it, put it somewhere else, chase people for responses, and reconcile it later. The stuff that's too specific to be a feature request but eats a day a month.
Curious what everyone's version of that is.
