IT Equipment Request template

A procurement form for buying hardware that doesn't exist yet: what's needed, why, the exact spec, cost per unit and quantity, the needed-by date, the manager who approves it, and whether an old device comes back. Its welcome screen draws the line explicitly — borrowing from the shared pool is the equipment checkout form's job, not this one's.

Use this template Start free — no card

10 questions · Free plan: 500 responses/month · fully customizable

1 built-in logic rule

Interactive — fill it in like a respondent would.Open full width

What’s inside

The questions this template ships with — rename, reorder, or delete any of them in the builder.

01Your name and teamShort text

02Your manager's emailEmail

03What are you requesting?Dropdown

04Why do you need it?Multiple choice

05Model and specificationLong text

06Estimated cost per unitNumber

07How many do you need?Number

08When is it needed by?Date

09Is there an old device to return?Multiple choice

10Asset tag of the device being returnedShort text

When to use this template

An IT team standing up a proper request path so laptop purchases stop arriving as Slack messages with no budget owner attached
A People team ordering new-hire kit against start dates, with the needed-by field carrying the deadline that actually matters
A company running a laptop refresh cycle, where the returned-device branch keeps the asset register honest
Any org where 'can I get a bigger monitor' currently has no approver, no cost, and no paper trail

Tips to get more from it

This is not the equipment checkout template, and the welcome copy says so. Checkout books existing shared gear with pickup and return dates; this one asks for a spec, a cost, an approver, and a needed-by date because something has to be bought.
The old-device branch fires on 'No — this is an additional device' and hides the asset-tag question. Requests that replace something capture the tag being returned, which is what keeps a refresh cycle from quietly doubling your fleet.
Cost per unit and quantity are separate number fields on purpose — they multiply cleanly in the CSV export, which is what finance wants when reconciling a quarter of requests.
The manager's email is required and its description explains why: approval routes there first. Wire up response notifications so it actually does.

Questions people ask

How is this different from the equipment checkout form?

Checkout reserves gear you already own — pickup date, return date, and a responsibility signature. This one requests a purchase: model and spec, estimated cost, quantity, manager approval, and a needed-by date. Different questions, because it's a different decision.

Can I require manager approval before procurement sees the request?

The form collects the approving manager's email so the request can be routed to them; approval itself happens in your process, not inside the form. Many teams forward the response email and treat the reply as the sign-off record.