Zeta for Cafeteria Merchants
Zeta for Cafeteria merchants is a web app used by cafeteria merchants as
- A POS ( Point of Sale ) solution for enterprise cafeteria merchants to receive and accept payments
- Platform for managing cafeteria products like adding and removing food items, marking items out of stock and order management
- A platform to manage sales and settlement reports and assign roles to employees and regulate their access across the platform
- Food inventory management redesign
- Managing sales and settlements after successful transactions from customers
- Defining merchant access roles to restrict visibility to sections of the app
- In 2014 there were 3million IT employees in India and that has been rising exponentially since. Today there are thousands of startups and many other companies most of them work out of a building that where multiple companies work together called as an IT park or from co-working spaces.
- Zeta, a startup started by the popular Directi parent company saw an opportunity here. At Zeta, we built an app that provided employees a part of their salary as a tax free component that they can spend on food and beverages. At the beginning of every month each employee receives a part of their income as zeta meal vouchers and they can redeem these vouchers in their cafeterias and pay for their lunch.
- In 2017, I was hired as the designer for a product that allows waiters at the cafeteria counter to add and modify food items, see orders and receive payments and monitor their sales and settlements from one dashboard. Users would then be able to order from the order section on the zeta app.
By Feb 2018, close to 10Million monthly transactions has been managed from this product.
Food inventory management redesign
Managing food inventory was one of the key features of zetas merchant business. This tool is used by cafeterias in different companies to define their food inventory and its availability on their platform which can then be used to place orders by users from the zeta app. Zeta already had a basic tool in place to manage their own cafeteria orders. It was time to scale the product to multiple business.
- Can you teach me how to operate this tool?
- Do you face any problems when there are long queues
- Have you ever had to call the manager for any issues you faced?
- Have you let someone else operate this in your absence and do you remember any issues that they faced?
- Did you add all the food items inside it?
- How do you handle cases when any/all items become unavailable?
- How do users know when can they start ordering in the mornings?
- Do you sometimes find the tool freeze or unusable at times of ordering? Does that cause any problems
- Does any one else operate the same tool simultaneously?
Video Walkthrough of current tool
( Watch after 2:29 for a little laugh 😉 )
We made a list of all inputs shared from different stakeholders and customers which helped us understand the initial directions for the product. We also got some reports from the customer support team which helped us through the process. Some of the highlighted problems we wanted to tackle in this redesign were -
- Searching and finding menu items to modify from a list was a pain. There was no quick search and merchants are not very fluent with their spellings to type and search.
- Switching between different cafeterias was unintuitive
- Categories are hardly visible and its a pain to find a specific category and turn it off.
- The overall navigation like adding a category and adding items into it was very very hard.
- The store is always on but in reality they shut down at 5
- Usually by the start of the day we remove and add multiple items. This takes me close to an hour daily
- Sometimes orders get left unchanged. People end up paying for it and wait for food to get delivered
- Its sometimes unclear how much money needs to be settled after Zeta’s charges
- At any point I can see the money made but its hard for me to understand how much of it has been settled
- Companies are requesting for downloadable reports for transactions
Before getting into any design work, I personally visited a few restaurants to check their menu management solution offered by existing businesses like Swiggy and Zomato. These businesses have similar products but used by restaurants to receive and process food delivery requirements. Though the use cases are very different these products did serve as a source of inspiration.
The product we had initially built solely for Zeta cafeterias and had a multiple issues with it. This was the first time we were making it better and expanding to multiple cafeterias across different corporates across the country. We had to rely mostly on our product managers to give us a picture of how the cafeterias functioned. We also went for a couple of site visits to see how the system worked.
We made 3 user personas that would define our target audience.
We quickly made a list of possible triggers and its respective actions to be taken. The flow we designed had a critical dependency on navigating to a category. Hence our first step to design the category flow in the easiest way possible to accomplish all the triggers.
Apart from these initial triggers we also made a list of use cases and its solutions that users might need to accomplish.
|Open/Close an Express store for business wherein he can||- configure fixed timings for every day of the week|
|- toggle a simple on/off switch for that day to handle bandhs/emergencies|
|Restrict the visibility of his store to specific corporate users based on||- a unique QR code OR|
|- whitelisted corporate email ids|
|Category Level setup||- Toggle availability of all items in a category|
|Separate daily vs standard menu items|
|Enable start and automatic stop.. Notify when the category starts||Category Name, Add / Edit / Delete / Start & Stop orders, Time based auto-enable/disable(optional field) of the category, Discount|
.. and more
Category and Item Navigation
One of the biggest problems pointed out was navigating and finding a specific item. Our personas had poor english fluency so it was inefficient for us to take the route of giving them a search bar to type the item. They might often end up misspelling the word which won’t yield them any result. We explored a few variations around category and item navigation and decided to go with the one that suited the best for our use cases.
The one that made the cut was something similar to the second variation.
Category and item toggling was identified as the most frequent action performed by the merchants. Every time an item or a category of items were available or unavailable, the merchants had to mark it in the interface. For this reason we decided to use Switches which takes the least amount of effort for toggling - One for each item and one for a category of items. We iterated over visual states when switches were on each toggled state.
The item switches are intentionally not turned off automatically to retain its previous state. For example if Egg Noodles was never available and had its switched turned off earlier, we wanted the platform to retain its state when the category was turned on.
As a bonus delight experience we could even go far to notify our users when this new order which was previously turned off gets available. This trigger is easy to capture and can boost sales apart from adding some delight to the users.
Adding multiple items at once
It was not an uncommon use case from our research that merchants wanted to add multiple items on the same category. For example some merchants wanted to create a category called “Lunch” and add several items into it. All of these items would be turned on and available to start with and later when the stock goes unavailable they would turn it off.
We accommodated this in the interface by extending the input fields to a simple click. This helped broaden our audience addressin multiple use cases.
Sales and settlement reports
Reports were one of the most important features required for both in-house cafeteria merchants and outside clients. They needed to be able to generate sales reports for different time ranges, export it to their company team and a lot more. We started by compiling a list of use cases that was turned into flows.
Broadly the use cases needed to address the following concerns
- What is the total revenue generated by the merchant over a period of X days or weeks
- How much of it has already been settled and when would the remaining get settled
- What happens to offline transactions that have not received a payment yet
- How can I pull out past sales and settlements
- All applicable zeta fees and payment channel related information
The information architecture was fairly straight forward for this use case. Up on the top we needed a transaction period to define any kind of duration which changes all other branch results. All other fields are children of Transaction period which makes sense for any duration period. Exporting these values also becomes as simple as exporting the displayed data in PDF or Excel file.
Navigation from the main application
Defining Access Roles
Typically cafeterias had multiple people operating and after studying different different merchants we decided to model the platform into three roles -
- Business Owner
- Store Manager
- Counter Operator
These were actually our personas we and simply had to define different rules to define which parts of the application is visible to each role. We made a list of who gets to see what, however on the front end we needed to come up with an interface to define these roles. This view is accessible only to the admins and they can define the roles but the access controls are defined from the backend.
We made a quick prototype on Marvelapp with basic features to present to the stakeholders.
Making it responsive
Now that we had all the features plugged in we need to simultaneously make it responsive. I typically design with a web-first approach because our primary traffic was for the web. We still delivered the mobile versions in case any the store manager or admins wanted to check login and check the infromation separately.
We tested the product while building it with our audience to understand if it works as expected. Thankfully 1.5 years later the product works as expected and manages more than 10 Mil transactions monthly.