Service Request vs Work Order: What Sets Them Apart

A service request (in Portuguese, pedido de serviço) tells the maintenance team that something may need attention. A work order (ordem de trabalho) is the approved, planned and tracked job that follows once someone has checked the request. The request opens the conversation. The work order commits people, time, parts and money, and it is the record that stays in the asset history.

Many teams use the two terms as if they were one document. That works while the volume is low. Once several sites, technicians and contractors are involved, mixing them produces duplicate jobs, unclear priorities and a history nobody trusts. This guide explains the difference, shows where each belongs in the workflow and describes how maintenance software can connect them.

TL;DR

• A service request is an unverified report of a problem or a need. A work order is the verified, approved task with an assignee, a priority and a due date.
• Requests can be incomplete, duplicated or outside maintenance responsibility, so they need a review step before work starts.
• The work order is the document that records labour, parts, time and completion, and it feeds preventive maintenance planning and reporting.
• Keep the two as separate records that are linked, so you can trace every job back to the person who raised it.
• FullyOps handles both in one platform, from request intake to work order closure and analytics.

Table des matières

• The short definitions
• Side-by-side comparison
• Why the difference matters
• How a request becomes a work order
• What each document should contain
• When to use a request and when to create a work order
• Three ways to run the process
• What to look for in software that links the two
• Perspective
• Common mistakes to avoid
• A worked example
• How FullyOps supports the full flow
• FAQ
• Sources

The short definitions

A service request (also called a work request, maintenance request or ticket) is a submission from a tenant, operator, customer or colleague. It says that something is broken, unsafe, noisy, slow or simply needs checking. One facilities management guide describes it as an unverified submission that says something may need attention.

A work order is a formal, written instruction that authorises, schedules and documents a specific maintenance or service task. The same guide says it ties the job to its asset, location, priority, assignee, due date and completion status.

In Portuguese-speaking workplaces you will also meet ordem de serviço (OS). In practice the term often covers what an English-speaking team calls a work order, and sometimes a service order raised for an external customer. Whatever the label on your documents, the useful question is the same: has anyone checked this and committed resources to it? If not, it is a request. If so, it is a work order.

Side-by-side comparison

Why the difference matters

The same guide notes that the most common confusion in facilities management is treating the two terms as synonyms. A request may be accurate, but it may also be incomplete, duplicated, wrongly categorised or unrelated to a maintenance responsibility. A work order is what exists after review: approved, resourced and specific enough for someone to perform and document the work.

Three practical consequences follow.

1. Duplicates. Five people report the same leaking valve. If each report becomes a job, you send five technicians or close four jobs with no work done. A request stage lets you merge reports into one order.
2. Priority. A report that reads “urgent” to the sender is not necessarily urgent for the plant. Review turns an opinion into a priority based on safety, production impact and contractual response times.
3. Clean data. If requests and completed jobs sit in the same list, your counts of jobs, hours and costs are inflated. Separate records keep your maintenance metrics reliable.

How a request becomes a work order

The path is short, but each step has an owner.

1. Submission. Someone raises the request through a portal, a form, a QR code on the asset, an email or a phone call logged by a coordinator. The aim is to capture location, description and contact details in a consistent format.
2. Review and triage. A coordinator checks whether the request is valid, whether it duplicates an open item and whether it belongs to maintenance. They set the category and a first priority.
3. Decision. The request is converted into a work order, merged with an existing one, redirected to another team or declined with a reason.
4. Planning. The work order gets an assignee, a date, the expected parts and the procedure to follow.
5. Execution. The technician carries out the work and records time, parts and findings, ideally on a mobile device at the asset.
6. Closure. The work order is signed off, the requester is told and the cost and history are stored.

This matches the workflow documented in the Formiga Preta guide to incident management, which moves from the customer’s request or ticket to planning (who, when and which services), then field execution with the customer’s signature, and finally closure with billing or cost allocation to a property. The names differ between tools, but the sequence of request, planning, execution and closure is the same.

