Service Request Form
A catalog of everything a facilities team provides, on one form. Sixteen services covering moves, access and passes, room setups, furniture, cleaning, waste, signage, comfort, deliveries, grounds, security, pest, parking and minor works, each with a published target so nobody has to ring and ask how long it will take.
- Sixteen services on one form, not sixteen separate forms
- A published fulfillment target against every service
- An approval threshold, so small requests are not queued for a signature
- Something broken goes on a repair order form instead
Service Request Form
A catalog, not a fault report
| # | WHAT KIND OF REQUEST IS THIS | TARGET | CHARGE | TEAM |
|---|---|---|---|---|
| 1 | Move, add or change, people, desks and equipment | |||
| 2 | Room, meeting or event setup | |||
| 3 | Furniture supply, relocation or removal |
The document you will get. Download for the full, editable file.
Who this service request form is for
One form, and three people who each need it to do something different.
The person making the request
You want one place to ask for anything, and to know when it will happen without chasing. Ticking one service and reading its published target is the whole experience.
Whoever triages it
The service category decides the team, the target and the approval route. Reclassifying a request is normal and the form has a field for it, because people tick what they think it is.
The facilities or workplace manager
The catalog is your service definition. Publishing targets is what converts a stream of ad hoc asks into something with a shape you can resource against.
The budget holder
Chargeable by default, the threshold, and the amount above it. Most requests fall under the threshold and should never have reached you at all.
Where a service catalog earns its keep
The services are common to most occupied buildings. What changes is which ones dominate and how much of the volume is chargeable. If you run one of these, the sector page goes further than the template does.
- Corporate facilities
Offices, where moves, desk changes and room setups are most of the volume and almost none of it is a fault.
Corporate facilities software - Education
Campuses with event setups and heavy term-start demand, where publishing targets is the only way to survive September.
Campus maintenance software - Healthcare
Access, passes and escorts dominate, and the approval route matters more than the timescale.
Healthcare maintenance software - Commercial real estate
Multi tenant buildings, where a request from a tenant and a request from the landlord follow different charging rules.
Portfolio maintenance software - Retail and malls
Store requests across many sites, where a published target is what stops a regional manager calling the helpdesk directly.
Retail maintenance software - FM service providers
Contracted workplace services, where the catalog is effectively the service offer and the targets are what get reported.
FM service provider software
What a service request form should contain
A service request form is one front door for everything a facilities team provides, organized as a catalog of services rather than as a fault report. The requester picks one service, says what they need and by when, and the form carries a published fulfillment target, whether it is chargeable, and the approval threshold that applies.
A. The sections that carry the weight
| Field | What goes in it | Why it earns its place |
|---|---|---|
| About you | Name, department, cost center and how to reach you | The cost center matters more than it looks. Most of these services are chargeable by default, and a request with nowhere to charge it stalls at approval. |
| What kind of request is this | Sixteen services, tick one | The field everything else follows from. One tick, because two services on one form are fulfilled by different teams and the request then moves at the speed of the slowest. |
| Repairs go elsewhere | Something broken belongs on a repair order form | Kept out on purpose. A repair needs to know what is wrong, whether it is getting worse and whether anybody is at risk, and none of those questions belong on a catalog request. |
| What you need, and why | A description, the reason, and how many people it affects | The reason field is worth keeping. It is how a request for six desks turns out to be a request for a meeting room, which is a different and cheaper answer. |
| Items or services requested | Item, quantity, unit and specification, with the date needed | Quantities are what make a request fulfillable without a phone call. Four chairs like the ones in Bay 2 can be ordered; some chairs cannot. |
| When and where | The date needed, the location, and whether it recurs | Recurring requests are the ones worth spotting early, because a monthly ad hoc request is usually a service that should be scheduled instead. |
| Received and triaged | Reference, who took it, the confirmed category and the team | The category is confirmed rather than assumed, because requesters tick what they think it is and reclassification is routine rather than a failure. |
| Target fulfillment date | Taken from the published table, not invented per request | The difference between a service and a favor. A date set per request by whoever answered the phone is not a target, it is a guess. |
| Cost and approval | Chargeable or not, the estimate, the threshold and the amount above it | Calculated rather than judged. Where the amount above the threshold is zero, the request proceeds without a signature. |
| Fulfillment targets by service | Each of the sixteen with a target, charging default, threshold and team | The published table. Agree it once, publish it, and the follow-up calls largely stop. |
| Fulfillment and confirmation | What was actually provided, and the requester confirming it | The confirmation line is what separates a request that was closed from one that was actually delivered, and they are not always the same. |
| Converted to a work order | Whether this became a job, and its number | The bridge out of the form. A request needing site work becomes a work order, which is where it gets scheduled and tracked. |
Publishing a target against every service is the single decision that changes how this form behaves, and the reason is economic rather than administrative. A catalog with no timescales generates a follow-up call on nearly every request, because the only way for a requester to find out when something will happen is to ask. Those calls interrupt the people doing the work, they arrive in no particular order, and in aggregate they cost considerably more than the requests themselves. Publishing a target, even an unambitious one, removes almost all of them. The second decision worth copying is the approval threshold with a calculated amount above it. Most facilities requests are small: four chairs, a lock change, an extra clean. Routing all of them through a budget holder produces a queue in which a genuinely significant request sits behind a trivial one, and the trivial ones wait a week for a signature nobody needed. Where the calculated amount above the threshold is zero, whoever took the request should simply proceed.
B. What it looks like filled in
One request through the process, end to end. The requester never called to ask where it was, and that is the entire point of the middle two lines.
| Line | Value |
|---|---|
| Reference | SR-2027-0662 |
| Service, and what was asked for | Furniture supply, four task chairs |
| Received | 2 April |
| Published target for this service | 16 April |
| Actually completed | 14 April |
| Target met | Yes, two days early |
The requester asked for these by the thirtieth and the catalog promised the sixteenth, which is why nobody chased. That gap is doing the work. A requester who can read the target when they submit knows whether it fits their deadline, and if it does they have no reason to ring the helpdesk, which is the call this form exists to prevent. Had the catalog published nothing, this request would have generated at least one follow-up and probably two, for four chairs that arrived early anyway. The approval side is the other half. Four task chairs is a small amount, almost certainly below the threshold set for furniture supply, so the calculated amount above the threshold is zero and whoever took the request could simply order them. Routing it to a budget holder would have added days to a request that was never going to be refused, and would have put it in a queue behind things that genuinely needed a decision.
Word for a version you want to put on an intranet or hand out, Excel for the one that calculates the amount above the approval threshold and holds a Request Register with days taken and whether the target was met, and PDF for the copy on a reception desk. Free, and yours to rebrand.
How do you run a facilities service request process?
Agree the catalog and its targets before you publish anything. The form is straightforward; the table behind it is what makes the process work. Six steps.
Agree the catalog of services you actually provide
Sixteen in the template, covering moves, access, setups, furniture, cleaning, waste, signage, comfort, deliveries, grounds, security, pest, parking and minor works. Remove what you do not offer rather than leaving it to be asked for.
Route repairs away from it
Something broken needs a different set of questions: what is wrong, whether it is worsening and whether anybody is at risk. Send those to a repair order form and say so on the request form itself.
Publish a fulfillment target against every service
Agree them once and publish them. Even an unambitious target removes the follow-up call, and the follow-up calls cost more in aggregate than the requests do.
Set the charging default and the approval threshold per service
Whether it is chargeable by default, and the value above which a budget holder has to approve. Let the form calculate the amount above the threshold rather than leaving it to judgment.
Triage on receipt and confirm the category
Give it a reference, confirm or reclassify the service, assign the team and set the target date from the published table rather than inventing one.
Fulfill it, then have the requester confirm
Record what was actually provided, whether the target was met, and get the requester to confirm. A request closed by the team and a request the requester agrees is done are not always the same thing.
A service request versus a repair report
Two things people submit to a facilities team, and they need completely different questions asked. Sending one down the other's route is why requests and repairs both get slower.
| Aspect | A service request | A repair report |
|---|---|---|
| What is being asked for | Something provided | Something fixed |
| The first question | Which service, and how many | What is wrong, and where |
| How urgency is set | A published target per service | Safety, and whether it is worsening |
| Whether it is chargeable | Often, by default | Rarely, it is usually covered |
| What it becomes | A fulfillment, sometimes a work order | A work order, usually straight away |
| What it should never ask | Is anybody at risk | How many do you need |
If something is broken, use a repair order form rather than this one. A repair needs to establish what has failed, whether it is getting worse and whether anybody is at risk, and it needs to be prioritized on safety rather than against a published service target. None of those questions belong on a catalog request, and asking them of somebody who wants four chairs is noise. The reverse is equally true: a repair form asking how many you need and which cost center to charge is asking the wrong person the wrong thing while a leak spreads. Keep the two routes separate and say on each which one to use, because the most common failure here is not people choosing wrongly, it is nobody telling them there were two routes.
When the template starts to feel limiting
The file is built for one site with a manageable request volume. Four things start to hurt as soon as that is not the shape of the problem.
One form per request, and a register kept by hand
The Request Register only knows what somebody typed into it, so the answer to what is outstanding is always slightly behind what is actually outstanding.
Nothing watches the target date
Every request carries a target and nothing acts on it. A request drifting past its date is discovered when the requester calls, which is the call the targets existed to prevent.
The requester cannot see progress
Once submitted, a paper or emailed form is invisible to the person who raised it. Every status question becomes an interruption for somebody on the team.
Recurring requests never get spotted
The same ad hoc request arriving monthly is a service that should be scheduled, and on paper it looks like twelve unrelated requests instead of one pattern.
What running this in Facilio looks like
The catalog does not change. What changes is that a request carries its own target and its own status instead of depending on somebody keeping a register.
Ops Performance Intelligence
Targets are watched, not just recorded
Each request carries the published target for its service, so one drifting past its date surfaces before the requester notices rather than after.
Work Order Intelligence
A request becomes the job
Where a request needs site work it converts into a work order directly, so the request and the work that satisfies it stay one record instead of two.
Audit Report Intelligence
The catalog gets a performance record
Because every request is held against its service, it becomes visible which services routinely miss their published target and which are comfortably inside it.
Asset Intelligence
Recurring asks read as a pattern
The same request arriving monthly against the same location is recognizable as a service that should be scheduled rather than as unrelated one-off asks.
Hallucination-free by design. Atom AI answers from the records in your tenant rather than generating plausible text, so an empty field reads as empty rather than filled in for you.
Frequently asked questions
What is a service request form?
It is one front door for everything a facilities team provides, organized as a catalog rather than as a fault report. This one carries sixteen services covering moves and changes, access and passes, room setups, furniture, cleaning, waste, signage, comfort, lighting, deliveries, grounds, security, pest control, parking and minor works.
The requester ticks one service, says what they need and by when, and the form carries a published fulfillment target, whether the service is chargeable by default, and the approval threshold that applies.
What is the difference between a service request and a repair report?
A service request asks for something to be provided. A repair report says something is broken. They need different questions: a repair has to establish what has failed, whether it is getting worse and whether anybody is at risk, and it is prioritized on safety rather than against a published target.
If something is broken, use a repair order form instead. Keeping the two routes separate and saying so on each is what stops both of them getting slower.
Why publish fulfillment targets?
Because a catalog without timescales generates a follow-up call on nearly every request. The only way for a requester to find out when something will happen is to ask, and those calls interrupt the people doing the work.
In aggregate the follow-up calls cost considerably more than the requests themselves. Publishing a target, even a modest one, removes most of them.
Why only one service per form?
Because two different requests on one form are fulfilled by different teams on different timescales, so the whole thing moves at the speed of the slowest one.
If you need two things, raise two requests. It feels like more admin and it is almost always faster, because the quick one is not waiting behind the slow one.
How should the approval threshold work?
Set a value per service above which a budget holder has to approve, and let the form calculate the amount above it. Where that amount is zero, whoever took the request proceeds without a signature.
Most facilities requests are small, and routing all of them through an approver produces a queue where a genuinely significant request sits behind a request for four chairs that was never going to be refused.
Should service requests be chargeable?
Many are, which is why the template records a charging default per service and asks for a cost center on the form itself. Extra cleaning, furniture supply and event setups are commonly recharged; comfort adjustments and access requests usually are not.
Whichever you choose, set it per service rather than deciding request by request, because a charging decision made case by case will not survive its first disagreement.
What happens after the form is submitted?
It is triaged: given a reference, its service category confirmed or reclassified, assigned to a team, and given a target date from the published table rather than an invented one.
Where the request needs site work it converts into a work order, which is where it gets scheduled and tracked. The form records that number so the request and the job stay connected.
Does this replace a helpdesk?
No. It gives a helpdesk something to work from, which is often what is missing: an agreed catalog, published targets and a charging position per service.
It stops being reasonable once volume rises. A register kept by hand is always slightly behind reality, nothing watches a target date, and the requester cannot see progress without asking somebody, which is the interruption the targets were meant to remove.
In one paragraph
A service request form works when it is a catalog rather than a fault report. Agree the services you actually provide, publish a fulfillment target against each one, and set a charging default and an approval threshold per service so small requests proceed without a signature. Send anything broken to a repair order form, because a repair needs to know what is wrong and whether anybody is at risk, and those questions do not belong on a catalog request.
The catalog is the floor, not the ceiling
Agree the services, publish the targets and keep repairs on their own route. Once nothing is watching a target date, or the same request keeps arriving monthly without anybody noticing it should be scheduled, the form has done its job.
