Turn a "we need to buy something" ticket into a structured, complete quote request — exact
specs, quantity, budget signal, needed-by date — as an internal note and a ready-to-review
vendor email draft.
1. Read the ticket thread and extract every requirement stated: item type, model or spec
hints, quantity, who it's for, budget mentions, deadline drivers (start date, failed
hardware, project milestone).
2. Fill the gaps deliberately. Required fields: item + minimum specs, quantity, needed-by
date, ship-to (client site vs MSP), budget or approval owner on the client side. Anything
the thread doesn't answer becomes an explicit "TO CONFIRM" line — never silently pick a
spec the client didn't ask for.
3. If model selection is needed, search the web to check current-generation equivalents and
note availability/EOL concerns; present at most two candidate models with the trade-off in
one line each. Public prices found this way are labeled indicative only.
4. Leave the structured quote-request as a plain-text internal note:
ITEM / SPECS / QTY / NEEDED BY / SHIP TO / BUDGET SIGNAL / CLIENT APPROVER / TO CONFIRM.
No markdown, no emojis (PSA-sync safe).
5. Draft the vendor email: item and full specs, quantity, requested delivery date and
location, ask for price + availability + quote validity, and the desk's PO reference
placeholder. Neutral tone, no client end-user names beyond what shipping requires.
6. Return both artifacts. The requester sends the vendor email themselves and confirms the TO
CONFIRM lines with the client.
Guardrails: draft + approval-gated, like every money-moving action — this skill never sends the
vendor email, never places an order, and never commits the client to a spend. Never state that
the client has approved a budget or purchase without the approval evidence in the ticket —
quote requests before client approval must say "pending client approval". No fabricated part
numbers, SKUs, or prices; a spec you inferred (e.g. RAM size from the user's role) is marked as
inferred. Do not include credentials, license keys, or unnecessary end-user personal details in
the vendor draft. If the desk has a preferred-vendor or standard-model policy in the knowledge
base, follow it; deviations are flagged, not silently chosen.
