Field service scheduling software for Canadian teams
Every schedule is a promise. Thursday between nine and eleven, someone will be there. The software’s job is to make sure that promise was possible when you made it, that everyone who needs to know about it does, and that when it changes — and it will — the change reaches the customer before they are standing at a window wondering.
This page covers the calendar: capturing work that needs a time, seeing who is actually free, booking, rebooking, and planning repeat visits. What happens on the day itself — the queue, reassignment, statuses and exceptions — belongs to field service dispatch software, and the two pages stay out of each other’s way.
Scheduling versus dispatch and employee rostering
Three categories overlap here and buying the wrong one is a slow, expensive mistake — slow because it takes a few months to notice. The distinction is what each one schedules.
| Category | Schedules | Typical question | Opsler |
|---|---|---|---|
| Field service scheduling | Customer jobs into time slots | “Can we get someone there Thursday morning?” | This page |
| Dispatch | Today’s work against today’s reality | “Kowalski is running two hours late — who takes the 2pm?” | Its own page |
| Employee rostering | People into shifts | “Who is working Saturday, and does that trigger overtime?” | Not supported at all |
Scheduling and dispatch are two halves of one product in Opsler and in most competitors — they are separated across two pages because the buying question differs, not because they are separate tools. Rostering is genuinely a different category, and Opsler does none of it: no shift patterns, no availability requests, no leave, no overtime rules, no payroll.
The terms in the wild are looser than the table. Service scheduling, service scheduling software, field scheduling and scheduling software for service business all usually mean the first row. Anything promising shift patterns and labour cost forecasting alongside customer appointments is either two products or is doing one of them badly.
Capture unscheduled work before choosing a time
Work exists before it has a time, and that gap is where jobs get lost. A quote accepted on Friday, a maintenance visit due next month, a callback promised in spring — none of them belong in the calendar yet, and none of them should live only in somebody’s memory.
Opsler keeps unscheduled work in a queue sorted by priority, sitting on the same screen as the calendar rather than in a separate list. That placement is the whole mechanism. Anything in a separate list is something you have to remember to open; anything beside the calendar is something you see every time you book.
Work arrives in that queue from three directions: a quote the customer accepted, which converts into a job carrying its line items; a job raised directly by the office from a phone call; or a request submitted through your branded booking page, which lands pending review rather than writing itself into the calendar. That last default is the right one — a booking form with direct calendar access will eventually book a job that does not exist.
A practical habit worth adopting whatever software you choose: if the queue is growing week on week, you have a scheduling capacity problem rather than a software problem, and no calendar feature fixes it.
View the calendar, availability and booked jobs
The calendar shows a day or a week, with a lane for each technician and their booked jobs in time order. If you run separate crews — residential and commercial, or two regions — it filters by team so you are not reading past work that is not yours to move.
Availability is the part worth examining closely when you compare products. Each technician shows as available, busy or offline, and each of their booked windows carries a start, an end, the job it belongs to and that job’s status, along with a count of their jobs that day.
Two details make that more useful than a static diary. Busy sets itself while a job timer is running, so the calendar shows who is genuinely on a job rather than who was scheduled to be — a distinction that matters by mid-morning. And the day’s job count gives you a load reading at a glance: four jobs each across three technicians and one with nine is a problem you can see without opening anything.
What the calendar will not do is judge that imbalance for you. It shows the load; it does not level it. Section nine is explicit about that and about the other automation this category tends to imply.
Book and assign a customer appointment
Booking and assigning happen together. Pick the job from the unscheduled queue, put it in a slot, and give it to a technician — the customer, the service address, the access notes and the scope travel with it.
That the context travels is not a small point. A technician who arrives knowing the gate code, that the dog is friendly, and that the last visit replaced a capacitor is a technician who does not phone the office from the driveway. Multiply that by four jobs a day across three people and it is most of a working morning saved somewhere.
Where you are booking a batch — twenty maintenance visits across a week, say — they can be assigned in bulk, and each one settles on its own. If two of the twenty fail, you are told which two rather than having the whole batch rolled back, which is the difference between fixing two problems and starting over.
The booking reaches the technician without anyone confirming it by phone; their view updates on its own. What does not happen automatically is the customer being told — there are no automatic appointment reminder texts, because SMS is planned rather than live. Confirmations to customers go by email, and that boundary is worth checking against every competitor you shortlist, because it is the most commonly over-promised feature in scheduling software.
Rebook cancellations and handle conflicts
A schedule is judged on how it absorbs change, and two kinds arrive constantly: the customer who cancels, and the booking that should never have been made.
The double-booking you nearly made
Assign a technician to a job whose time overlaps one they already have, and Opsler raises an error that names the job it collides with. Not a warning you can scroll past — an error, with the conflicting job identified so you know what you are choosing between.
This matters more than it sounds because double-bookings are never discovered by the person who made them. They are discovered by a technician at 2pm, or by a customer at 4pm, and by then the cost is a phone call, an apology and sometimes the job. Catching it at the moment of booking is the cheapest possible place to catch it.
The cancellation
Cancelling leaves a hole. The unscheduled queue sitting beside the calendar is where you go to fill it, sorted by priority, which is the argument for keeping unbooked work on the same screen rather than in a separate list. Rebooking is moving the job to a new slot, and reassignment records who previously held it — useful three days later when someone asks why the appointment moved.
What Opsler does not do is fill the hole for you. There is no waitlist that automatically promotes the next job, and no suggestion of which unscheduled work best fits the gap. You look at the queue and decide.
Plan repeat work without inventing automation
Recurring work is where scheduling software earns its subscription, and also where its marketing is loosest. Here is exactly what Opsler does.
You create a recurring series against a customer on a fixed interval — monthly, quarterly, annually. Opsler generates the jobs 30 days ahead, so upcoming work appears on the calendar before it falls due rather than the week it is needed. If you want longer visibility, a manual generation run can produce jobs further out, up to a year. A series can be active, paused, completed or cancelled, so a customer putting a contract on hold does not keep producing jobs nobody wants. This is a Pro feature.
Now the honest half, because “recurring” gets sold as intelligence. The series generates on the interval you set. It does not choose a good date, avoid a week when the technician is away, cluster visits geographically, or reschedule around a delay. Generated jobs land in the queue as ordinary unscheduled work and a person books them.
Two further limits worth knowing before you plan a maintenance business around this. There is no contract record — nothing holding a value, a term, covered equipment or an entitlement to a number of visits, and no contract profitability reporting. And because there is no asset register, a series attaches to a customer rather than to a specific unit, so servicing eleven rooftop units at one site quarterly is one recurring job rather than eleven trackable ones. For a business whose value is in per-unit maintenance records, that is the boundary to weigh.
Pass the schedule into the day-of dispatch workflow
The seam between the calendar and the day is the five job states, and they are the same records rather than a handover between systems: pending, assigned, in progress, completed, cancelled.
A booked job is assigned. When the technician starts it, it moves to in progress and the office can see the rest of that person’s day is at risk without ringing to ask. When it closes — with its before photo, after photo and signature — it is completed, and the invoice can be raised from it.
That continuity is why scheduling and dispatch are one product rather than two. Where they differ is the time horizon you are working in: scheduling is a decision about a future slot with capacity in mind, and dispatch is a decision about now with reality in mind. The dispatch page covers the day-of half — the queue, reassignment, urgent work and exceptions. What technicians see and do on their phones is on the mobile field service app page, and the whole lifecycle around both sits in the Canadian field service management guide.
Routes, GPS, skills and automatic optimisation: what to verify
Scheduling software is sold on automation, and the word covers a wide range of things — from “it generates repeat jobs” to “it builds your whole week”. Ask about each capability separately, of every vendor. Opsler’s answers:
Automatic scheduling — no
Nothing chooses a date, a slot or a technician. Every booking is a person looking at the calendar and deciding. Recurring series generate jobs on the interval you set, which is generation rather than scheduling — the generated job still needs booking.
Capacity optimisation — no
The calendar shows you each technician’s load. It does not balance it, does not warn you that one person has nine jobs and another has three, and does not redistribute work. Reading the imbalance is your job; the numbers are there to make it quick.
Skills-based scheduling — no
Technicians carry a skills field you can fill in and read, but nothing matches a job to a technician by skill or filters who can be assigned. Where work needs specific certification — gas fitting, refrigerant handling — the scheduler has to know who holds what.
Route optimisation — yes, on Pro, and you trigger it
Select a set of stops and run it; you get them back in a more efficient order with per-leg distance and driving time. It is a tool you use while planning a day, not a background process, and it does not re-optimise as things change.
GPS — yes, on Pro, at four moments
Location stamps when a technician starts, marks en route, arrives and completes. Not live tracking, and nothing recorded in between. The dispatch page goes into both of these in more detail, since they matter more on the day than in the diary.
Rostering, payroll and attendance — no
No shift patterns, no leave, no overtime rules, no payroll. Technician timers on Pro record work and pause intervals against a job with a reason — that is job costing, not an attendance clock, and treating one as the other will misinform your payroll.
Where those answers rule Opsler out, they should. Microsoft Dynamics 365 Field Service, Salesforce Field Service, Zoho FSM and Fieldcode all publish automated scheduling and optimisation capability, and a business whose scheduling problem is genuinely a computation problem — hundreds of jobs, complex constraints — will be better served by one of them.
Field service scheduling software evaluation checklist
Book a real week, then break it. A calendar that handles an empty week gracefully tells you nothing.
- Load a genuine week for your whole crew and time how long it takes. This is the task you will repeat every Friday afternoon for years.
- Double-book someone deliberately. Confirm you are stopped, and that you are told which job it clashes with.
- Cancel a Wednesday morning job and fill the gap from the unscheduled queue. Count the clicks.
- Set up a quarterly recurring visit and check how far ahead the jobs appear, and whether pausing it stops them.
- Ask the six questions in section nine separately. Vendors answer “do you have automation” very differently from “does it choose the technician”.
- Confirm what the customer actually receives when you book them, and whether it is a real message today or a roadmap item.
- Check the schedule on a technician’s phone, not on a desktop.
- Count seats: at US$25 per seat per month with no minimum, a scheduler and four technicians is five seats, billed in US dollars rather than Canadian.
Steps one to three run on the free Budding plan — two seats, 50 jobs a month, no card. Step four needs recurring series, which is Pro, and the 14-day trial covers it without a card.
What the calendar does and does not do
Checked against the product. Amber means it exists with a condition attached.
| Claim | Opsler | Detail |
|---|---|---|
| Calendar in a day or week view | Filterable by team once you run more than one crew | |
| Unscheduled work visible beside the calendar | Priority-sorted, so accepted work does not go quiet | |
| Per-technician availability | Available, busy or offline, with each booked window | |
| Booked slots showing start, end and job | Plus a count of that technician's jobs that day | |
| Conflict detection on double-booking | Raises an error naming the job it collides with | |
| Book and assign in one action | Customer, address and scope travel with the assignment | |
| Bulk booking of many jobs | Each settles independently; failures reported separately | |
| Rebooking and reassignment | Records who previously held the job | |
| Repeat work on a fixed interval | Pro plan. Generated 30 days ahead; a manual run can extend to a year | |
| Technician job timers | Pro plan. Work and pause intervals with a reason — not payroll attendance | |
| Route optimisation | Pro plan. You trigger it for a set of stops; it is not automatic | |
| Automatic scheduling | Nothing chooses a date or a slot for you | |
| Skills-based scheduling | Technicians have a skills field; nothing matches jobs against it | |
| Capacity optimisation across a team | The calendar shows the load; it does not balance it | |
| Employee rostering and shift patterns | Different category — use specialist workforce software | |
| Payroll and time attendance | Job timers are not a payroll clock | |
| Automatic appointment reminder texts | SMS is planned, not live. Communication is by email |
Those are two questions and they have opposite answers, which is exactly why they should be asked separately. Automatic scheduling: no. Nothing in Opsler picks a date, chooses a slot, or decides which technician should take a job. Every booking is a person looking at a calendar and deciding. There is no auto-scheduling, no suggestion engine, no capacity balancing and no schedule optimisation across a team. Route optimisation: yes, on the Pro plan — but you run it. You select a set of stops and trigger it, and it returns them in a more efficient order with the distance and driving time for each leg. It does not run on its own, it does not re-optimise as the day changes, and it does not decide anything about who goes where. If you want a system that builds the schedule for you, Microsoft Dynamics 365 Field Service, Salesforce Field Service and Fieldcode all publish automated scheduling and optimisation, and that is a genuine reason to look at them instead of us.
Up to a point, and the point is worth knowing precisely. You can create a recurring series on a fixed interval — monthly, quarterly, annually — against a customer, and Opsler generates the jobs 30 days ahead so they appear on the calendar before they fall due. A manual run can generate further out if you need visibility across a longer horizon, up to a year. A series can be active, paused, completed or cancelled, so a contract on hold does not keep producing work. That is a Pro feature. What it is not is contract management. There is no contract record holding a value, a term, covered equipment or an entitlement to a number of visits, and no reporting on contract profitability. And because there is no asset register, you are scheduling against a customer rather than against a specific unit — so quarterly servicing of eleven rooftop units at one site is one recurring job, not eleven.
No, and it is the most common category confusion in this space. Opsler schedules customer jobs — this appointment, at this address, at this time, with this technician. Rostering software schedules people — who is working Tuesday, whether they are on lates, whether that breaks an overtime rule, and how much they are owed. The two look similar on screen and answer completely different questions. Opsler has no shift patterns, no availability requests, no leave management, no overtime rules and no payroll. There are technician timers on the Pro plan that record work and pause intervals against a job with a reason attached — a parts run, a break — but that is job costing, not attendance. If you need to roster staff, use specialist workforce software alongside; the two coexist fine, because one is about your customers' time and the other is about your employees'.
Ready to Run Your Business Without the Chaos?
Scheduling, dispatch, estimates, invoicing, customer portal, and a free branded website — start completely free, upgrade to Pro when you scale.
Free forever on the Budding plan. No credit card required.