Service Order Handling Step by Step - From Intake to Settlement

Most service businesses start the same way. Requests arrive by email and phone, someone logs them in a spreadsheet, the technician gets a message on chat, and you check the state of a case by asking whoever is handling it.

This works. At a dozen or so orders a month and two people in the workshop it works rather well - it is cheap, flexible, and nobody has to learn anything new. It is worth saying so upfront, because articles about "digitising your service operation" usually pretend a spreadsheet never makes sense.

The trouble starts not when there are many orders, but when they stop being alike. One is waiting for a part, another for the customer's decision, a third for a technician to travel out, a fourth for the manufacturer to respond. Each one is stuck for a different reason and each one is on a different clock - and the spreadsheet shows them all the same way.

Below are the seven stages a service order passes through. Each one follows the same pattern: what happens, what has to be recorded, and what stops working when that record is missing.

1. Intake and identifying the device

Requests come in through several channels at once: email to the service inbox, a phone call to the office, a form on the website, sometimes through a distributor or a retail chain. The first action is always the same - establish what the case is actually about.

And this is where the first fork appears. In retail you identify the order. In service you identify the individual unit.

What has to be recorded: the serial number or another identifier for the unit, the model, the date of purchase or installation, the customer, the intake channel, and the fault described in the customer's own words.

What breaks without it: the customer calls for the third time about the same heat pump, and the question is "what have we already done to it" - not "which invoice was it on". Without a record tied to the unit, the answer lives in the memory of a technician who happens to be off that day. The second symptom is quieter: the same device comes back for a third time, nobody notices, and nobody draws the conclusion that there is a batch fault.

It is also worth capturing how the customer described the fault - in their words, before diagnosis. Later, in an argument about the scope of a repair, that is often the only record of what the case actually arrived as.

2. Qualification: warranty or paid work

Before anyone picks up a screwdriver, somebody has to decide whether this is a warranty repair or a paid one. That is a decision about money, and about who ultimately pays for parts and labour.

I am not going to settle here what that qualification should look like in legal terms - it depends on the product, on your agreements with the manufacturer and on the warranty conditions. What matters here is the operational layer: who makes the decision and on what basis.

What has to be recorded: who qualified the case, when, on what grounds (purchase date, warranty terms, arrangements with the manufacturer) and what the outcome was.

What breaks without it: the qualification happens in a phone call and leaves no trace. Three weeks later the customer insists you agreed on a free repair and the technician remembers otherwise. There is nothing to check. In companies where sales staff make arrangements outside the service department, this problem multiplies by the number of sales staff.

There is a second, internal consequence. If qualification is not a separate, deliberate step, some orders move on without it - and that only surfaces at invoicing, when the equipment is already back with the customer.

3. Diagnosis

The technician examines the device and establishes what is actually broken. This is the stage that produces the most knowledge about the case - and the stage where most of that knowledge is lost.

What has to be recorded: the established cause, the diagnostic steps performed, photographs (especially for mechanical and transport damage), the list of parts required, and the estimated repair time.

What breaks without it: the diagnosis comes back to the office as a single line on a chat app. Enough to order a part - not enough to explain to the manufacturer six months later why you treated the fault as a warranty case. Photographs taken on the technician's phone stay on the technician's phone.

Diagnosis is also the first point where a case can genuinely stall. The device sits on the bench, the technician has been sent out on an urgent call, and comes back in three days. For those three days the spreadsheet shows exactly what it showed yesterday.

4. Quotation and customer approval

Paid repairs add a step that warranty work does not have: the customer has to approve the cost before you start.

This stage is the single biggest bottleneck in most service operations, because the waiting time is not yours to control. You send the quotation and you wait. The customer replies today, tomorrow, or in a fortnight.

What has to be recorded: the content of the quotation, the date it was sent, the channel, and the date and form of approval or refusal.

What breaks without it: the quotation goes out from an individual's mailbox and nobody else knows the case is waiting on the customer rather than on the workshop. The device takes up bench space, the statistics say "repair taking 21 days", and the truth is "we have been waiting for an answer for 16 days". Those are two completely different pieces of information - the first looks like a problem with your service department, the second like a reason to pick up the phone.

Refusals need a path of their own too: what happens to a device the customer will not collect and will not pay to have repaired. Without a defined ending, cases like that stay open indefinitely and clutter every list you look at.

5. Spare parts

Ordering spare parts is the point where an order enters a waiting state - and most often drops out of sight.

What has to be recorded: which part, ordered from whom, when, the delivery date promised, and which order it belongs to.

What breaks without it: "waiting for a part" is not a status. It does not say which part, since when, or whether the supplier is already late. With twenty cases like that, nobody is tracking any of them individually - the one being tracked is whichever one a customer just asked about.

A common variant of the same problem: the part arrives, sits in the stockroom, and nobody connects it to a specific order because the person who ordered it is on leave. The device waits another week for something that is physically two rooms away.

