The problem
Booking looked like a simple two-step problem until routing context and time entered the flow. Availability could become stale between selection and confirmation, while the correct meeting type depended on an earlier routing result.
Implemented middleware · Dubai, UAE service-booking workflow
Building booking middleware that respects routing and slot freshness
I implemented a Dubai scheduling workflow that resolved the correct meeting route, returned availability and created bookings through one visible, low-code flow.
The working context
What I was solving and what I owned.
My contribution
I designed the availability and booking branches, normalized the incoming fields, resolved the appropriate meeting route and handled the validation needed before a booking request could be trusted.
I have kept the organisation, product and people private. I also left out exact figures and internal details that could identify the work. The status above tells you how far the implementation actually went.
How I worked through it
The choices behind the implementation.
If you are working on a similar system, these are the decisions I would examine before choosing tools or adding more automation.
- 01
Resolve routing before showing time
I treated the meeting type as a result of the customer route, not a value the booking layer could guess. Availability only made sense after that context was known.
- 02
Validate the selected slot again
A slot that was available when displayed may be invalid when submitted. I added freshness checks before creating the booking instead of trusting the earlier response.
- 03
Keep both branches understandable
The workflow separated availability from booking while keeping the routing steps visible. That mattered because the system had to be maintainable by people who were not writing application code.
Expert insights from the work
What I learned and what I'd ask you to consider.
These are the lessons I took from the work. I would use them as questions for your own implementation, not as a universal recipe.
Availability is temporary data
Treat every displayed time as a short-lived option. Check it again before confirmation and give the customer a clear recovery path when it has gone.
Booking inherits upstream mistakes
If your routing answer is wrong, the scheduling layer can make a technically valid booking with the wrong team. Test the full route, not only the calendar request.
The dependency I would remove
Do not rely on an unrelated earlier submission to resolve the route.
The implemented version depended on a prior successful routing result. I would replace that with explicit context attached to the current request. It would make the workflow easier to test and less sensitive to stale state.
Connected disciplines
- Scheduling
- Workflow automation
- Routing
- Validation
- Customer journey
Continue through the work
Related experience and perspective.
If this overlaps with a system you are thinking through, start a relevant conversation.