So we have a delivery due today - between 9.32 and 12.32.
Every time I get one of these notifications, I mutter about spurious precision, but I suspect there's probably something else going on here.
If it was me, I'd calculate the earliest a delivery was possible, then tack on a fairly arbitrary margin of tolerance based on past experience.
Anyone know if this is even vaguely near the mark?
@bykimbo This is more or less what I assumed. But at this point, I'm more or less a delivery time connoisseur. Noting that some will have 4-hour windows early in the day, while others narrow it down to an hour even at the end of the round.
@Spinybadger Aha, clearly made quite the study :D I've never noticed the gap narrowing. I don't think I'm at your level of expertise!
@Spinybadger it's just lazy programming. When the outbound time is called back from the API, they just "let arrivalMax = new Date(departureTime.getTime() + (3*60*60*1000))" or something basic like that..
If it was me I'd call the Google Navigation API and fetch the average traffic time for the drivers entire route at that particular time, with all stops and just add an accumulative minute per stop. Store the route in the db with the user data linked to the stop. Loop through the stops and inform the user "around x time". I'd track the vehicle using websockets and ping it's location to the server. (Mongodb has built-in geo fencing), I'd set that to maybe like 500 meters in each stop. If the truck enters the fence, send an arriving soon push notification. As the truck goes through stops, I'd recheck the estimate, if it exceeds by a tolerance of 10 minutes, I'd broadcast new arrival estimates to the users.
In most areas this is more accurate than you think and customers prefer it cause it statistically wastes less of their time. Also has a general UI UX practice, less is better, making the user think about a single general time is much better making them think about a span.
Happy weekend!
@skanman There may be policy reasons why they'd rather not run any risk of having to tell people their delivery is going to be later than stated (as well as the importance of having someone in to receive it, which may become an issue without a clearly stated window).
But my inner geek really loves this idea.
@Spinybadger I've used it in 2 different apps, they managed b2b in house couriers. So usually packages went to offices where the delivery windows were constricted to office hours unless security has a 24 hour presence.
However, and you'll love this, to modify it for b2c, all you have to do is expand the arrival tolerance by distance in between the stops by order and that solves that problem.
@Spinybadger I'd think the two hours *is* the margin of tolerance and the number is just calculated using last completion time plus expected travel and they haven't bothered with any rounding.