DELIVERIES | TRUE-UP | DRIVERS | MORE
Odeko is a virtual purchasing agent that uses artificial intelligence to help cafes run more efficiently.
Odeko is a service that helps small/medium businesses like coffee shops reduce waste and save money by ordering intelligently. We use the cafe’s POS data to predict future sales, and combine weather/calendar events data to order just the right amount. The in-store web app is a mobile platform that gives the user areas to correct data around inventory in their daily work flow.
This B2B Saas company has a responsive web app platform for businesses, and an internal admin/ordering platform for our team’s operation. Odeko is a user centered product, meaning we solve problems for our users’ direct needs. The coffee shops that we easily user test/ research/ study are located all around us like Birch Coffee, Matcha cha, Joe’s Coffee, Partners Coffee, Think Coffee, and Gregory’s. As the second designer, I collaborated in squads of about 6 to produce MVP solutions for our user’s day to day processes.
This B2B Saas company has a responsive web app platform for businesses, and an internal admin/ordering platform for our team’s operation. Odeko is a user centered product, meaning we solve problems for our users’ direct needs. The coffee shops that we easily user test/ research/ study are located all around us like Birch Coffee, Matcha cha, Joe’s Coffee, Partners Coffee, Think Coffee, and Gregory’s. As the second designer, I collaborated in squads of about 6 to produce MVP solutions for our user’s day to day processes.
My Deliveries
Problem
|
Role
|
The problem is that a cafe manager can not accurately update invoices on items that they received. What they think they are getting, isn’t actually what they receive. As well as what we ordered for them and think they are getting, is not always what they get. We needed to create a system that keeps invoicing digital instead of manual.
The current process was to order for a cafe, send them an email the morning of, telling them what they are receiving for the day. Then in the morning the delivery is out front with a paper receipt of what was delivered. The cafe would then open up the delivery and contact the vendor for any refunds needed. So that's our company ordering, the vendor is delivering, cafe is receiving, then it becomes unclear where the error was.
We decided to take away this need for the cafe to get involved with the vendor, instead we took over contacting the vendor for discrepancies. But how could we receive this information from the cafe manager? He can’t reply to each daily email manifest with his corrections, that would be too tedious and error-prone. We decided to take this read-only email format, and make it dynamic.
The current process was to order for a cafe, send them an email the morning of, telling them what they are receiving for the day. Then in the morning the delivery is out front with a paper receipt of what was delivered. The cafe would then open up the delivery and contact the vendor for any refunds needed. So that's our company ordering, the vendor is delivering, cafe is receiving, then it becomes unclear where the error was.
We decided to take away this need for the cafe to get involved with the vendor, instead we took over contacting the vendor for discrepancies. But how could we receive this information from the cafe manager? He can’t reply to each daily email manifest with his corrections, that would be too tedious and error-prone. We decided to take this read-only email format, and make it dynamic.
Preliminary wireframe exercise of a rejected layout flow.
We added a new section to our pre-existing in-store app called My Deliveries. This is where the user can see what deliveries to expect and have a chance to correct discrepancies on the go. Above left image is an early rejected flow, where you enter edit mode for the list of numbers to turn into inputs.
We validated our hypothesis' by user researching and usability testing. I developed multiple prototype rounds to review/test with both current cafe stakeholders and random local cafe managers. Below is our MVP solution's planned work divided out by sprint velocity.
We validated our hypothesis' by user researching and usability testing. I developed multiple prototype rounds to review/test with both current cafe stakeholders and random local cafe managers. Below is our MVP solution's planned work divided out by sprint velocity.
Above is the MVP solution's planned work divided out by sprint velocity.
Final screens and an iPad view.
|
|
As a result, we implemented a calendar view of orders per vendor in a list of what is expected. You can click on any item to update the amount you received, select a reason for what happened, leave a further detailed note, and attach a photo. We integrate this data directly into our system, which corrects current inventory counts and adjusts orders in the background. We also have a digital trail of invoices now and can follow up with the vendor for problems with clear data points. At the start of the day, our platform easily stores more accurate data about the number of croissants a cafe actually has on hand!
Waste & True-Up
Problem
|
Role
|
Background: A discrepancy suddenly arose and we might start to lose cafes' trust. We need to huddle and make an emergency effort to save and keep customers happy. A four person Tiger Squad forms for a 2-day hack-a-thon to solve the high priority problem of capturing and decreasing the unknown discrepancies day to day. We brainstormed, discussed, and chose three pain points to rapid prototype. We discovered these pains during past user research sessions: a running low on inventory button, way to waste out an item, and a sold out button. Cafes were happy to hear that we were working on solutions to improve their work flow. and actually launching product. With additional user feedback and testing, we made a plan for Odeko 1.0. Three OKRs were targeted: to increase accuracy of orders, increase cafe usage of app, and increase data accuracy.
The 2-day hack-a-thon prototype screens above were used for user research, answering these scenario questions:
1. The last Chocolate Croissant just sold, report this sell out. 2. While in the app, you remembered you spilled 1 San Pelligrino item, report this as waste. 3. Check that your next delivery will include a San Pelligrino and a Chocolate Croissant. 4. Correct your current delivery of Matcha Banana Bread to 2 received. |
Whiteboard sessions with the squad, and diagram drawn in my notes.
|
We were able to identify that errors in data were taking place around tasks they performed throughout the day. The features we produced above were working, but were clunky, incomplete, separate prototypes, and needed to further ensure all data points were addressed. We decided to introduce data entry into three parts of their day to ensure accuracy:
The three verbs above, reflect the three actions the user can take from our nav bar.
- The Morning shift accepts deliveries. (in development, soon to launch)
- The Afternoon shift counts inventory. (already exists in app) This downtime can be used to correct inventory levels that don’t go on the POS system, for us to make better orders.
- End of day shift confirms Waste & True-Up. Step by step flow to confirm waste and inventory after a day of transactions, delivery of the wrong items, accidents of dropping pan of muffins on floor, and waste outs, internal consumption.
The three verbs above, reflect the three actions the user can take from our nav bar.
Two early concepts presented to squad. We selected option 2 to move forward with.
|
Wireframe options of tool tab usage.
|
Cafe manager conducting user research by testing an early prototype version.
|
Prototype screen by screen set up with hotspot links.
|
We iterated on this new idea, made multiple prototypes, tested with numerous users, presented to retail managers and ceos of the cafes, and soon came to a validated prototype to start developing the flow in the image below. Also prepared handoff to cafes about Odeko 1.0: we made training decks, user manuals, handbooks, demos, collateral, and email announcements.
Prototype screens of the winner version used for deployment.
MVP screens split up into sprint work.
Weekly raw data we emailed the cafe district manager.
Odeko 1.0 released and we saw changes in data instantly. More and more cafes were completing the flow, increasing data accuracy as a whole, and loving our company again. We even got ceo's across to change current waste processes to our new system and replace the POS. Above is raw data sent to the cafe district manager to review.
We changed the way our customers operated day to day, increasing our market value, and our need for each other.
We changed the way our customers operated day to day, increasing our market value, and our need for each other.
Direct Ordering
Reach out to me for access to this private page of unreleased work
Driver's App
Preliminary work contributed to a newer business concept. I accompanied our drivers on a late night delivery run conducting user research on how to integrate an app into their very manual process. Created service designs below.
|
|
|
Early service designs drawn to discuss with squad for app concepts.
Fist sprint's V1 iOS redesign from an existing proven prototype.
|
Future app ideas/sketches.
|
More
|
|
|
|
|
