The goal
To design and build a service to allow online ordering of calorie-controlled meals and tiered delivery – in multiple locations and countries, that would replace an existing spreadsheet-based solution with an administration system for order management and reporting.
My Role
I was responsible for creating requirements outlines for a website from initial interviews with service managers – also the visual look and feel of the websites based on existing menu PDF documents, and then coding the websites for each location (5 in total) in WordPress/Woocommerce. Also, modifying the websites to encompass each location’s specific quirks.
Discovery
Interviews
As the service was already in operation the quickest method of finding out requirements as a business was to interview the service managers in the UK and Hong Kong as to how the meals were prepared and any existing logistic considerations. What parts of the administration were the most problematic and time-consuming.
Market research
Armed with the infrastructure requirements I looked at our nearest competitors to see how they were solving some of the issues that had been raised by the team. Anything we thought had merit was added to the list for further investigation, but there were no outright winners already in the market.
Challenges
clientele
After looking through the existing client base and their buying habits, two clear client personas surfaced.
Insight
Client 1: The Chemist – bulk payment up front because they don’t want to think about food until its in front of them.
Client 2: The Gourmet – wants to be able to change what they eat to keep it exciting. I want to be satisfied as I eat my food so I won’t be tempted to stray.
menu rotation
Each location changed the menu weekly between two or more in rotation.
Insight
This makes the prospect of combining a customisable weekly order and a subscription model very challenging indeed.
Administration
The key to providing a great service is making sure no mistakes are made and all information is accessible efficiently.
Insight
Ensuring that all 3 parties (client/manager/courier) have the accurate information through a single source is critical to efficient operations.
Commerce
Originally, the service was taking payments through the Mindbody SaaS platform, as that what was already used in the gymnasiums where the service was run from. However the security and time aspects of this method were undesirable.
Insight
Shifting the point where payment would be taken into the remit of the client removed the need for the managers to handle any card details, allowed payment in all cases removing any potential failed transactions.
Delivery
The service required two tiered pricing structure and a restricted delivery area, and two of the locations don’t have postcodes to use which most address systems require.
Insight
By turning the address input upside-down for Hong Kong and Dubai and getting clients to narrow down by area and then sub-area and finally house address we could be sure they were delivery qualified.
Design
On paper, the idea of providing a food preparation and delivery service doesn’t sound too complicated.
However, the reality is that you have to cater (no pun intended) for all kinds of diversity, be it cultural diet restrictions, allergies – things became very complicated very quickly.
Throughout the development of the websites, various issues would make themselves known. whether it was a required process mechanism or a locale issue like;
- Hong Kong’s area-specific delivery time slots because of the local topography made the delivery route very linear and lack of postcodes for zoning meant inputting addresses had to be done by [ region > district > area > building > number ].
- being able to add multiple dishes per day and add specific days to a single order was quite an interesting problem to resolve as most shopping carts simply don’t work that way.
- Having the option on some websites to be able to order a custom weekly menu or a multi-week subscription.
- All locations have a weekly rotation of menu – but having one location’s week starting on a Sunday rather than Monday.
Add onto this a weekly rotating menu (up to 4 different menus) and the list of potential problems becomes a bit bigger than anyone could imagine initially.
These are just the issues associated with building the website – actually running the service provides its own special challenges.
User Journeys
Using our two client types and an outline of the service structure I planned out the required steps to get a client from a landing page through to the checkout and decide on what sort of emails were required once an order had been placed.
Having addressed as many of the pain points that we could observe I set about producing the first iteration of the website.
Prototyping
Three main iterations of the site were built to test the user-flow from arrival through to payment. The first a subscription-only site as that was already the model being used in Hong Kong, followed by a weekly customisable model and finally one that embodied both systems albeit running in parallel.
Each model would be built on a staging website and gym managers and selected clients would be asked to run the gauntlet and report what they had experienced and suggest ideas to refine the service.
Ideas would be brought in by other team members while they were able to experience the website, and these would be considered based on feasibility and utility for the next iteration.
Sample problems we resolved.
Problem: Once I have added meals to my order I can’t tell which days I have missed, is there an easy way to tell?
Solution: By adding the name of the day to the title of each meal, it was clear to see in the cart, in the checkout and confirmation order emails which days had food ordered for. This also helped the service managers when scanning a customers order .
Problem: I’m eating exactly 1300 calories per day how do I know if I have ordered too much or too little?
Solution: Subscription based orders we included an accurate counter that would tally up the calories you would be consuming based on what you had selected before adding to the order.
for custom weekly orders all dishes have ingredients and nutritional details available.
Problem: How to display an active weeks menu for clients to select from?
Solution: By combining the output of categories products and a plugin that using shortcode tags to display content based on a predetermined calendar. We could display a specific weeks meals. It’s an incredibly niche system as a e-commerce platform.
Problem: How to display order details to service managers, Kitchens and couriers?
Solution: Use of a Restful API and a timed retrieval of latest orders to populate a Symphony based application. We created the dream admin panel for the service managers. baking in feature requests thick and fast as the managers gave us feedback.
Outcomes
The overall feedback from clients and service managers was an overwhelmingly positive one, with only the most previously pampered clients complaining that the lack of a customer concierge being a step backward. This was one of the key improvements from day one – to provide a great service for many clients, not an exceptional service for a few – ensuring the service was viable and well managed.
In 3 of the locations, we had the ability to advise them on how to launch EatUP operations based on the model we had already running successfully elsewhere, vastly reducing the setup time required.
The amount of time required to manage the service was also reduced (by around -1500%) and communications with both the kitchens preparing the food and courier services being real-time, streamlined and transparent, with each party having a reduced subset of the same order data to reference online made communication easier.
The platform is now flexible enough to launch in nearly any location with very little preparation time, ensuring that the service and brand maintain a consistent result.