What each document should contain

A good service request

Keep it short enough that people complete it, and structured enough that the coordinator does not have to call back. The useful minimum is:

• the location or asset, ideally selected from a list or scanned rather than typed;
• a description of the symptom, not the assumed cause;
• a photo or short video when possible;
• the requester’s name and contact;
• whether there is a safety risk or a stopped process;
• the date and time it was noticed.

A good work order

The work order is for the person doing the job, so it should answer every question they would otherwise ask by phone:

• the asset, its location and its identifier;
• the type of work: corrective, preventive, inspection or improvement;
• priority and target completion date;
• the assignee or team and the skills needed;
• step-by-step instructions or a linked checklist;
• parts and materials, with stock availability;
• safety notes and permits where the task requires them;
• fields to record actual time, parts used, findings and sign-off;
• a link back to the originating request.

When the template is consistent, technicians stop improvising and managers can compare jobs. Our guide to the five-stage work order workflow shows how those stages fit together, and the liste de contrôle de gestion des bons de travail covers the fields in more detail.

When to use a request and when to create a work order

A simple rule: use a request when you are informing, and a work order when you are committing.

Preventive maintenance skips the request stage altogether. The schedule itself is the authorisation, so the system generates work orders at the planned interval. Requests exist for the unplanned demand that arrives from people.

Emergencies

Emergencies do not need a slower process, they need a faster one. The request is converted into a work order the moment the coordinator confirms the hazard, and the review notes can be completed afterwards. For security-related equipment such as alarms, cameras or safes, the same logic of verifying a report, prioritising it and then creating a job applies; this overview of maintaining security systems shows how routine checks and reported faults feed into maintenance actions.

Three ways to run the process

Most maintenance and facilities teams in Portugal sit somewhere along one of these models.

1. Email, phone and spreadsheets. Requests arrive in an inbox or by phone, and someone copies them into a sheet or a printed ordem de serviço form. It is quick to start. The weak point is the hand-over: the link between the request and the job lives in a person’s memory, and costs and hours are entered later, if at all.

2. A general ticketing or helpdesk tool. It captures requests well, with statuses and notifications. It usually does not know about assets, maintenance plans, spare parts or technician time, so the work order has to be tracked elsewhere.

3. A maintenance management platform. Requests and work orders live in one system tied to the asset register. A request converts into a work order with one action, the technician sees the job on a mobile device, and parts, time and cost are recorded as the work happens. This is the model FullyOps is built for.

For teams comparing platforms, our articles on logiciel de gestion de la maintenance and on the types de systèmes de gestion d'actifs explain the categories and what to look for.

What to look for in software that links the two

Whatever you choose, check these capabilities against your own process:

• A request portal or form that non-technical people can use from a phone, with required fields so reports arrive complete.
• A triage queue where a coordinator can merge duplicates, set priority and decline with a reason.
• One-click conversion that carries the asset, location, description and photos into the work order.
• Two-way status updates, so the requester sees progress without calling.
• Mobile work orders for technicians, including checklists, time logging and sign-off.
• Inventory links, so parts are reserved and consumed against the order.
• Roles and permissions, so requesters, technicians, administrators and managers see only what they need.
• Rapport on response time, completion time, backlog, cost per asset and the share of preventive versus corrective work.
• Integrations or an API to connect with ERP, accounting or monitoring systems.

If scheduling is your bottleneck, our guide de planification des interventions sur site and the checklist for assigning work orders quickly show how to match jobs to the right technician.

Perspective

We see the same pattern in maintenance teams of every size: the problem is rarely that people report too little, it is that reports and jobs are treated as one thing. When a request is allowed to behave like a work order, nobody owns it. When a work order is created without a request trail, nobody can explain why the job exists.

Our view is that the two records should be distinct and always connected. That is why FullyOps combines work order control, asset lifecycle management, real-time field data collection and operational analytics in one platform built for industrial, facility and maintenance use. The request is the entry point, the work order is the controlled job, and the asset history is where both end up.

