Nearly every delivery app has a time window field. Very few of them let it change anything.
You can usually type "before 10am" against a stop. Whether that has any effect on where the stop lands in your route is a completely separate question, and the answer is often no.
The difference between a note and a constraint
A note is stored against the stop and shown to the driver. It is a reminder. The route is built without reference to it, and honouring it depends on the sequence happening to work out, or the driver reordering things themselves.
A constraint goes into the calculation. The route that comes back is the best route that also satisfies it, and if no such route exists, you get told.
Both look identical in the interface. One field, same placeholder text. The behaviour is entirely different.
Why the distinction usually exists
It is generally not a design decision. It is inherited.
If an app is built on a mapping API's waypoint optimiser, that engine accepts a list of coordinates and returns a better order. There is nowhere in the request to put a time window. So the app stores it, displays it, and cannot use it, because the thing computing the order has no field for it.
Adding real window support means changing the engine, not the form.
How to test yours in two minutes
Take a route you already have. Find a stop that is geographically inconvenient, somewhere at the far end of the run. Put a hard early window on it, something like before 9am.
Optimise.
If the stop moves toward the front, your windows are constraints. If the order is identical, they are notes.
Worth doing before you rely on it for anything that matters.
What good behaviour looks like
Every stop comes back with a predicted arrival. Not a range for the route, a time per stop. That is what you can repeat to a customer.
Service time is included. How long you spend at each door changes every arrival after it. A route planned on driving alone drifts later all afternoon, and the drift is invisible until the last few stops are late.
Impossible windows are named. This is the part most tools get wrong. Some days the constraints genuinely do not fit. The right response is to say which stop cannot be met and why, before the van leaves. The wrong response is to return a route anyway and let the driver discover it.
That last behaviour is worth insisting on. A tool that silently drops a constraint is worse than one that never supported it, because you stopped checking.
Windows and multiple drivers
Once you have more than one vehicle, windows and assignment stop being separate problems.
Splitting the day by postcode and then hoping the windows work out is a guess. Two drops with tight morning windows can land on the same driver's list at opposite ends of the run, and no amount of clever sequencing fixes an assignment that was wrong to begin with.
Doing it properly means deciding assignment and order together, with the windows and each driver's shift hours in the same calculation.
How RouteMate treats them
Windows and time on site are part of the solve. Every stop returns a predicted arrival, and when a window cannot be met, the stop and the reason are reported rather than the list being quietly reshuffled.
With several drivers, the day is divided by shift hours and starting depot rather than by suburb, and the windows are part of that division rather than checked afterwards.
The sequencing itself is fast enough not to be a factor: 40 stops ordered in 138 milliseconds, measured against production.
What windows cannot do
They cannot create time. If you have more time-critical drops than the day holds, a solver will tell you which cannot be met. It will not make them fit.
That is still worth a great deal, because knowing at 8am that two drops will not make their windows is a phone call. Finding out at 3pm is an apology.