Unifying third-party online ordering

The existing experience had two different types of users to understand: users who had the platform’s first-party online ordering service and users who did not have this service. Users who did not have the service still had to juggle multiple devices. They had their POS devices for in-person and phone orders and then managed third party online orders on a separate device. Users who had the platform’s first party online ordering service had an additional step. They had the same flow listed for the first type of user, but then they also had first-party online orders that were coming directly into the POS device. These first-party online orders also appeared in an online ordering section of the platform’s website which could be accessed from a personal device.

I surveyed a mix of six servers, bartenders, and hosts to understand current workflows and identify pain points. Users handled this workflow in a few different ways. Some restaurants had a designated employee responsible for online orders, such as a host or expo worker. Some restaurants had all employees responsible for online orders regardless of possible, including managers, hosts, servers, and bartenders. One participant said the online orders were handled exclusively by bartenders. A universal pain point identified was the inconvenience of handling third-party online ordering on a separate device, with some participants calling out frustrations around having to mark items as not available on multiple devices and having to charge marketplace-specific tablets.

One major challenge was determining how to create an experience that would integrate seamlessly with users who had the platform’s first-party online ordering service, wouldn’t disrupt first-party online ordering users that didn’t want to add the integration, and support users who only wanted the integration without also using the first-party online ordering service. I approached this by placing the integration inside the online ordering section of the platform, but customized the view for the three user types: only using first-party online ordering, only using the integration, and using both services. I decided on two entry points. Users could connect and manage the integration from the online ordering section of the integrations page to attract users who were already using online ordering integrations. The second entry point was within the actual online ordering section to highlight a valuable addition available for first-party online ordering customers.

From either entry point, users with the integration already included in their plan could walk through a self-service setup, and users needing a plan upgrade could quickly submit a request for an associate to contact them to assist setup. If first-party online ordering was enabled, users would see their same online ordering options, with the addition of third party orders appearing alongside their first-party orders. Users without first-party online ordering would have a limited view of the online ordering section available to them after the integration setup. After setup, users could access Stream orders and settings by going directly to the online ordering section of the platform or by going to the Integrations page and clicking the “Manage” CTA. This was to help users easily navigate to the integration who were used to managing everything from the “Integrations” page.

There were multiple internal and external technical constraints throughout this process which required close engineering collaboration. The internal development team working on the point-of-sale (POS) device had limited resources, which heavily narrowed the design options. The external integration company had their own technical constraints which limited the type of information I could present to users and the amount of control users had over orders. I worked closely with my engineering partner and the external engineering team at each design iteration to allow for quick pivots as new constraints were uncovered. This tight communication loop kept the project timeline on track.

I had several items planned for the future roadmap including a fully self-service setup and an improved experience on the POS device. Currently, users can only complete a self-service setup if the integration is included in their plan. If it’s not included in their plan they have to request a representative to call them to initiate the plan upgrade. Eliminating this extra step in the onboarding process could greatly improve feature adoption. On the POS device, most of the order information had to be sent to the internal notes section due to limited development resources available on that team. In the future I would like to break this information out into designated sections to establish a stronger hierarchy and avoid critical information from being buried if multiple internal notes are added.