Home / Case Studies / VSYS
Case Study — Service Business Operating System
VSYS: built from the ground up to run a service business — not to watch the people running it.
Fistreet built VSYS by studying a real service operation from the ground level — every enquiry, quotation, installation, service call and spare-parts request — and turning that understanding into one connected, SOP-driven operating system. It is deliberately built without GPS or continuous employee location tracking.
Project Snapshot
What VSYS is, in one view.
Service-based enterprise — equipment sales, installation & field service
VSYS — a purpose-built service-business operating system
Lead through after-sales: sales, installation, service, spare parts, reporting, management visibility
Ground-level study → SOP definition → digitisation → automation → training → refinement
Trust over tracking. Structure over surveillance.
The Business Challenge
Real operations, running on memory and improvisation.
Before VSYS, the business ran the way most growing service organisations do — through individual effort, memory, and a patchwork of tools. The work was getting done. But it depended on who was doing it, and nothing about the process would have survived that person's absence.
Sales follow-ups depending on individual memory
Whether a lead was followed up — and when — lived in someone's head, not in a system.
Customer information scattered across systems and WhatsApp
Requirement notes, quotations and conversations sat across chats, notebooks and spreadsheets.
Quotations losing visibility after being sent
Once a quotation went out, there was no reliable way to see whether it needed a follow-up, a revision, or was simply forgotten.
Manual service coordination
Assigning a service request to the right engineer, at the right time, was a phone-call-driven process.
Engineers working with inconsistent processes
Two engineers could handle the same kind of job in two different ways, with no shared standard to follow.
Spare-parts requirements disconnected from service
What an engineer needed on-site and what the spares store knew about often didn't match up.
Incomplete or inconsistent service reporting
What was actually done at a service visit wasn't always captured — or captured the same way twice.
Management repeatedly asking teams for updates
Status on a lead, a quotation, or a service case meant picking up the phone and asking someone.
Business dependency on individual employees
Institutional knowledge lived in people, not in the business.
Lack of continuity when a key employee was unavailable
Leave, transition, or turnover meant work — and context — could stall.
Why We Started From The Ground
Software should follow the business — not the other way around.
VSYS didn't begin with a feature list or a template. It began with time spent inside the actual operation — sitting with the sales team, walking the service floor, going through the registers and documents already in use, and understanding who was responsible for what, and why things were done the way they were.
Only once that ground-level picture was clear did the work of defining a Standard Operating Procedure — and then a system to run it — begin.
The Key Decision
Trust over tracking.
GPS and continuous employee location tracking have legitimate uses in other contexts. For this project, we made a deliberate decision: continuous location tracking was not required to achieve real operational accountability. We chose to build trust into the system instead — through clear SOPs, defined ownership, and visible work — rather than watch where people were.
Give the team the tools to do the work correctly, without assuming the worst.
Define the one correct, repeatable way each piece of work should happen.
Every step has a clear owner and a clear status — by design, not by supervision.
Let the system carry the repetitive parts of the SOP, so people don't have to.
Give management a real view of pending work — without needing to ask anyone.
GPS vs Operational Visibility
Two completely different kinds of information.
GPS can tell management where a person is. It cannot tell management what work is happening. VSYS was designed around the second question, not the first.
- Where a person is right now
- How far they have travelled
- How long they stayed at a location
- Whether a site was physically visited
- Which customer was handled, and what they need
- Whether a quotation is required, sent, or pending action
- Whether follow-up happened, and what the next action is
- Which machine has a problem, and what diagnosis was made
- Which spare parts are required for the job
- Whether the service report and customer confirmation are complete
“Location is one type of information. Operational information is something completely different.”
SOP As The Foundation
Understand the process. Then digitise it.
VSYS does not digitise chaos. It helps establish a correct, repeatable way of working — and only then automates around that structure.
Understand
Study how the work actually happens today.
Define the SOP
Agree the one correct way to do it.
Digitise
Turn the SOP into a software workflow.
Automate
Remove repetitive manual effort where it helps.
Create Visibility
Surface status to the people who need it.
End-to-End Business Flow
One connected journey — from first enquiry to the next service visit.
Every stage below sits inside the same system, with the same customer, machine and history carried forward from one stage to the next.
Phase 1 — Sales & Order
Lead
Enquiry
Requirement
Follow-up
Quotation
Negotiation
Order
Phase 2 — Delivery & Service
Installation / Delivery
Service Request
Engineer Action
Spare Parts
Phase 3 — Closure
Service Report
Customer Confirmation
Closure
Phase 4 — Continuity
After-Sales
Service Planning
Management Visibility
Sales Workflow
From first enquiry to a confirmed order.
Lead & requirement capture
Every enquiry is logged against a customer, with the actual requirement recorded — not left in a chat thread.
Follow-up visibility
What needs a follow-up, and when, is visible to the salesperson and to management — not dependent on memory.
Quotation tracking
A quotation stays visible after it's sent — whether it's pending, being negotiated, or needs a revision.
Negotiation history
Terms discussed and positions taken are recorded against the opportunity, not lost between conversations.
Order confirmation
A confirmed order carries its full history — requirement, quotation and negotiation — into delivery and installation.
Service Workflow
From a service request to a confirmed closure.
Service request logged
A request is raised against a specific customer and machine, not a generic ticket.
Engineer assigned, with history
The assigned engineer sees the customer and machine history before arriving — not just an address.
Diagnosis recorded
What the engineer finds is captured against the job, as the SOP requires.
Spare-parts requirement raised
If parts are needed, the requirement is raised from the job itself — connected, not separate.
Service report completed
Work performed is recorded in a consistent, structured format — every time.
Customer confirmation captured
The job isn't closed until the customer's confirmation is on record.
Spare Parts & Inventory
What the engineer needs, connected to what the store holds.
A service diagnosis and a spare-parts requirement used to live in two different worlds. VSYS connects them directly.
Spare-part need discovered on-site, communicated informally after the visit
Spares team finds out about a requirement well after the engineer has already been there
No shared record connecting a specific job to the part it needed
Spare-part requirement raised directly from the diagnosis, against the job
Spares team sees the actual requirement as part of their normal workflow
Every part used is traceable back to the service job it was used for
Service Reports & Customer Confirmation
Work isn't done until it's recorded — and confirmed.
A service report in VSYS follows the same structure every time — what was found, what was done, which parts were used, and what's recommended next. That consistency is what makes the history useful the next time this customer or this machine comes up.
And a job is not considered closed on the engineer's word alone. Customer confirmation is the actual closure gate — not a formality added afterwards.
After-Sales & Service Planning
Closure isn't the end of the relationship.
Once a service case is closed, the history stays attached to the customer and the machine — ready for the next visit, whoever handles it. Future service needs are planned from that history, rather than rediscovered from scratch each time.
Quick Actions
“People don't want to operate software. They want to complete work.”
Every screen in VSYS is built around that idea — quick actions, a clear next step, and the minimum data entry needed to move the work forward.
Log Requirement
Send Quotation
Record Follow-up
Confirm Order
Assign Engineer
Log Diagnosis
Request Spare Part
Submit Service Report
Confirm Closure
Schedule Next Service
Automation Built Around SOP
Automation should strengthen the SOP — not replace the thinking behind it.
Every piece of automation in VSYS exists to reinforce a step the SOP already requires — never to skip the judgment the SOP is there to protect.
- A pending quotation that needs a follow-up is surfaced automatically, instead of relying on someone to remember it
- An incomplete service report is flagged, instead of quietly staying incomplete
- Upcoming and planned service needs surface on their own, from the customer and machine history
- Jobs waiting on customer confirmation stay visible until they're actually confirmed
Team Engagement, Not Surveillance
Built for the people doing the work, not for watching them.
VSYS is not positioned as employee monitoring. It's positioned as team enablement — replacing questions with visible answers.
- Sales sees the customer information relevant to their conversation.
- Service sees customer and machine history before a job even starts.
- Engineers have the information they need to do the job, not just an address.
- Spare-parts teams see the actual requirement, connected to the job.
- Management sees pending work and operational status, without asking anyone.
Reducing Dependency On Individual Memory
The business shouldn't stop when one person is unavailable.
When a customer's history, a machine's service record, and a pending action all live in the system rather than in one person's head, the business keeps moving even when that person is on leave, has moved on, or is simply busy elsewhere.
“The system should remember. The employee should execute. The manager should guide. The SOP should provide the structure.”
Ground-Level Implementation
Trained where the work actually happens.
VSYS wasn't rolled out from a slide deck. The actual sales and service team was trained on the actual system, in the actual working environment — then the workflows were tested, gaps were identified, the system was refined, and it was tested again.
Building VSYS together — process discussion, workflow design, system implementation and team enablement, worked through in the same room.
What We Deliberately Did Not Build
Sometimes product judgment means choosing not to build something.
GPS and continuous location tracking are the clearest example: technically straightforward to add, and deliberately left out — because they weren't what this business needed to run accountably. The same discipline applied elsewhere in VSYS. Not every feature that could be built belongs in the system, if it doesn't serve the SOP or strengthen the team's trust in it.
“Don't build software that watches people. Build software that helps people do their work correctly.”
The VSYS Operating Model
Every piece of work answers five questions.
What happened?
Recorded as it occurs — requirement, diagnosis, report, confirmation — not reconstructed afterwards.
What is happening now?
Current status is a live view, not a question someone has to answer.
Who is responsible?
Every stage has one clear owner, defined by the SOP.
What happens next?
The SOP defines the next action — it doesn't need to be reasoned out each time.
When is it complete?
Closure has a defined condition — such as customer confirmation — not a guess.
What Makes VSYS Different
Not a generic CRM. Not a tracking app.
- Designed from ground-level study of a real operation, not adapted from a generic template
- Built around a defined SOP for every stage of the sales-to-service journey
- Accountability engineered through ownership and visibility — not location surveillance
- Spare parts, service and reporting connected as one workflow, not separate systems
- Interface built around quick actions and clear next steps, not data entry for its own sake
- Management visibility into pending work, without needing to ask the team for status
- Continuity that doesn't depend on any single employee being available
Implementation Philosophy
How VSYS actually got built.
Ground-level business study
Understand actual workflows
Understand people & responsibilities
Study documents & existing processes
Define the SOPs
Convert SOPs into software workflows
Add quick actions
Automate repetitive actions
Train the actual team
Test workflows
Identify gaps
Refine the system
Test again
VSYS is not about tracking people. VSYS is about structuring the business.
Trust, SOP, accountability, automation and visibility are not separate features — they're one connected way of running a service business, built from the ground up around the people who actually run it.
Ready to structure your own operation?
Every Fistreet engagement starts the same way — a ground-level look at how your business actually runs today, before we write a single workflow.