Building trust through pay transparency for restaurant managers & employees

TL;DR

Restaurants implement different systems of collecting and distributing tips to their staff, depending on their preference (tip pooling, tip sharing, etc). Having built a product that calculates the math based on defined rules (tip pooling), now 7shifts customers were looking for a way to transparently share earnings report with their staff and provide visibility to their tip earnings and calculations. This problem was very complex for a few reasons:

• Different restaurants wanted to provide different levels of transparency.
• Some restaurants enter their tips lump sum manually and some pull detailed tips on receipt level from their point of sale system (causing challenges in availability of data points).
• Since distribution rules for tip earnings, varies from business to business, the data points were not standardized to mean the same across different restaurants and employees.
• Tip pool data is always live as long as tip pool cadence is not over (daily, weekly, biweekly), so finding the right cadence of data to be shown was also a challenge.

Solution & key results:

we developed a mobile solution, for employees on the 7shifts mobile app to view a breakdown of their tips earnings per shift. We optimized the earnings report to ensure it’s meaningful and intuitive to different restaurant roles, and includes a moderate level of transparency so most restaurants can share it with their employees.
This feature helped unblock sales in generating revenue from restaurants with more locations and upon release, met user satisfaction and happiness metrics.

PLATFORMS
iOS, Android

TIMELINE
6 Weeks (Prioritization to release)

MY ROLE
Main Product Designer & Researcher

METHOD
Design Thinking ( Empathize, Define, Ideate, Prototype, Test, Implement)

Method

Problem Analysis - 5Ws!

Customer Research

We analyzed customer insights and conducted 6 interviews to understand how different restaurants currently solve this problem without a digital solution. Most servers/FOH staff, collect something called a cash-out slip at the end of the night and take it home, enter it in their notepad to keep track of their earnings. Managers/admins rely on tip pooling report from our system, but the report might not be the final step in calculating tips. Depending on the complexity of their tip distribution system, they might use the report's values in other spreadsheets or formulas to calculate employee earnings. Also a lot of times, our tip pooling report did not have all the values populated, due to their account setup and tip pool choice (manual or from POS).

Lots of questions in our heads!

Trying to break the problem down and ideate on the potential solutions, I started by listing all the components/data points that make the earnings report in our system. Questions were what should the cadence or breakdown look like? is it a daily report? per pay period report? or by shift? What do these different data points mean to the user and how are their used? The answers to these questions were not straightforward and easy, because depending on the restaurant's use case and tip pool structure, the data points could mean different things.

Understanding limitations in our data points

Relying on the knowledge of more senior peers and team members who directly worked on the tip pool product when building it, I analyzed different cases where our most important data point "Tips earned", could mean different things to restaurants. This was an ongoing project to standardize the definition of data points in our system, in a way that it does not cause problems in existing user's workflow.

Understanding the math in complex tip pool rules

We identified some of the most complex tip pooling scenarios to understand how granular our data points and calculations need to be if presented to employee user. This excercise was done to understand the limits of our data points and their relevance.

Digging for user data to dial the solution right

Collaborate with my data analyst to find what % of our customers, use tip pools in what way. The findings helped us better understand how the customers are using the product. With majority of our users, using manual tip pools, we realized manual pools ( selected for flexibility and accuracy) even though is the most accurate data points, but is not where our solution should end. Manual tip pools were mostly used in combination with other tip pools.

Competitor Analysis

Competitor deep dive helped us understand how other tools in the market, enable restaurants against this problem and helped us scope our offerings according to market.

Ideation

I ideated on the requirements based on data from our customers, user expectations and our system's best ability to show accurate and useful data. Some of the mentioned ideas below, were later invalidated by user testing, team feedback or just taken out of scope.

Bittersweet user testing

Test plan: I conducted 6 user testings, 2 with manual only tip pools, 2 with Sales based tip pools, 2 with tip percentage distribution model to ensure our solution can address all cases.In order for the tests to be realistic and the data to resonate with employees, I pulled each company's recent tip pool report, and designed the prototype with their specific case and data. This way, they would not ignore the values or think it's dummy data.

Invalidated ideas: In these tests, I uncovered that sales-based tip pools, have much more granular data points pulled from POS, and more complex calculations, that we can not elegantly solve for in our system with the details the user needs ( net sales amounts). This was because, depending on the Point of Sale system, 7shifts had limitations in the data they could pull, ingest or consume. So from these user tests, we knew that our solution needed to be complimented with their cash-out slip or spreadsheet. 
We also realized that, tip pool rules are either meaningless to the employee or are known. This led to removing this information from our scope.

Validated ideas: Manual tip pool users, tip percentage users saw value in the report. The feedback also validated the need for tips/(weighted)hour which we is not a readily available datapoint, but an insight for employee to understand their earnings per hour. ( Servers in US might get only $2 per hour in some states, so their wages are basically non-existent, and they only rely on tips)

Users wanted tips earned & we didn't have it!

One major concern from the start of this project was the accuracy of calculating a final tips earned number that would be visible to employees. As mentioned above this number could have been wrong depending on how processed the tip distribution model at the restaurant was. Or because managers/admins had not completed their tip export setting in the app. Here was our plan to mitigate risk as much as possible:

1. We proposed a solution to our web team, to encourage manager/admin users to set up their tip export settings., but this was delayed due to technical work that needed to be done, to make the tip data in our system usable.
2. Phased roll-out and close monitoring of bugs
3. Defaulting tips earned a simplified calculation that would be logically accurate unless the user changes their tip export. ( Tips collected - tip in + tip out = tips earned)
4. Enable the feature only with a setting controlled by admins
5. Collecting feedback early post-release and fast follow with iterations
6. Define a vision and align on it with stakeholders and other teams to build a shared language about value

Our data is view-only! how do we measure success?

In order to keep a pulse and measure success, I designed a feedback collection mechanism to closely monitor the accuracy of data and the user satisfaction/feedbacks on the report. We phased our roll-out to 100 users at first, to control and debug quickly if we get inaccurate reports. We did find a few bugs which we quickly resolved with the help of our backend team, and we released the flow to the remaining users after we gained confidence. 

Final screens