Powstania Warszawskiego 15
31-539 Kraków
Every field service project eventually reaches the same question: does the office get its own application, and if so, how much of one. The answer decides a large part of the budget and the calendar, and in a first version it is usually smaller than anyone expects.
Custom dispatch software is a second application, not a screen attached to the mobile app. In a first version the office usually needs three things: a live view of job status, the ability to correct a record by hand, and visibility of anything that failed to arrive. A full dispatch board with drag and drop scheduling, route optimization and a customer portal is a separate phase, and deferring it is the most common way a field service project launches inside a quarter rather than after it.
Because it is one. A dispatch view has its own users, its own permission model, its own data volumes and its own failure modes, and none of that comes for free once the mobile app exists.
The mobile app serves one person doing one job at a time. The office view serves someone looking at a week of work across a whole team, reassigning it, and answering a customer on the phone while they do it. Those are different products that happen to share a database.
That is why a full dispatch board is usually the largest optional block on the plan, and why moving it to a later phase is the lever that turns a long project into a launch. What the rest of the calendar looks like is in how long a field service app takes.
Three functions. Without them the operation depends on developers for ordinary exceptions, which is not a workable way to run a business.
A list of today's jobs with status, who has them, and what came back from site. Not a dashboard with charts. A reliable list that removes the reason to phone a technician for an update.
Somebody has to be able to fix a job from an admin panel or from the app itself when something goes wrong, without a developer. This is a small piece of work during the build and an expensive one afterwards.
Anything stuck in a queue or rejected by another system has to be visible to a person, with a way to resend it. A silent failure is how a week of billable work disappears.
Assigning work and moving it between crews, in whatever form is simplest. A form and a list are enough here. The visual board is a convenience, not a capability.
Everything on that list is about keeping the operation self sufficient. Nothing on it requires a scheduling calendar, a map view or role based dashboards.
The office does not need a beautiful board in version one. It needs to stop phoning technicians for status, and to be able to fix a wrong record without calling us.
Most of the visual dispatch layer can wait, and waiting produces a better version of it, because by then you know how the field side actually behaves.
Deferring these is not cutting corners. It is spending the budget on the part that carries the operational return, which for most operations is the gap between work finished and invoice sent. What decides that gap is set out in field service app requirements.
You settle it with a rule during scoping rather than discovering it in production. The usual rule: the office wins on assignment and scheduling, the field wins on job outcome.
That split works because it follows who knows. The dispatcher knows a job moved to another crew. The technician knows what was found on site and how long it took. Neither side should be able to overwrite the other on its own ground.
The case that actually needs care is a job reassigned in the office while a crew is already working on it with no signal. The outcome from the field still has to land somewhere, even though the assignment changed underneath it, which is why work created offline carries its own identity.
The three meanings of offline are separated in what offline means in a mobile app, and the architecture behind it in offline first app development.
Who can reassign a job after a technician has started it, and does the technician see that it happened?
What does the office see while a crew is offline, and is that state visible as pending rather than as nothing?
Who can edit a completed job, and is the change recorded as a correction rather than as the original truth?
When scheduling, customers and invoicing already work there. In that case the right project is a technician app that writes back, not a replacement for a platform your office knows.
This is more common than vendors admit. A business can be perfectly served by its existing back office while the field side is the part that fails, because the mobile experience was an afterthought in a product designed for the desk. Rebuilding the whole thing to fix the field is an expensive way to solve the wrong half.
The decision comes down to where the rules live. If the logic that decides what is billable sits in your platform and works, keep it and connect to it, as described in where the field service app writes back. If those rules live in spreadsheets and people's heads because the platform cannot express them, that is one of the signals in when you outgrow field service software.
In heating and cooling the deciding factor is often service agreements and the unit as the record, which most generic boards handle poorly. That case is covered in custom HVAC software development, and inspection operations have their own version of it in inspection app development.
Sit with the dispatcher for a morning and write down every action taken outside the current software. Those actions are the specification, and there are usually fewer of them than the wish list suggests.
Count the calls made purely to assign work or ask for status, the times a record had to be corrected after the fact, and the moments someone rekeyed information from one system into another. Each of those maps to one of the four day one functions, and anything that does not map is a candidate for a later phase.
Then ask which of them would still be necessary if the field app worked perfectly. That question removes a surprising amount of proposed office functionality, because much of it exists to compensate for information that never arrived from site. A structured way to run this is the app discovery workshop, and how the scope becomes a committed number and date is in fixed price app development.
A shipped example of the field first approach, where coordination and documentation came before any full board, is the TimeFix case study. The service page is field service app development.
Most operations start with the mobile app plus a minimal office view: job status, manual correction, failed sync visibility and a simple way to assign work. A full dispatch board is a second application and is usually better built once the field side is running and the real scheduling patterns are visible.
The minimal version is a modest part of the build. A full dispatch application with scheduling, mapping and reporting typically adds several weeks and moves a project from the shorter band into the longer one. The bands by project shape sit on the pricing page.
Often the best answer. If scheduling, customers and invoicing work where they are, a technician app that writes back into that system solves the failing half without replacing what already works. It also keeps the office out of retraining.
The assignment change belongs to the office and the work already done belongs to the field, so both have to survive. Work created offline carries its own identity rather than depending on the current state of the job, and the office sees anything still pending rather than an empty record.
Yes, with the change recorded as a correction. Errors happen and a business cannot wait for a developer to fix a wrong time entry. What matters is that the original entry and the correction are both visible, particularly where the record supports an invoice or a compliance report.
Web, in almost every case. Dispatchers work at a desk with a large screen and multiple jobs in view, and a browser avoids store releases for every change. The mobile app stays focused on the person doing the work on site.
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Describe how your dispatcher spends the morning and we will tell you which parts belong in version one, which belong in the platform you already run, and what that does to the timeline.
30 minutes, no preparation needed.