Delivery Watch

One click reads a project's purchase orders, what has been received against them, shipment rows, mail and vendor APIs together, and tells you what is late, what shipped without anybody logging it, and what has arrived that nobody has counted in.

What It Does

Between ordering equipment and installing it, the truth about a project is spread across five places that never talk to each other: the purchase orders you issued, what has actually been received against them, the shipment rows somebody typed in, the vendor's email saying it slipped two weeks, and the vendor's own availability API. A sweep reads all five at once, matches what the messages say to your own records, and raises a finding wherever the two disagree.

These are the same purchase orders and the same receipts the rest of the app works from — the ones under Purchase Orders & Receiving. A sweep has no records of its own, so a date it puts on an order is a date the buyer sees on the order.

The AI does one job only — matching a sentence in an email to a purchase order or shipment row that already exists in this project. Everything after that is arithmetic: how many days a date lands past your deadline, how many units of an order are still to come, whether that is bad enough to need a decision, and what you can do about it. Nothing about a sweep is a guess about your data.

A sweep also writes nothing outward. It updates this project's own shipment records and purchase orders when you accept a finding. It never emails a vendor, never drafts a change order, and never creates a task list.

The sweep board: the banner says what deadline everything was judged against and what the sweep actually read; each finding carries its own delay figure.

Before You Start

• Set a delivery deadline on the project. Open the project, click Edit, and fill in Equipment needed on site — it sits directly below Go-Live Date. This is the date everything is measured against, and it is the single biggest difference between a useful sweep and a quiet one.
• Connect your email. The sweep reads the project's synced mail from your own mailbox. Without it, a sweep still runs — it just reads your records alone and can only tell you what your own dates already say. Microsoft Teams conversations synced to the project are included as they become available.
• Issue your purchase orders in AVstackr. A sweep matches vendor messages to purchase orders by their PO number. Orders placed entirely outside the app have nothing for a message to attach to. A draft order is invisible to a sweep — the vendor has not been sent it, so nobody can have promised anything against it — and so is a cancelled one. Issued, acknowledged and closed orders are all read.
• Record what arrives on the Receiving page. Receipts are how a sweep knows an order is settled. An order whose equipment has all been received drops out of the sweep's attention; one where the carrier says "delivered" but nothing has been counted in is exactly what a sweep is looking for.
• Any project can be swept, at any stage. A contract is not required — though on a contracted project the sweep adds one extra check, described under Warnings below.

Running a Sweep

1. Open the project and click AVIP ASSISTANT in the header.
2. On the Delivery watch tile, click Run sweep. There is no source to pick — the project is the source.
3. The run moves through Analyzing → Review → Completed. Findings appear on the board as they are derived rather than all at the end.
4. Decide every finding. When none are left pending the sweep completes on its own.

A project runs one sweep at a time. If a sweep is already open — including one that failed or paused — the tile sends you back to it rather than starting a second.

How far back it reads: a project's first sweep reads the last 30 days of mail, up to the 50 most recent messages. Every sweep after that starts where the previous completed sweep stopped, so nothing is read twice and nothing between sweeps is skipped. The 50-message cap still applies; when it bites, the board says so in plain numbers — "180 emails in the window; the 50 most recent were read."

Delivery watch has one button, not a source pair — a sweep's source is the project itself.

Reading the Board

The banner

Two lines sit above every finding, and they answer the two questions worth asking before you read any card.

• What deadline is this judged against — "Judging against Equipment needed on site: Sep 5". If the project carries none of the three dates, the banner says so instead, and the sweep raises no date-risk findings at all rather than quietly measuring against today.
• What the sweep read — "Read 4 POs, 6 shipments, 23 emails." A source it found nothing of is left out rather than printed as a zero. A project with nothing to read says that too, which is how you tell a clean board from an empty one.

Warnings

Below the banner, the sweep reports anything that limited what it could see or check. A vendor API that failed or timed out becomes a warning line, never a failed sweep — availability is a bonus, and a sweep built on three of four sources should not look identical to a complete one. The email cap appears here. So does one check that has nothing to do with messages: on a contracted project, the sweep counts the contracted equipment lines that are not fully on a purchase order yet and tells you how many. It reads the same coverage the Procurement Worklist does, so a line you excluded from procurement is not counted against you, and a half-ordered line still is.

The findings

Each finding is one card, badged Safe, Review or Critical, and labelled with what kind of problem it is:

