01
Request intake
Request registered
The customer reports a cooling failure by phone and the coordinator immediately records the site, device, symptom and business impact.
Who is it for?
For the owner of a service company, a service manager, coordinator, dispatcher and the team that wants to see one clear case flow from intake to closure.
What does the demonstrator show?
One example layout of a board, case view, manager panel and the history of a single case. It is an explanatory process material, not a production-ready system.
Best next step
If you want to translate this kind of layout into your own workflow, the first useful step is to define statuses, ownership, input data and closure conditions in an audit of one workflow.
Building ServiceOps
What an organised service request board can look like
This demonstrator shows how one service case can move through intake, qualification, execution, documentation, verification and formal closure without losing status, ownership or proof of work.
The board, case card, manager panel and one case history are shown here as one coherent example for HVAC / renewables service, warranties, inspections and field work.
The demonstrator uses fictional data and shows one possible way to organise the process. It is not a live client application, a production-ready system or a solution design for a specific company.
Want a quick self-check first? Use the service chaos scanner.
What is this demonstrator meant to show?
One source of status truth
Each case has a stage, owner, deadline and next step visible without asking several people for the current status.
Proof of work in the same case
Photos, notes, the report and decisions do not live separately across email, chat and the technician’s phone.
Clear closure conditions
A case does not disappear from the board just because the technician visited the site. First the outcome and evidence have to be confirmed.
Example request board
Below is a simplified board with several cases. The main demonstrator story follows case `#SRV-1042`, which at this point has already been assigned and prepared for field execution.
New
#SRV-1048 No inverter reading
Source: email • Priority: medium
#SRV-1047 Rooftop unit noise
Source: phone • Priority: high
Needs qualification
#SRV-1045 Warranty pump inspection
Missing rating plate photo • Waiting for data
#SRV-1044 Drain leakage complaint
Warranty scope to be confirmed
Assigned to technician
#SRV-1042 Cooling failure
Technician: Marek Wrona • Visit today 12:30
#SRV-1039 High-pressure alarm
Technician: D. Kowal • Visit tomorrow
Verification
#SRV-1036 Rooftop inspection
Waiting for report approval
#SRV-1035 Sensor replacement
Missing after-install photo
Ready for settlement
#SRV-1032 Controller repair
Documents complete • Paid job
#SRV-1031 F-gas inspection
Closure confirmed
Case card `#SRV-1042`
The same case visible on the board has all the decisions needed for execution and later closure in one card.
- Customer River Mall, Krakow
- Location Food hall area, AHU-03 unit
- Case type Cooling breakdown outside recurring inspection
- Priority High, impacts tenant operations
- Case owner Service coordinator: Anna Sowa
- Technician Marek Wrona
- Current status Assigned to technician, waiting for field visit
- Time slot Today, 12:30-14:30
- Required evidence Rating plate photo, issue photo, service note, warranty decision
- Next step Visit the site, confirm root cause and complete the documentation
Why does this view matter?
- the coordinator does not need to ask who owns the case and what is still missing,
- the manager can see whether the blockage is in qualification, field work or verification,
- closure is not based only on someone saying “done”, but on a complete set of decisions and evidence.
From service request to confirmed closure
Below the demonstrator shows one fictional case `#SRV-1042` as a sequence of decisions. The point is not the board alone, but making sure every person can see what stage the case is in now, who owns it, what proof exists and what still has to happen next.
02
Qualification and priority
Scope confirmed
The case is classified as a failure affecting tenant operations, so it receives high priority and a rapid visit requirement.
03
Assignment and plan
Visit scheduled
The coordinator assigns a technician with the right qualifications, sets the time window and defines what evidence must be collected on site.
04
Field execution
Work performed
On site, the technician confirms the root cause, performs cleaning and replaces the faulty contactor, restoring cooling.
05
Documentation and evidence
Evidence attached
The case receives the rating plate photo, damaged part photo, after-repair photo and a short visit note.
06
Verification
Checked by coordinator
The coordinator verifies that the scope is closed, the documentation is complete and the customer confirmed that cooling has been restored.
07
Ready for settlement
Ready for settlement
The system or coordinator marks that the case has the full data set needed for settlement or for formal warranty closure.
08
Closure
Closed and confirmed
The case is closed only after execution, documentation, business decision and customer communication are all truly completed.
When can the case be closed?
- when it is clear who owned the case and who approved the final outcome,
- when the work is described and the required photos, report or note are already attached,
- when the customer or coordinator has confirmed the result, if that checkpoint is required,
- when the status leaves no open gaps that block settlement or further responsibility.
What does the manager see in this?
The manager panel does not need every technical detail. It should quickly show where cases are stuck, how many still lack proof and which stages are stretching the process.
14
Open cases today
3
Cases missing full evidence
2
Cases past reaction SLA
6
Cases ready for settlement
1
Case sent back for completion
87%
Closures with full documentation
- whether the issue is at intake, in the field or during verification,
- whether cases return because of missing photos, reports or warranty decisions,
- whether the team really has a “ready for settlement” point and not only “the technician visited the site”.
What changes when the process is organised?
Before
- the case status lives in calls or in the coordinator’s memory,
- proof of work is scattered and hard to verify for completeness,
- closure and settlement get mixed up or happen too late.
After
- each case has a stage, owner, required evidence and next step,
- the manager sees not only ticket counts but also process bottlenecks,
- closure means actual completion of responsibility, not only the end of the visit.
What is always tailored to the company?
Statuses and exceptions
A breakdown, a warranty claim and a recurring inspection do not follow the same path. The demonstrator shows the logic, not a universal status list.
Documentation that requires confirmation
Some companies need only photos and a note, while others also require a signature, report, cost decision or subcontractor settlement data.
The closure moment
In some organisations the case closes after coordinator approval, in others only after customer confirmation or after settlement is linked.
Recommended next step
If this way of running cases should be translated into your own team, the first step is to define the real workflow, roles, exceptions and closure conditions. Only then does it make sense to design a demonstrator, pilot or target tool.