Plans for technicians, administrators and managers are designed so each role works with the part of the process that is theirs: the requester reports, the coordinator triages, the technician executes and the manager reads the numbers. For operations managers, the practical gain is visibility: how long requests wait, how many become orders and where the backlog builds up.

Pedro

Common mistakes to avoid

• Converting every request automatically. Without review, you pay for duplicates and out-of-scope jobs. Keep a triage step, even if it takes two minutes.
• Closing the request but not the order, or the reverse. Link them so closure of one prompts closure of the other and the requester is informed.
• Using free text for everything. Categories, asset pickers and priority lists make reports comparable.
• Skipping the work order for small jobs. Short jobs add up. Recording them gives you a true picture of hours and recurring faults per asset.
• No feedback to the requester. People who never hear back stop reporting properly or report the same fault repeatedly.
• Mixing planned and unplanned work in the same list. Tag work orders by type so you can measure how much of your effort is preventive.

Our article on the processus de gestion des ordres de travail shows how a tight process reduces downtime, and the piece on streamlining the service request workflow looks at the intake side.

A worked example

Imagine a facilities contractor looking after several office buildings. On Monday morning three different tenants report that the air conditioning on the second floor of one building is not cooling. These are three service requests.

The coordinator opens the triage queue, sees that all three refer to the same floor and merges them into one item. The report mentions a warning light on the unit, so the coordinator sets a high priority and converts the item into a single work order for an HVAC technician. The order carries the asset identifier, the location, the photos and the maintenance history of the unit.

The technician receives the job on a mobile device, finds a clogged filter and a worn fan belt, records the hours, takes a belt from stock and signs off. The system closes the work order, notifies the three tenants and adds the entry to the unit’s history. A month later the manager sees that this unit has had repeated corrective jobs and adds a preventive inspection to the schedule. Our Liste de contrôle pour l'intervention sur site en CVC follows a similar sequence.

How FullyOps supports the full flow

FullyOps is a cloud-based asset and field service management platform for companies that maintain industrial, facility, electronic or automotive assets. It brings together work order management, preventive maintenance scheduling, technician and team workflows, inventory tracking, reporting and performance analytics, with user roles and permissions and an API for integrations with other systems.

The platform is offered in three plans, Basic, Professional and Advanced, with different levels of functionality for technicians, administrators and managers. Prices are not published on the site, so see the plans on the FullyOps website and ask for a demo or trial that matches your team size and process.

FAQ

Is a service request the same as a work order?

No. A service request reports that something may need attention and has not been verified. A work order is the approved task with an assignee, priority and due date. In some organisations one document plays both roles, but separating them avoids duplicates and unclear ownership.

What is the Portuguese term for each?

A service request is usually a pedido de serviço, pedido de manutenção ou ocorrência, depending on the organisation. A work order is an ordem de trabalho, and in many companies the ordem de serviço (OS) plays the same role. Check how your own documents use the terms and keep the distinction between reporting and authorising.

Does every request need to become a work order?

No. Some requests are duplicates, some belong to another department, and some are resolved with information. Only requests that are valid and within maintenance responsibility should be converted. Declined or merged requests should still be recorded with a reason.

Do preventive tasks need a service request?

No. Preventive maintenance is planned in advance, so the schedule authorises the work and the system generates the work order at each interval. Service requests cover the unplanned demand raised by people.

Who should approve the conversion?

Usually a maintenance coordinator, planner or supervisor, depending on the size of the team. Many organisations also set a cost threshold above which a manager must approve the work order before it is assigned.

Sources

• What Is a Work Order? A Complete Facility Guide, Facility Management Insights
• Gestão de Ocorrências, Formiga Preta

Recommandé

• Qu'est-ce qu'un ordre de travail ? Avantages et types expliqués
• Work Order Approval: Setting Up a Process That Works
• Processus de gestion des ordres de travail pour réduire les temps d'arrêt
• 7 étapes pour une liste de contrôle efficace de la gestion des ordres de travail