Zocalo now works with commercetools! Read more about the integration that expands commercetools' capabilities and accelerates deployment on a leading commerce platform. Learn More
Insights / ARCHITECTURE
Appointment Service Design for eCommerce Applications, Part 2 – Technical Considerations
TwitterInstagramLinkedInFacebook
INSIGHT

Appointment Service Design for eCommerce Applications, Part 2 - Technical Considerations

Stephen Osentoski
by Stephen Osentoski

Designing an appointment service for your eCommerce application requires a comprehensive understanding of your business, close cross-team collaboration, and thorough technical architecture. In my last post about appointments, I introduced a couple considerations that would help frame your thinking for the technical design for such a service, including the importance of the race condition, as well as identifying whether your appointment is with a purchase, or is the purchase itself. With this deliberation in mind, this post will go through the key decisions necessary to develop a proper technical design for your appointment service.

Select the Appropriate Appointment Software for You.

Rarely would you want to create the entire appointment application yourself. Given the number of well-supported appointment software available, as well as the general similarity between use cases, there should be no need for you to spend the time and resources required to build an entire appointment application from scratch. With that in mind, here are the key questions to ask when evaluating which software will best serve your business’ needs:

  • Which of my applications need appointment data? Regardless of use case, it’s likely that your appointment involves a brick-and-mortar destination in some capacity. This means that multiple applications are likely to rely on this data for customer interactions, which requires flexibility from your appointment software. As such, it’s important to identify which applications will need integration, and how compatible they will be with your new appointment service.

  • What integration capabilities does each option provide? Are the APIs for the appointment software well-documented and thorough for your needs? It’s a good idea to tap into your technical team to take a look at the capabilities of the software for each operation your business needs.

  • Does the appointment software offer a balance of flexibility and features? Ensuring the software is flexible to suit both developers and business-owners appropriately is important in ensuring it’s the right choice for you.

Focus on the Appointment Operations

Now that you’ve chosen your appointment software, the first step should be determining the operations required to develop the desired customer experience. Once you have a comprehensive understanding of the software’s APIs, bring your technical and UX teams together to figure out the best way to align technical capabilities with the planned appointment flow.

Consider who is interacting with the appointment software and the applications that will be interacting with it. Will the application used by the store managers and the brick-and-mortar stores be needing the same operations that are exposed to customers on the website? How do they differ? Identifying how each system will use the appointment software will help build a roadmap for your internal teams’ development with more accurate estimates, as well as avoid duplication of work.

For example, say you want to display the available appointment times for an entire week; what are the necessary parameters I need to pass as a part of my request for this appointment data? Ideally, there’s an option to pass a date range as two parameters in my GET request to retrieve a list of available times in that range. However, what if the API only supports a GET request with a single day parameter? Either a revision is needed to the customer experience to better match the capabilities of the API, or you need to get creative in your call to the appointment software, such as creating multiple threads to make 7 synchronous GET requests for the multiple days for which you are requesting data.

Addressing the Race Condition

As discussed in my earlier article, the way to address the potential of two customers reserving the same appointment will be heavily influenced by your use case and business requirements.

If your business case has serious repercussions for overbooking, you’ll want to be sure to design a technical solution that prevents this scenario from ever occurring. Here are a couple of ways you can handle this:

  • Add frequent checks to the appointment application throughout checkout process. Ideally, you should design your appointment flow so that the appointment selection is as close to final order submission as possible, as this will reduce the chances of a customer encountering a race condition, and minimize their frustration at having to start over after completing a series of steps. If this isn’t possible, consider adding checks to confirm slot availability throughout the process, such as during the Customer Details, Payment Details, or Cart Summary pages.

    • Positives: Catches more race conditions than just checking at time of slot selection and order confirmation.

    • Negatives: Performance hit for added checks; still not most elegant solution.

  • Reserve the appointment slot at time of selection. When a customer reaches the point in the checkout process to select their desired appointment slot, make a call to the appointment application to both check that the appointment slot is still available, and if so, reserve it right away and register a session-aware attribute for this reservation. This ensures that at the time the customer selects an appointment, they have reserved it until they either complete their checkout or abandon their session. If the latter does happen, issue a cancellation for that appointment slot to the appointment application to ensure that time-slot becomes available for all other customers. Another consideration with this approach is the amount of time before their reserved slot is “released”. How long do you let a customer have this appointment slot in their cart before releasing it to other customers? What is the experience like to let your customers know of this timer? What page do you redirect them to when it has run out?

    • Positives: Best eliminator of all race conditions.

    • Negatives: More technical implementation; usually requires a timer / re-direct; impact on customer experience.

So What?

While there is no one correct way to design your appointment service for your eCommerce application, there are ways to best set yourself and your customers up for the most optimal appointment-placing experience. Close collaboration between business, technical, and user experience teams, designing with the appointment application limitations in mind, and developing with your business’s appointment operations and race conditions in mind will ensure you’re on the best path possible to avoid headaches in the future.

RELATED INSIGHTS
INSIGHT
Appointment Service Design for eCommerce Applications
There are appointments in many different eCommerce scenarios. Whether it’s in the form of a movie ticket, an airplane ticket, or an oil change, each appointment scenario requires specific business rules and technical decisions to properly design its system. In this first half of a two-part series, the author introduces the considerations and challenges developing a service like this poses.
Stephen Osentoski
READ MORE  
INSIGHT
Is MACH/headless eCommerce right for you?
To celebrate the launch of Avatria’s new composable commerce accelerator, Zocalo, we wanted to share a few blog posts about some of the thinking that guided our development of the tool.
Anando Naqui
READ MORE  
INSIGHT
Why you shouldn’t build business logic into your frontend
When we started building Zocalo, our MACH-based eCommerce enablement tool, we brought our decades of experience as digital commerce consultants to the design process. We looked at where eCommerce platforms were 5, 10, and 15 years ago, thought back to all of the poorly built system architectures we’d been brought in to shore up...
Zach McMahon & Anando Naqui
READ MORE  
Have questions or want to chat?