• Unlogged shipment — a vendor named a tracking number this project has no shipment row for.
• Delay risk — a date lands past your deadline. This fires from a vendor's delay notice or promised date, and also from your own records alone: a shipment or purchase order whose own dates already miss the deadline needs no email to prove it.
• On schedule — a vendor states a ship date that meets your deadline. Good news is still a record: the card is green, lands in the low-risk pile, and offers the same one-click write, so the vendor's date ends up on the order either way. Only a message raises this one — your own healthy records stay quiet.
• Stalled PO — an issued purchase order the vendor never answered: no acknowledgement on it, no promised ship date, no shipment linked to it, and nothing in the mail the sweep read that answers it, ten days after it was issued.
• Missing tracking — a vendor says it shipped but gave nothing to track it by.
• Arrived, unconfirmed — either a message says it arrived while the shipment row still reads in-transit, or a shipment record carries a delivery date but its status was never moved to Delivered. This one is about the shipment row being behind.
• Delivered, not received — something says the goods arrived, and the order's own receipts still show units outstanding. The card quotes the count: "PO-12, 0 of 8 received". This one is about receiving being behind, and it is the one card that never offers anything to write.
• Availability issue — a vendor's own API reports an item is unavailable or backordered. Only vendors with an API configured are checked.

The big figure on a card is its delay — how many days the date lands past the deadline, so "11 days delay" means eleven days late. A date that still makes the deadline reads "to spare" instead. Beneath the headline, the two dates run as a line from Needed to Arrives — fading to red when the date lands past the deadline, to green when it lands inside it.

A card that names a purchase order also names what that order still owes — Still to come, with each line's make, model and the units not yet received — so you can see what equipment is at risk without opening the PO and searching it.

Cards cite their evidence two ways, on purpose. A finding that came from a message quotes the message. A finding derived from your own data is flagged From your records and quotes the row instead — so you never mistake your own shipment row for something a vendor told you.

Acting on Findings

Two piles, same as scope change. Findings the agent judged safe to record collect in Low-risk findings with one Accept all button and one optional reason covering the batch. Everything else gets its own card and its own decision, and those ask for a reason.

Each card offers the actions that make sense for it — Log this shipment, Log the expected date, Record the promised ship date on the PO, Mark delivered — with the recommended one marked. Some findings have nothing to write at all; those say Acknowledge and offer no button, because there is genuinely no record to change. Dismiss is on every card: it records that you looked and decided this is not a risk, or that you handled it outside the app.

The low-risk pile only ever writes shipment rows. A promised ship date changes the order itself, so its card always waits for a person — it is never swept up by Accept all.

A review card: the delay figure is the headline, the quote is the evidence, and the recommended option is marked.

Accepting a ship promise

When a vendor's mail names one of your orders and gives a date, the card offers Record the promised ship date on the PO. Accepting it does exactly what clicking ACK on the purchase order does: the order moves to Acknowledged, stamped with that promised ship date. An emailed ship promise is the vendor acknowledging your order, so the sweep records it as one — and the PO's Progress spine shows the acknowledgement dated from your decision.

When the same vendor writes again with a later date, accepting the new card moves the promised date only. The acknowledgement keeps the day the vendor first answered, because that is when they answered — the slip is a new promise, not a new acknowledgement.

An order you already closed gets a different card: Reopen the PO & record the ship date. The vendor saying "it ships Sep 5 after all" on an order you closed is a decision point, and accepting the card takes it — one accept, with your reason, reopens the order and records the date, exactly the two clicks of Reopen PO then ACK on the PO page. The reopen only ever happens from a card whose label says so.

A cancelled order still refuses in plain words — there is no order left to ship against, and reopening is not the answer. The same refusal guards the plain record button when an order closes between the sweep reading it and you accepting: that button never mentioned reopening, so it writes nothing.

The card that writes nothing

Delivered, not received has no Apply button anywhere on it, by design. A receipt is a person counting what came out of the boxes, and the sweep will not do that for you — it reads receipts and never writes one. The card carries an Open Receiving link instead, which opens the Receiving screen for this project in a new tab so the sweep stays where you left it. Record what arrived there, and the next sweep has nothing to raise.

The one card with no Apply button: it cites the receiving count and points at the page where a person does the counting.

What Gets Written

Accepting a finding writes to two places inside this project, and nowhere else:

• Shipment records — a new shipment row, or an update to an existing one, linked to the purchase order it belongs to. Find them from the project's actions menu, under Sales Operations → Shipment Tracking.
• Purchase orders — the acknowledgement and the vendor's promised ship date, on the order itself. The same fields the ACK action on the purchase order writes, and the only fields a sweep touches there.

Nothing leaves the building. No email is drafted or sent, no vendor is contacted, no change order is drafted, and no task is created. Each decision records who made it, when, and why — and each card tells you afterwards exactly what it wrote, including when it wrote nothing and why.

Questions Mid-Sweep

The chat rail beside the board belongs to the sweep while one is open. Ask about what it read, or why a date landed where it did, and the answer arrives as a chat message without touching any finding.

Closing, Re-running, Discarding

• Close returns to the workflow tiles. The sweep keeps running and is waiting when you come back.
• Re-run the sweep appears when new signal has arrived since the sweep froze its reading. Re-running supersedes only the findings nobody decided yet — records you already updated stay updated.
• Discard abandons the sweep and frees the project to start another. Records already written stay written.

Credits

Sweeps use AI credits from your organization's balance, and one needs at least 25 credits available to start. A sweep that runs the balance down pauses rather than failing: top up and click Resume, and it picks up where it stopped — the analysis it already paid for is not billed twice. See AI Credits.