Introducing
dynamic pricing
to Zenjob customers
I helped Zenjob customers test a premium payment option for reliable service from skilled workers.
How does the business work?
The problem
In 2023, Zenjob aims to become a profitable platform for temporary jobs. One way to do so is to allow customers to increase price at any point in time of the job posting. Currently customers pay one price for a job and cannot change it in order to make their posting more attractive. This is a economic opportunity the leadership of Zenjob wanted to explore.
“My hypothesis is that a surge pricing concept will boost our revenues.” - CPO, Zenjob
“A controlled experimentation can help us validate the idea that our customers want to pay more”
- Engineering lead, Zenjob
“Customers should be able to boost a job when they need a talent faster” - Head of Product, Zenjob
“Our customers need more economic flexibility to help us boost our revenues” - User research
Customers can change prices, check order status, and expedite acceptance by increasing their offer on the B2B web app.
Solution in short
Impact
10%
Engagement with the feature
The whole initiative proved to be a successful proof of concept upon which Zenjob decided to build a full blown system for dynamic pricing. My contributions laid the base for future designs and user flows. It also established a healthy practice to do more fake door tests every time there was a lack of understanding of the needs of the user base. So my contributions introduced a new way of validating ideas and also kickstarted an exciting feature.
Discovery & research
1. Gauging user interest via in-app Survey
To start the project, I needed to see if users would pay more to make their jobs better. I created a survey with a tool called Satismeter, which asked customers on the booking app for their thoughts on a potential feature to surge prices.
We tested the prompt on troubled customers with order issues.
The low response rate didn't clarify. Resulting in lack of evidence on the initial hypothesis that users will pay more for shifts.
3. Benchmarking marketplace pricing flows
While searching for an answer, I researched other businesses' revenue tactics. Sharing this knowledge with the team (CPO, Design lead, Pricing team) helped us find the ideal model for Zenjob.
4. Mapping the user flow based on above research
The benchmarking helped in building an initial user flow that could be used as a base to develop the final design better.
The map also brought a visual clarity to the Developers, leadership & research stakeholders.
Due to lack of user guidance, my team and I decided to develop a preliminary version of our idea. This idea will be tested as a part of a trial run that we called "fake door test" with customers who often seek more fulfilled orders.
2. Insight from the survey
Implementation via ‘Fake door test’
1. Analysing the mental model of the users
Modals were the interaction pattern of choice of the users to complete any action on the platform.
The next challenge was to find the step where we would offer surge pricing to the users.
I created low fidelity wireframes & shared analysis of each option with the Product manager and the developers to bring alignment.
My suggestion to do a fake door test lets us show the design idea to users without backend development, saving time on building a costly surge pricing system with no user validation.
2. Finding the right point to ask customers for a price increase.
Based on the above exploration the right moment for the feature was on the fulfilment page.
This is the page where the customers track the progress of their orders in a calendar view format.
So I concluded this is the best touchpoint to highlight any pricing decision.
The final design was released as a Fake door test meaning the pricing wouldn’t affect real business to validate my solution and also get early understanding of how customers make pricing decisions.
When a user clicks on a shift cell on any date, they will see a popup with the shift details. I decided to add the pricing feature to live on this pop up shift detail view.
4. Prototype testing & release
I finalised the interaction based on benchmarking and quick usability test run internally based on UX metrics to arrive at the following design.
Now the user can simply choose an option and increase the price in two simple clicks.
Further one can always revert their decision by clicking on
“Edit price increase.”
3. Building the UI based on the above explorations
I explored various interaction patterns on how the feature could behave on the pop up for shift details.
Team setup
Product designer
Product manager
2 x Front end devs
Process
We used an experimental process to solve this problem. First, we gauged interest in dynamic pricing through app prompts. Then, we tested and developed the design using a fake door test.
Hypothesis
Customers can get their orders faster by paying a bit extra to our skilled workers.
Metrics
An increase in orders with higher prices per shift and order from the intended customers.
Key learnings
Gaining user insights by doing an economic front end release.
Building a feature by experimentation.
Pricing as a feature is a business solution & its constraints need to be considered when designing the solution.
Not every problem needs to be solved by asking the user what they feel about it.
What would I have done differently?
If I could iterate further I would focus on understanding who is in charge of pricing decision and at what point of the order does the customer make a decision on increasing the price.
I would have explored the idea of sharing predictions of peak seasons based on historical data to nudge the user into anticipating shortage in staff so that they increase prices more mindfully.
