Providers don't plan that way. Someone who fixes things for a living runs their week around routes and other jobs. A job pinned to one exact slot only works for providers who happen to be free right then. So we designed four ways to schedule a job instead of one:
- A fixed date and time, as before.
- A fixed date and time plus a backup, so the provider picks one of the two.
- A date, with the provider choosing the time.
- A time, with the provider choosing the date.
The goal was written into the spec in plain words: make it easier for the customer and the provider to find a time that suits both, so more providers apply. Flexible scheduling isn't a nice extra. It's how a customer's week gets matched to a provider's.
Every option changes the rules
Four options sounds like four date pickers. It's four sets of rules, and most of the work is in the rules.
Take expiry. A job with one fixed slot expires when the slot passes. A job with a backup date can't expire until both dates have passed. A job where the provider picks the date can't expire on a date at all, because there isn't one yet, so it stays open until a provider is chosen. Once a provider is hired, every job switches to the date and time both sides agreed.
Then there's applying. When a customer leaves the time open, a provider can't apply until they've chosen one, so the apply button stays off until they do. Once they've applied, their choice is locked. The customer sees each applicant's proposed time next to their name, which turns choosing a provider into choosing a slot.
None of that shows up in a mockup. All of it decides whether the feature works.
Don't break the people who haven't updated
Mobile apps have a problem websites don't: people keep running old versions. When NEBO's scheduling changed, providers on the previous version still had to see and apply for jobs created with the new options.
So the new data had to make sense to the old app. A job with a backup date shows older versions the primary date. A job where the provider picks the time shows a sensible default time. A job where the provider picks the date shows a default date a couple of business days out. Nobody on an old version gets a broken job, and nobody is forced to update to keep working.
That kind of thinking rarely makes a feature list. It's the difference between a release that goes quietly and one that fills the support inbox.
Write the spec like a test plan
The NEBO scheduling spec wasn't a list of features. Every scheduling option got its own use case: the goal, what has to be true before it starts, what success looks like, and a long list of the ways it can fail. The customer can't open the scheduling window. The provider can pick a time that's already passed. The apply button stays off after a valid choice. Each failure is a test someone runs before release.
Writing the failures down first changes the design. You notice that a provider shouldn't be able to choose a time outside the window the customer allowed, or a date in the past, before anyone has built the screen that would let them.
Both sides need the same picture
A booking always has at least two people looking at it. The customer's dashboard, the provider's dashboard and the job details all have to show the same scheduling information, in the same words, at every stage. When one side sees "Tuesday, any time" and the other sees "Tuesday at 10 am", trust goes fast.
We write that into the spec as a test, not a hope: for every scheduling option, check what the customer sees and what the provider sees, from posting the job to finishing it.
Every scheduling project picks up extra requests. On NEBO, they included a live map so customers could see their provider on the way, optional before-and-after photos when a job is finished, and labor and materials shown separately on each job and in the admin portal.
All of them were worth doing. None of them were scheduling. So each one was estimated and scoped on its own, and fitted around the main release instead of holding it up. That's a simple rule with a big payoff: the feature that changes how the business works ships on time, and the extras follow.
The same lessons, at a bigger scale
We've since built full scheduling software for a national call center. The client is under NDA, so the screens stay private, but the lessons carry over:
- Start from how the people on both ends actually plan their day.
- Write the rules down before you design a single screen.
- Decide what happens at every edge: no-shows, changes, expiry, old versions.
- Test what each side sees, not just whether the data saves.
Scheduling looks like a calendar. It's really a set of agreements between people who plan differently. Build for that and more bookings stick. If your business runs on bookings that keep falling through, tell us how it works today.
