A field service scheduling app schedules the drive, not just the job.
Most of what goes wrong in a field service scheduling app is not the calendar. It is the twenty two minutes between the third job and the fourth, the customer who was promised between one and three, and the technician sent to a boiler he is not certified to touch. A board that looks full is often a day that cannot physically be driven. Scheduling is one slice of the wider problem covered in field service apps, and it is the slice that decides whether the rest of it works.
This page covers why travel time sets the real job count, and what a scheduled job has to hold beyond a time and an address. It also covers how recurring maintenance should be stored, and what happens on a technician's phone when dispatch moves a job after the van has left.
See how many jobs fit in a dayThe short version
A full board is not the same thing as a day somebody can drive.
Two numbers decide whether a schedule is real. How long the work takes on site, and how long it takes to get there. The second one is missing from most homemade tools, and by the middle of the afternoon it is usually the bigger of the two.
Everything else in a service scheduling app follows from that. Who can be sent where, how wide an arrival window has to be, what happens when a job overruns, and who has to be told when the plan changes at eleven forty.
Travel time sets the real job count
Most scheduling tools draw a day as a row of slots and let a dispatcher drop jobs into them. The gap between the slots is where the day is actually spent. If a job takes 45 minutes on site and the average drive between customers is 22 minutes, each job costs 67 minutes of the shift, not 45. An eight hour day holds seven of those, not ten.
That arithmetic is why clustering by geography beats sequencing by the order the calls came in. Two jobs in the same postcode on the same morning are worth more than two jobs booked at convenient times an hour apart. A dispatch app that cannot see the map is guessing at the one number that decides the day.
Push this far enough and the scheduler stops being a calendar. Ordering stops by drive time rather than by booking time is the job of a route planning app, and a service business that ignores it ends up running one informally, in a dispatcher's head. Be clear about which of the two you are building, because the data differs. A calendar stores a start time for each job. A router stores a sequence and derives the times from it.
Try it
How many jobs fit in a day
The day starts at 8:00. Every job costs its time on site plus the drive it takes to reach it.
7 jobs fit, 9 booked
Each job costs 67 minutes of the shift, and 33 percent of that is driving. Anything starting after 16:00 is overtime or a phone call to the customer.
Recurring visits are a rule, not fifty two rows
Service contracts are where a homemade scheduler quietly falls apart. A quarterly inspection, a monthly filter change, a weekly clean. The obvious build writes one row per visit for the year ahead and moves on. Then the customer shifts one visit, the contract changes to every six weeks, the site stops taking Tuesdays, and there are fifty rows to reconcile by hand.
The calendar world settled this a long time ago. RFC 5545, the iCalendar specification, defines a recurrence rule with parts for frequency, interval and day of the week, so every second Tuesday is one stored rule rather than twenty six records. The same specification states that the two ways of ending a series, a count of occurrences and an end date, must not both appear in the same rule. Exceptions get their own property, so a single skipped visit is recorded against the series instead of breaking it.
Copying that model is far cheaper than inventing one. Store the rule, generate the occurrences you need to display, and keep any moved or cancelled visit as its own record pointing back at the series. The test is simple. When a customer says same as always but not the week of the fourth, your data should already have somewhere to put that.
When a job moves, the phone has to be told
A dispatcher reassigns a job at eleven forty. The technician is under a house with the phone in a jacket on the van seat. Two separate things have to happen here: the schedule has to change in your data, and the person driving to the old address has to find out. Most scheduling builds do the first and quietly assume the second.
Nothing about a database write reaches a handset on its own. The app learns about a change either by asking again, on a timer or when a screen comes back into focus, or by being sent a push notification. Push is not free either. Apple's guidance is that an app must get explicit permission before it can show an alert, play a sound or badge its icon. The request should come in context rather than at first launch. Once somebody declines, a later request does not prompt them again. A technician who tapped the decline button during onboarding is on the next open path for good.
We checked the default rather than assuming it. An app built with Newly does not push anything unless you ask for it. Notifications are an explicit setup step that connects a push provider, and permission is deliberately never requested on first launch. Skip that step and a reassignment lands in the data, where the technician sees it the next time the app fetches, which in practice is the next time the screen is opened. Even with notifications set up, sending one automatically from your own backend the moment a job changes owner is further work. We did not watch a reassignment arrive on a real handset, and a simulator cannot receive a push at all, so treat the exact timing as unverified. What can be said plainly is that the default is next open, not a buzz in a pocket.
Decide this before you design the board. If a moved job has to reach somebody within minutes, notifications are part of the build rather than a later nicety, and telling the technician the job moved is where those mechanics start.
No signal, and two people accepting the same job
Plant rooms, basements, lift shafts and rural sites all share one property: no usable signal. A technician scheduling app that only works online is a paper run sheet with extra steps. The minimum is that today's list is already on the device before the van leaves, carrying the address, the access note, the site contact and what the job actually is.
Writes are the harder half. If a status can be set offline and sent later, two problems appear. A job accepted at 14:10 and uploaded at 16:30 can overwrite a change somebody made at 15:00, and two technicians can both accept the same urgent call while neither can see the other. Stamp every change with the time it happened, keep a version number on the job, and decide explicitly what a conflict does instead of letting arrival order decide it.
Urgent work is its own scheduler anyway. Sending the nearest available unit, the way a tow truck app does, is a different problem from filling a booked calendar, and most service businesses run both at once. Trying to serve both from a single board is a common reason a scheduling build stalls halfway.
What each approach gives a dispatcher
| Option | Drive time in the plan | Recurring contracts | Tells the technician | Fits your own rules |
|---|---|---|---|---|
| Shared calendar and phone calls | No | one entry per visit | you ring them | Yes |
| Spreadsheet board | No | copied by hand | you ring them | Yes |
| Scheduling inside your accounting tool | No | sometimes | No | No |
| Off-the-shelf field service platform | Yes | Yes | Yes | generic |
| A scheduling app you build | if you add routing | Yes | if you wire notifications | Yes |
Building one around your own job types
Field service platforms are priced per technician per month and shaped around a generic job. A six van operation pays for a parts catalogue, an invoicing module and a customer portal it never opens, then hits the one rule the platform has no field for. A two person job that occupies one slot. A site that can only be visited when the manager is in. A permit that has to be pulled 48 hours ahead. A customer who must be phoned an hour before arrival or the visit is wasted.
Newly is an AI app builder. You describe the scheduling rules you actually run, and it writes a React Native and Expo project you own, running it on a cloud simulator while it builds. It costs $25 a month, there is no free plan, and iOS builds go out through TestFlight using your own Apple Developer account. It does not arrive with a dispatch engine, licensed map data or invoicing, and it is not a field service platform. It is what you reach for when the platform is built for a company four times your size.
Start by writing down one real week, including the two jobs that overran and the one nobody could get into. Those are your rules, and there are usually fewer of them than people expect. A board built around them beats a board built around a generic job, and it is a much smaller thing to build than it looks.
Questions people ask about field service scheduling apps
It assigns jobs to technicians and to times, then keeps that plan and the people working it in agreement. What separates it from a shared calendar is that it knows how long the work takes, how long the drive takes, who is allowed to do the job, and what the customer was promised.
Describe the week your technicians actually work
Write down one real week of jobs, the two that overran and the one nobody could get into, and build the board around those rules instead of a generic one.
Start building