Small IT teams don’t need a procurement policy. They need four decisions written down somewhere findable, so that ordering a laptop is not a fresh negotiation every time and so the process still works during the fortnight the person who normally does it is on holiday.

TL;DR

  • Four decisions cover it: the standard build, who approves, who orders, and what happens when it’s urgent.
  • A standard build removes most of the work. Two or three options, published, with a stated exception route.
  • Pre-agree an approval limit so routine orders need no conversation at all.
  • Write down the urgent path before you need it, or the urgent path becomes a retailer and a manual exception.
  • Document it where a stand-in can find it, because the single-person dependency is the real fragility.
  • Review the build annually and the suppliers when something goes wrong, not on a schedule.

Why small teams end up with no process

It isn’t neglect. At eight or ten people a process is genuine overhead, so the one person who knows the supplier just orders what’s needed and that works well for a surprisingly long time.

Then it breaks. The company reaches 50 or 60 and three things happen at once. The orders get frequent enough that the knowledge in one head becomes a bottleneck, somebody in finance starts asking why spend varies so much per hire, and a new starter arrives in a country nobody has shipped to before. That’s the moment, and it arrives suddenly rather than gradually.

What’s needed then is still not a policy document. It’s four decisions, recorded somewhere a colleague could find them without asking.

Decision one: the standard build

Two or three options, no more. A standard machine, a higher-specification one for the roles that genuinely need it, and possibly a lighter option for travel-heavy work.

Publish them with the price. That single act removes most of the back and forth, because a hiring manager asking what their new starter gets now has an answer they can read rather than a conversation to start, and finance can forecast from a number instead of an average of whatever happened last quarter.

Then state the exception route explicitly. Somebody will need something different, and the useful framing is that exceptions are fine and go through a named person, rather than that they don’t exist. A process that pretends there are no exceptions gets routed around the first time one comes up.

Decision two: who approves, and what needs no approval

Most approval steps in small companies exist by accident. Somebody asked once, it became a habit, and now a 1,200 laptop for an approved hire waits two days for a signature that was never going to be refused.

Set a limit under which nothing needs approving. A standard build for a confirmed hire is already an approved cost, because the headcount decision carried it, and re-approving the same thing twice is pure delay. Above the limit, or for anything off the standard list, name a single approver and a deputy.

What to do:

  • Set a value under which a standard build needs no approval at all.
  • Name one approver and one deputy for everything above it.
  • Make the deputy real by routing something to them deliberately once a quarter.
  • Put the limit in writing where a hiring manager will see it.

Decision three: who actually places the order

This is where the single-person dependency lives. One person has the supplier relationship, the account login and the knowledge of which reseller handles which country, and none of it is written down anywhere.

Fix it cheaply. One page listing each supplier, what they are used for, which countries they cover, the account details in your password manager rather than in somebody’s inbox, and the lead time you have actually experienced rather than the one quoted. That page is the difference between a holiday and an incident.

Record real lead times, not promised ones. A supplier quoting five working days who reliably takes 11 is useful information, and it is the number that should drive how much spare stock you hold.

Decision four: the urgent path

Every team has urgent orders. Pretending otherwise is how the urgent path becomes a trip to a retailer, which produces a machine outside automated enrollment and a manual exception that lasts for years.

Decide it in advance. Make it something that preserves the rest of the process. For most teams that’s a small local spare pool, sized from your own replacement lead time, so an urgent need is met from stock you already own and the replacement order follows at normal speed. The alternative is to accept the retailer route and commit to recording every machine bought that way, which works but requires discipline nobody reliably has under pressure.

A two-person team that wrote it on one page

A 74-person company had one IT person and one part-time contractor. Every laptop order went through the IT person, including the approval, the purchase and the shipping arrangements.

They wrote it down. Four decisions on a single internal page, and the supplier credentials moved into the shared password manager. Standard build published with prices, no approval needed under 1,400, two named approvers above it, three suppliers listed with real lead times, and four spare machines held in the main market. It took an afternoon, and the measurable change was that 19 of the next 22 orders were placed by somebody other than the IT person.

Nothing about it was sophisticated. The value was entirely in having written it down, which is the part that keeps getting deferred because it feels like administration rather than work.

Where a lifecycle platform helps, and where it does not

A two-person team’s real constraint is attention. The question worth asking about any platform is whether it removes work or adds a system to maintain, and for procurement specifically the answer depends almost entirely on how many countries you ship to.

RemoAsset is our own product. It handles procurement and retrieval across 80+ countries and records each device through issue and return, which is worth most to a small team shipping into markets where it has no supplier relationship and no realistic way to build one. Pricing is published, from $1,499 a year on the Subscription tier for companies with 50 to 5,000+ employees, including a 60 per cent reduction on retrieval charges.

The limits are worth stating. It has no network discovery, so it will not find hardware you have lost track of. It has no software licence management, which is a real gap when licences are often the larger per-head cost. And only the Subscription tier publishes a figure, with pay-as-you-go quoted. For a single-country team with a working supplier and a spare machine or two, it solves a problem you simply don’t have.

Workwize, Firstbase, GroWrk, allwhere and Deel IT operate on broadly similar lines, and not one of the five publishes a rate card you can compare against. The live Workwize domain is goworkwize.com.

Checklist for the one page

Checklist:

  • Standard build options published, with prices.
  • Approval limit stated, with one approver and one deputy named.
  • Suppliers listed by country, with real lead times rather than quoted ones.
  • Credentials in the shared password manager, not in an individual inbox.
  • The urgent path decided and written down.
  • Exception route named, so exceptions go somewhere instead of around.

Final Thoughts

Four decisions, one page. Standard build, approval limit, who orders, and what happens when it’s urgent, written somewhere a stand-in could follow without asking anybody.

Small teams don’t fail at procurement because their process is bad. They fail because the process lives in one person’s head, and the fix is an afternoon of writing rather than a system.

Frequently asked questions

What does a small IT team’s procurement process need?

Four decisions rather than a policy. A published standard build with prices, an approval limit under which nothing needs signing off, a named person who places orders with the supplier details recorded somewhere shared, and a pre-agreed answer for urgent requests. Written on one page, that covers almost everything a team under 100 people encounters.

How many standard build options should we offer?

Two or three. A standard machine, a higher-specification option for roles that genuinely need it, and sometimes a lighter one for people who travel constantly. More than three and the choice itself becomes the work, which defeats the purpose of standardising in the first place.

Should every laptop order need approval?

No. Most approval steps in small companies exist by accident rather than by design. A standard build for a confirmed hire is already an approved cost because the headcount decision carried it, so re-approving it adds delay and changes nothing. Set a value under which nothing needs signing, and name an approver only above it.

How do we handle urgent orders without breaking the process?

Hold a spare pool. Size it from your real replacement lead time. That way an urgent need is met from stock you already own and the replacement order goes in at normal speed through the normal route. The alternative, buying from a retailer, produces a machine outside automated enrollment that becomes a permanent manual exception.

What should we record about suppliers?

What each is used for, which countries they cover, where the account credentials live, and the lead time you have actually experienced. That last one matters most: a supplier quoting five days who reliably takes eleven is useful information, and it is the number that should decide how much spare stock you carry.

When is it worth using a procurement platform?

Count your markets. It’s worth it when you are shipping into countries where you have no supplier relationship and no realistic way to build one. For a single-country team with a working supplier and a spare pool, a platform adds a system to maintain without removing much work. The number of markets, rather than the number of people, is the thing that changes the answer.