Staff is shown as available even though an appointment is already booked

[Guenter_R]

We're using the graph booking API to book appointments.

To find an available slot the assigned staff is got for a service and the availability is checked for all staff members. If at least one staff member is available the appointment is successfully booked. 

Afterwards the staff member is shown available for 2 - 5 minutes. So the next try to book an appointment within this 2 - 5 minutes finds the same staff member and the slot is booked twice for the same staff.  

When an appointment is cancelled the status change also needs some minutes. 

I'm not 100% sure but I think this worked some month ago (currently only a prototype solution). 

[#2]

Also experiencing this issue.

the delay is causing double bookings for us.

[#3]

Hi Zack,
Thanks for your feedback. Hope that MS provide a solution.

Guenter

[#4]

We have also been seeing this issue. We believe it has to do with the number of staff and services as well as the number of existing appointments.
This is essentially the ticket we submitted to MS support
https://techcommunity.microsoft.com/t5/microsoft-bookings/microsoft-bookings-ignoring-staff-time-off...
They responded saying to look at this page and that the reason the issue was happening was because we have too many staff/services and are booking too far into the future (90 day max lead, 1hr increments, services are 1-3hrs length, ~8am-6pm Mon-Fri operating hours).
https://techcommunity.microsoft.com/t5/microsoft-bookings-blog/scaling-bookings-for-large-demand/ba-...

[#5]

I'm fairly certain it's not this. We've been running our booking page with around 35-40 staff and around 15 services for years without any issues. I've also tested a brand new booking page with a small number of staff and services, and the issue remains. This leads me to believe it's due to something Microsoft has changed, as there are far too many people reporting similar and odd issues all of a sudden. This all started after the recent changes to the bookings homepage.

[#6]

This is the validation I've been looking for, I didn't think it had to do with the scale either!
I agree this is something that has been very recent.

[#7]

Hi Jamie,

This is also my opinion!

Thanks
Guenter

[#8]

@Guenter_R 

We are experiencing the same as well. Did wonder if this was something to do with the timing the specific Bookings calendar was created, as a previously create done didn't seem to have the same issue - maybe a bug which affects Bookings calendars created within a specific window which has now passed? Or maybe this only affects Bookings calendars taken from a copy of a previous one.

I have created a new Bookings calendar from scratch and this still has the lag. Thankfully, nobody can book the duplicate appointment, they receive an error. This happens for about 5 minutes until things catch up, so likely to create frustration for customers.

Hope this helps others who are trying to get away from the issue. Please keep posting if you find a fix, try another workaround, or if the issue goes away for you.

Thanks

[#9]

Hi Greg,

Maybe it is a good idea to create a new calendar and check its behavior. Fortunately we only have this in a lab scenario. But after all our solution will not go in production with this issue.

Thanks
Guenter

[#10]

Has anyone had much luck with getting this resolved? We are currently dealing with Microsoft support and making little progress, as far as I can tell.

[#11]

Hi Zack,

No progress in our project.

[#12]

Hi @ZackKhalifah. 

Sadly no progress here. I had created a new calendar from scratch to test (not duplicated to avoid duplicating the issue) and also used real staff (as opposed to 'noreply' type addresses for the staff), in case it was causing issues that the staff user account couldn't be found. Same issue in the new calendar I'm afraid.

What is interesting, is that older bookings calendars don't have the same issue, the availability is removed with no delay.

Good luck with your support case and please keep us updated if possible.

Greg