This is also the clearest illustration of why a clock on the whole case tells you little and a clock on the stage tells you everything. "Case open 24 days" says nothing. "Waiting for a part for 12 days against a 7-day limit" says the supplier is late and someone needs to call - today, not when the customer calls you. That is what a time limit on the stage and escalation once it is exceeded are for.

6. Repair, inspection and handover

The repair itself is usually the shortest stage of the whole process - which tends to surprise companies measuring their process for the first time. Most of the time in a service operation is not spent working, it is spent waiting: on a decision, on a part, on a customer.

What has to be recorded: what was done, which parts were consumed, who carried out the work, the inspection result, the handover date and confirmation of collection.

What breaks without it: the customer collects the device and is told verbally that "we replaced the controller". Six months later the same unit returns with a similar symptom and nobody can establish whether it is the same fault or a new one. Without consumed parts tied to the order you also cannot calculate what a repair actually costs you - and therefore whether your rates make sense.

Handover is the last moment at which anything can still be established. After the device leaves, everything that was not written down is gone for good.

7. Settlement with the manufacturer

If you operate as an authorized service point, the order does not end when the device goes back. It ends when the manufacturer accepts the repair and pays for it.

This is the stage that guides to "running a service department" tend to skip, and the one that can decide whether the department is profitable at all.

What has to be recorded: the claim number at the manufacturer, the amount claimed, parts consumed with their numbers, whatever documentation the manufacturer requires, the settlement status and the payment date.

What breaks without it: the repairs you have claimed and the repairs you have been paid for stop matching. You discover it at the quarter close, when reconstructing three-month-old documentation means searching through mailboxes. Some claims are rejected because a photograph or a part number is missing - and nobody remembers where those were.

It is also the strongest argument for producing data during the process rather than collecting it afterwards. The documentation needed for settlement is mostly the same material that stages 1 to 6 already generated. The only difference is whether it was recorded in one place or scattered across inboxes and phones.

What this means for the system

Looking at those seven stages together, two things stand out.

First, each has a different owner. The office takes the case in, the technician diagnoses, the customer approves, the supplier ships a part, the manufacturer settles. The case changes hands several times, and each handover is a place it can stall.

Second, each has a different clock. Diagnosis should take two days, waiting for a part seven, waiting for customer approval five. A single counter on the whole case averages all of that into a number nothing follows from.

That is why what matters in a service management system is not how many fields the form has, but whether it lets you model your process as it actually is - with your own stages, permitted transitions, and time counted separately on each of them. In Reklamator you define the stages, statuses and transitions yourself, each request type can have its own process, and the system colours cases approaching their deadline and escalates the ones past it instead of waiting for somebody to notice. Business rules react to a stage change - sending an email, sending an SMS, assigning the case to a specific person.

One clarification, so there is no misunderstanding: the system enforces the deadlines you set in it. Which deadlines apply to your business follows from the law and from your contracts - no software settles that for you.

When a spreadsheet genuinely is enough

Back to where we started, because this is the honest half of the answer.

If you handle a dozen or so orders a month, one or two people in the same room deal with them, the cases all look much alike, and nothing tends to wait longer than a few days - the spreadsheet is the right tool. Rolling out a system in that situation solves a problem you do not have.

The signals that it has stopped being enough are fairly specific:

• somebody regularly asks "what stage is this at" and answering requires calling another person
• you cannot say off the top of your head how many cases are waiting on a part and how many on a customer
• the same information lives in three places: the spreadsheet, an inbox, and a technician's head
• when one person leaves, part of what is known about live cases leaves with them
• settling with the manufacturer means reconstructing documentation rather than retrieving it

If two or three of those sound familiar, the problem is not the number of orders. The problem is that the state of a case lives in people rather than in a system.

Frequently asked questions

How many orders a month before a system pays off?

Order volume is a worse indicator than the number of people and request types involved. A hundred similar repairs handled by two people is a simpler case than thirty orders passing through an office, two field technicians, a stockroom and a manufacturer. What settles it is how many times a case changes hands.

Can we start without mapping the whole process?

Yes, and it is usually better that way. The most elaborate process running for one of our customers today has 138 stages, but it did not start at 138 - it started at five. A sensible starting point is intake, diagnosis, repair, handover and closure; the detail gets added once it turns out cases are stalling somewhere you cannot see.

Is this a complaints system or a service system?

In practice it is the same process at different points. A complaint is often the start of a service order, and a scheduled inspection can turn into a warranty repair. If you are weighing up whether you need a separate tool or whether the module you already have will do, six questions settle it in a separate article.

What about technicians in the field?

It is the same problem as with parts, only with GPS: the case is with someone who is not in the office. What solves it is less a mobile app than permissions on stages - the technician sees and changes only what belongs to them, the manager sees everything, and the end customer sees the status.

Where do we start if everything is in email today?

By writing down the stages an order actually passes through and measuring how long each one really takes. That is a pen-and-paper exercise, not a rollout, and it usually reveals the bottleneck on its own. Only then is it worth looking for a tool, because by then you know what you want from it. If you want to see what such a process looks like once it is in order, we have also written up automating request handling step by step.