Long-lead gear tracker
Switchgear gets ordered in the spring and is needed on site in the fall. In between, nobody looks at it closely. The PO sits in a folder. The vendor sends an acknowledgment with a ship date, and...
The problem
Switchgear gets ordered in the spring and is needed on site in the fall. In between, nobody looks at it closely. The PO sits in a folder. The vendor sends an acknowledgment with a ship date, and that date lives in an email thread the superintendent was copied on three months ago.
Then the date moves. Sometimes the vendor says so in a one-line email. Sometimes the portal quietly changes and nobody notices. Either way, the superintendent finds out when the electrical foreman asks where the gear is, and by then the crane is booked, the utility outage window is set, and the options are all bad.
A slipped ship date is not a disaster if you learn about it early. Four weeks of warning lets you resequence, push the outage request, or call the vendor with leverage. Four days of warning gets you an apology.
The problem is not that anyone is careless. Tracking a dozen long-lead items against a moving schedule is tedious, and field work crowds it out.
How the agent workflow works
The agent runs once a week, on a fixed day, and does three things.
First, it reads. It pulls from a long-lead register (a simple sheet listing each item, its PO number, the vendor's current promised ship date, transit time, and the schedule activity that needs it). It also reads the project schedule export and any new vendor emails or order-status notices forwarded to a shared inbox.
Second, it compares. For each item it calculates the expected arrival date from the ship date plus transit, then checks that against the need-on-site date from the schedule, minus the buffer the superintendent set for receiving and inspection. It flags anything where the float has shrunk since last week, and anything where the vendor's date changed.
Third, it drafts. For each flagged item it writes a short expediting note: what the item is, the old and new dates, which schedule activities it affects, and a proposed ask to the vendor. It also writes a one-paragraph summary for the superintendent, with the flagged items ranked by how little float remains.
The human checkpoint is before anything leaves the building. The superintendent reads the summary, corrects the register where the agent misread something, and approves, edits, or discards each drafted note. The agent never emails a vendor on its own and never edits the schedule. It proposes, and the superintendent sends.
What you need to set it up
- A long-lead register in a spreadsheet. Building it for the first time is the real work, typically a few hours per project.
- A schedule export the agent can read, in whatever format your scheduling software produces, refreshed weekly.
- A shared inbox or forwarding rule so vendor acknowledgments and status emails land somewhere the agent can read.
- An AI agent tool that can read files and email on a schedule and write drafts without sending. Most general-purpose agent platforms can do this. Confirm that sending is turned off.
- About an hour of tuning in the first few weeks, adjusting buffers and the wording of the notes until they sound like you.
No new software purchase is required if you already have a spreadsheet, a scheduling tool, and an agent subscription.
Where it breaks
The agent is only as current as its inputs. If a vendor changes a date by phone and nobody updates the register or forwards an email, the agent reports good news that is not true. This is the biggest risk, and it looks like confidence.
Vendor emails are inconsistent. Some give a ship date, some give a week, some say "in process." The agent can misread a production-complete date as a ship date. Ambiguous wording should be flagged for you to check, but it will not catch every case.
Transit times are estimates. Freight on oversized switchgear can run long, and the agent does not know about a port backup or a carrier problem unless someone tells it.
The agent reads the schedule, but it cannot judge whether the schedule is realistic. If the need-on-site date was a guess, the comparison inherits the guess.
Drafted notes can also be too polite or too pushy for a given vendor relationship. You know which vendors respond to a firm note and which need a phone call. The agent does not.
Finally, a weekly cadence misses fast-moving items. For something critical, check it more often.
The bottom line
This workflow does not make gear arrive sooner. It makes sure you hear about a slip while you still have room to act. The value is the early warning and a ready draft, not automation of the vendor relationship.
Build the register, keep it honest, and read the weekly summary. If the inputs are current, you will stop learning about late switchgear from the foreman.
Related use cases
- Three-way match on every delivery Materials
- A gate on every material order before it goes out Materials
- Two-week lookahead, built not typed Management