SysEngineering

Purchasing Desk roadmap

Set 7 November 2026, after a week of AI-initiative meetings. The desk becomes the home of Business Operations’ tools under Robbie: procurement today, then a chat agent, reporting and receipts, and recruitment one day. Adam’s and Claude’s working list, to check goals off as they land; operational state stays in HANDOFF.md.

Checklist

• 1. Order ledger (BigQuery): live 7 November, views created, totals match PSA
• 2. Viewer and buyer roles: small, before Kelly gets in
• 3. Ask the desk (chat agent): live and answering from both sources, 7 November; Kelly waits on 2
• 4. Reports for Robbie: first cut live 8 November (the Reports tab, 00030-kez); next, Robbie’s own reports
• 5. Apple with ABM serials: key in hand, discovery
• 6. Receipts for Jennifer: discovery first
• 7. Recruitment: waiting on Robbie’s details

Alongside:

• Deploy #260 (order prices): live with the ledger, 00026-san (7 November)
• Deploy from main (HANDOFF, “Goal”): in place before Ask the desk ships
• Lean-down refactor (src/app.css is 2,154 lines), with the new sections’ navigation so they don’t copy the bloat

5 and 6’s discovery steps need no code and run alongside 1-4.

What carries over to every new section

• JSM is the record of purchases; the order ledger holds only what vendors’ emails said (goal 1). Okta decides who signs in.
• Every Jira write is previewed and approved by a buyer (Adam, 25 October). New sections are read-only unless a decision here says otherwise.
• Sources are read-only: the mailbox by gmail.readonly, vendor APIs GET only, with a test that fails the build otherwise (the Zoom dashboard’s pattern).
• Totals and counts are computed in code, never by the model (Greg #263, Gwen’s portfolio tool).
• Credentials go straight into Secret Manager in hillspire-procurement, read only by purchasing-desk-runtime@; never chat, the repo or a ticket.
• Lean: one stylesheet per page, no speculative abstractions.

1. Order ledger (first)

PSA answers most questions: spend by entity, vendor and month, order counts and cycle time come from its fields, titles and changelog. What it lacks is the items. Total Order Cost is one number per ticket, often several vendors’ orders together, and no ticket holds a part number or a price per item, so “how many X1 Carbons” or “why did the X1s go up” can’t be answered from it. The desk reads both from every vendor email and kept only the total it posts; the mailbox covers 90 days.

Decided (Adam, 7 November): BigQuery, in the desk’s own project and separate from Harry’s CSAT. The ledger holds only what the vendors’ emails said; JSM stays the record of the ticket, and Ask says which source each answer used. Chosen over keeping items on the ticket because it catches every order the mailbox sees, including the ones a buyer handles by hand, and later Amazon’s actual charges and ABM’s serials. How it works: README, “Order ledger”.

• Dataset purchasing_desk, log sink purchasing-desk-ledger and its grant (7 November; HANDOFF)
• The desk logs one desk.ledger line per vendor email; views in ledger_bigquery.sql, checked in BigQuery against the fixtures (7 November)
• PR (#270, with this roadmap), deployed with #260 as 00026-san (7 November)
• First rows land; create the views; a few orders’ totals match PSA (7 November)

2. Viewer and buyer roles

Today everyone on the access list can approve Jira writes. Before Kelly (CIO), or anyone who only reads, gets in: buyers approve; viewers see Orders, Requests, Reports and Ask but get no approve buttons, enforced on the server, not just hidden. One Okta group per role; PROCUREMENT_ALLOWED_EMAILS stays the second check.

3. Ask the desk (chat agent)

A chat panel on the desk for Kelly, Robbie and the buyers: “how many Lenovos did we order this month?”, “how much have we spent on Lenovo laptops?”, finance’s “the X1s were $2.5k, now $3k, why?”. Asked for by the CIO on 3 November. Mock (invented numbers): https://claude.ai/artifact/TLTB72QSnR9kBTP5AUQEWH.

• Same backbone as Greg, Harry, Marty and Oscar: Claude through the Anthropic API (claude-opus-5-5 since 7 November, when every agent moved to it; one setting) and the same agentic tool loop. The desk is Node, so @anthropic-ai/sdk; the shape (system prompt, tools, loop, limits) follows Oscar’s.
• Tools are fixed, GET-only reads of PSA and the ledger (spend by vendor, entity and month; order and item counts; price history for a part; open orders). The arithmetic happens in the tool, the model writes the sentence, and every figure links its tickets. No user- or model-written JQL.
• It writes nothing. No Jira writes, no approvals; it can point to an order on the desk.
• Its own key, purchasing-desk-anthropic-api-key, not Harry’s. A record of use (who asked, which tools ran) as structured logs.

• Order-level questions work on PSA alone from day one; item-level ones (“how many X1 Carbons”, price history) cover what the ledger holds (from 20 October on), and say so.

• Built 7 November on feat/procurement-ask (README, “Ask the desk”): the loop, three tools (purchase_requests, vendor_orders, ordered_items), the Ask tab; 161 tests with ABM’s, 62 UI checks
• Anthropic key purchasing-desk-anthropic-api-key in Secret Manager (a Console service account, 7 November)
• The runtime’s BigQuery read; an item question answered live (7 November)
• Tried from a laptop (scripts/try-ask.mjs), #272, deployed as 00028-qux
• Roles (goal 2) before Kelly goes on the access list

4. Reports for Robbie

• A Reports section on the desk: spend by entity, vendor and month; top items; cycle time (request to ordered to delivered, from Jira’s changelog); CSV export.
• Spend kept apart from the open queue: the $1.4M queue figure includes stale tickets (HANDOFF, 28 October).
• The same queries as Ask’s tools, built once.
• First, ask Robbie what she reports today, to whom and how often, and build those.
• Live 8 November (#273, 00030-kez): the Reports tab over PSA and the ledger: filters, groupings, a cross-tab, a chart over time, the period before, CSV, links and print, with rejected requests left out of spend. README, “Reports”. Not yet: cycle time from Jira’s changelog (it has days from created to closed), and whatever Robbie reports today.

5. Apple with ABM serials

The plan decided 28 October stands (HANDOFF, “Apple”): Apple’s emails drive the flow, already copied to procurement@; ABM adds serial numbers. Adam has the ABM API key (7 November).

• A GET-only client (server/abm-client.mjs) and a local preflight (scripts/abm-preflight.mjs), from Apple’s docs (7 November, feat/procurement-abm). An ABM API account can also reassign devices, release them from the organization and edit Blueprints, so the client is GET only, pinned by test.
• The key, client ID and key ID go into Secret Manager from the file (HANDOFF, “Apple”; commands there).
• Ask who created it, with which role, for which ABM organization (one per entity?), and whether a narrower role exists.
• Run the preflight: does ABM’s order number equal the AAA… number on PSA-2486 (AAA6828504)? That decides whether serials can be matched to tickets at all. Also W1610319216 (an in-store pickup) and AFH0099144.
• An Apple order confirmation sample (does it carry prices?).
• The Apple adapter in vendors.mjs; serials on the order, added to the ticket on approval; serials go into the ledger too; later the helpdesk hand-off.

6. Receipts for Jennifer

Worth doing, but not first, and not a Concur integration first.

• The desk already holds the evidence for its vendors. Every confirmation is in procurement@ and in the ledger. Each vendor added covers more of the pile.
• What Concur accepts may be the charge, not the order. Amazon charges per shipment, and an order confirmation may not pass as a receipt. Amazon Business has its own SAP Concur integration for e-receipts: check whether it is on. If so it may cover Amazon with no code.
• Discovery, about 30 minutes with Jennifer over one month’s report: which cards (hers, or a company card feed into Concur), which vendors make up the pile, what she does per receipt today, and what Concur sends back.
• Whether Amazon Business’s Concur e-receipts are on.
• Likely build: a Receipts view per month listing each charge’s order, ticket, entity and receipt (the vendor’s email or invoice as a PDF), downloadable as one bundle to drop into Concur. Concur’s own API only if the drop is still the slow part: it needs SAP partner registration and a write path into an outside system.
• Out of scope: travel and meal receipts. The desk only sees purchasing.

7. Recruitment

Not started; waiting on Robbie’s details. Candidates’ personal information is a different kind of data from orders, so plan its access (its own Okta group at least) and retention with InfoSec then, before building.

Also queued (HANDOFF, unchanged)

Amazon Business API (carrier tracking, later Reconciliation for receipts) and the morning “Needs you” Slack message. The name stays “Purchasing Desk” until it holds more than purchasing; the Cloud Run service and project names don’t change.