Field note / procurement and licensing
Procurement is excluded everywhere on this site. Here is what that boundary actually means.
Every delivery line in the catalogue excludes procurement in one line and moves on. This page slows down long enough to name who buys, who advises, and who stays out - for hardware and for software licensing.
Why procurement stays out
A recurring reference band cannot price a one-time purchase.
Essential and Plus price repeatable monthly work. A hardware purchase or a software licence commitment is a one-time or contract-term decision with its own budget, vendor terms, and payment relationship - folding it into a per-user monthly figure would either overcharge the months nothing is bought, or quietly underfund the purchase itself.
Review the two reference bands and what they exclude →Ownership map
Five procurement-adjacent decisions and who actually holds each one.
| Decision | Who buys or signs | Who can advise | Delivery's role |
|---|---|---|---|
| New hardware (laptops, servers, network gear) | Partner or client, whoever holds the vendor account | Partner, with delivery input on specs | Recommends specs and configuration; does not place the order or hold the invoice |
| Software licence purchase or seat count | Partner or client, whoever owns the subscription | Partner, informed by delivery's usage observations | Flags when a seat count or tier looks wrong; does not change the subscription without approval |
| Licence renewal timing | Whoever holds the contract | Partner | Can flag an approaching renewal it happens to notice; does not own the calendar |
| Vendor account and billing relationship | Partner or client - never delivery | Not applicable | Uses the relationship it is given access to; never becomes the account holder |
| Warranty and RMA claims | Whoever holds the purchase record | Partner | Can identify a likely hardware fault; does not file the claim on the partner's behalf unless separately agreed |
Confidentiality-style boundary
What delivery can honestly do, and what stays someone else's call.
What delivery can honestly do
- Recommend a spec, tier, or seat count based on observed use
- Flag a licence approaching its limit or a device approaching end of life
- Configure and deploy what has already been purchased
- Document the decision so it does not need re-litigating next quarter
What stays a partner or client decision
- Which vendor gets the purchase
- Whether to buy, lease, or extend
- The commercial terms and payment relationship
- Whether a recommendation is worth the cost
Representative pattern
A procurement question should have exactly one predictable next step.
- Delivery notices, or is asked about, a hardware or licensing gap.
- Delivery writes down the observation and a plain recommendation - not a purchase order.
- The named buyer decides whether, when, and from whom to buy.
- Delivery configures what arrives, inside the already-qualified endpoint or Microsoft 365 lane.
This is a process description, not a claim that a specific purchase workflow already exists for a given partner.
See how a purchased device actually enters the endpoint lane →
Related decision
A project usually has its own procurement question too.
An office move or new-site rollout often needs equipment sourced on a deadline - a related but separately scoped decision.
Bring the gap, not a purchase order.
A specific device or licence observation, and who currently holds the vendor relationship, is enough to start this conversation.