Sammy Lazinski

Re-thinking Deal States

To Make Transactional Billing Work for Us

We created a sales process that was taking too long and costing us deals. We needed a quick way to finish a “price-difference deal” that benefit retail employees, customers, and the business as a whole while maintaining the integrity of the our app & sales process.

Client:   VLORM

Role:   UX Designer (In-house)

Project Timeline:   April 2019 – June 2020

My Role:   UX/Product designer + Project Manager

I spearheaded tackling this problem and took beginning-to-end ownership of this project, and worked in a self-directed manner. I collaborated with our developer & discussed problems with my co-workers before presenting solutions to the team, and boss/CEO for consensus & approval.

Background

We were growing as a company and had just sold a local car dealership on our B2B application & services. Our CEO decided to shift VLORM’s business model from a monthly subscription to a transactional (collecting a fee per deal completed) model. The goal was to create less of a barrier for smaller retailers with less volume of sales to purchase and use our product.

It quickly became evident that our app would not support this billing model in its current design – it was simply too easy for another retailer to abuse the system and work around getting charged while still reaping the benefits of using our app. We needed to come up with a solution that would allow us to bill a retailer on each transaction while limiting the potential for abuse.

Goals

  • Implement a solution that allows us to bill for each ‘real’ deal (transactional billing model)
  • Implement a solution that maintains more profit margin than store credit (maintain the integrity of the app)
  • Create a more simple solution than already exists / simplify the process for employees and admins
  • Make it fair and transparent for retailers

01/ Discover

Understand and identify the problem space, then make sure I am aligned with my team.

Once our boss made clear that a new transactional billing model would be implemented in the near future, issues began to rise to the surface. Our developer raised the question: “What are we billing based on? What state of the deal?” A lot of issues were popping up in my mind already and I was concerned…

Deal States - May 2020

Open: deal was started/initial input made

Awaiting Validation: deal ‘completed’ after “Deal Summary” button tapped

Validated: deal completed, then a transaction ID was added to the summary page

“Validated”, was my boss’s initial response – but even he knew it would be a flawed solution.

What we all knew:

– A validated deal required an employee to enter a transaction ID (to tie it to a sale in the retailer’s POS system)

– Employees in our own store (Sport Systems) were often forgetting to validate deals, even when they were getting commission based on doing so.

Questions & concerns that came up:

– Why would another retailer validate a deal, especially when that is the way they are getting charged?

– How would we get another retailer to validate deals if we couldn’t validate ourselves (especially if they choose not to commission employees the same way we do, based on validation)

Pain Points

Watch a 2-minute Video of the Problem:

Our current process was not scalable – and we needed it to be scalable.

We needed a way to bill a retailer based on completing a deal, without punishing them for practicing using the app. Deal validation really wasn’t working in our store (Sport Systems) so far, so I saw an opportunity to re-think deal validation when coming up with an overall solution for transactional billing, as both issues seemed inextricably linked. 

I got the nod from my boss to do a deep dive in solving this problem, and so I began.

#Empathise

Since I had been working on the same product over the course of several years, I was able to spend time really empathising with different users. I had been involved with the high-level development of our company, so I had that empathy for our business needs as well. I spent a lot of time in the shoes of employees, management, and our customers while I was training and onboarding.

To help me further solving this specific problem, I defined the problems around deal validation from the perspective of each key user.

~ Business (VLORM) ~

  • We want to be able to easily track how a customer (especially a new customer) is doing with the app (how many deals, practice & real deals)
    • to gather data to inform our onboarding process
    • To be able to encourage momentum
    • To know when we need to intervene/send help or check in with them
  • We want billing to VLORM from the retailer to be automated & accurate so that we don’t have to spend time & resources sorting through their deals
  •  

~ Customer (Retail store manager) ~

  • There is so much going on during the sales & checkout process that we don’t want to have to remember another step – we don’t want the stress of having even more things to remember to do (we’ll likely forget/put it off).
  • We’ve done business the same way for so long – it’s going to take time for change
  • A new process has got to be simple. I want my staff to have confidence in this new process & trust themselves to use the app correctly – not constantly second-guessing themselves. We don’t want them losing confidence in their sales process or to deter them from engaging customers with the app & process.

Customer (Retail Manager/Owner) Thoughts:

  • “My staff is too busy to remember to validate deals & I don’t have the time or resources to chase them down & enforce validation or to do it myself. It’s too much of a hassle.”
  • “We want a way to practice deals & get used to the app w/out being charged for practicing.”
  • “As a manager, I want to be able to see if my staff is practicing with the app & how much they are individually engaging with it”

 

Business (VLORM) Thoughts:

  • “We can’t keep up with trying to police our retailers and get them to get their employees to enter transaction i.d.s – we don’t have the time or resources to do so.”
  • “We’re not getting paid for real deals that have been done, and we should be receiving payment for our retailers whom are reaping benefits using our product – we need money!”

My Design Process Overview

I follow all of the steps of the design-thinking process in a non-linear way. I use the Double-Diamond process as a framework for my process.

02/ Define

#Define

I created a table of Problem Summaries & Requirements. I was able to define the 3 main related problem areas to the main challenge that I was trying to solve, then in the column next to it I wrote out the requirements. After defining the requirements, I asked “How Might We” questions to steer me in the right direction for ideation.

#Insights

  • Validation is currently not the default end to the process, it is an extra step; more friction
  • Deal ‘completion’ should be the default to the end of a deal, and this is what we should charge based on
  • We need to provide a way to let employees practice deals without penalty/not charging the retailer

~ I needed to re-think the our current deal states in the app 

03/ Develop

Research & ideation

#Research

Much of my research to define the problem came from direct observation and hearing concerns directly from different users. By wearing many hats and continuously working on, and training others on one main product, I knew the concerns of our users & company intimately.

The main thing I needed to seek out from other sources was when I was trying to solve the following problem:

How might we create a default path for employees to ‘complete’ a deal (log as billable), reduce potential for abuse, while still allowing them to practice deals?

I went back to previous versions of our app, where we had different deal states. Some of the past models’ solutions would technically solve this, but would create other problems.

I asked myself, “How do other products prevent abuse?”

#Ideate (Diverge)

My process was really messy at first. I sketched out concepts in a notebook, coming up with a LOT of ideas to tackle specific issues i.e. validation, deal completion, then created cleaned-up low-fidelity wireframes and flows to be able to take to the team & discuss.

#(Re)define

Sometimes you have to re-think the way you’ve always done things. It was time to ask…

Is deal validation even necessary?

Validation purpose: to confirm that a completed deal ended in, and was attached to a transaction (and track if deal wound up with customer walkout instead) #insight: Really for retailers to track

Answer: not for VLORM/billing purposes

#insights #define : we need to define a “Completed Deal” state that is separate from “Validated”

#Ideate (Converge)

At this stage, I scheduled a team meeting to discuss my progress so far, get realigned with the team, and see what insights they had. 

We had a very productive discussions at this stage, and at the next higher-fidelity stage as well.

My co-workers were able to see solutions that I hadn’t seen at the time and helped me get unblocked. They also helped by asking important questions like “do we even need that step?” which helped to simplify the entire process.

04/ Deliver

Prototyping + testing

Claim or Discard: simplifying the decision to 2 options

#Prototype

I had already been working on a high-fidelity prototype of the app when we had rebranded from BDR to VLORM, so it was easier for me to just prototype this solution in high-fidelity

#Test

I always try to poke holes in the process myself, and also get my co-workers to do the same, so that we can refine things a bit before it gets tested by others. I started by running through the prototype with my team and asking them to spot weaknesses, then letting them go through the process on an ipad individually.

The true test would be how the process performed in the real world – at our store and at our customer’s dealership. That could only be tested after implementation of the solutions.

Watch a 2-minute Video on the implemented Solutions

05/ Measure (Results)

Measuring outcomes + reflection

 We tested the process in our store for several months, and we were all really pleased with the results. It became way easier for the staff in our test retail store to validate a deal. 

We went from roughly 30-40% of all deals being invalidated to about only 5-10% invalidated.

We were also able to bill one of our customers based off of this new transactional model for 2 months.

The System Worked!

#Reflect

My Process

Conveying ideas earlier on, in a more low-fidelity way through flows & prototypes really paid off. This project reinforced that I should not jump into high-fidelity work too soon & that working and sharing work in lower-fidelity saved time, energy, and allowed me to not get too attached to an idea.

Our Business

While I was proud that we solved this problem, possibly the biggest lesson I learned, was a business lesson:

Sometimes, a business may have to put generating revenue before investing more time and energy into changing the product to fit an ideal. Unfortunately, our company folded not long after and we didn’t get to see the full impact of these changes

Thanks for looking through my Case-Study!

I would be happy to walk you through, explain, and answer any questions you may have about my process.

Feel free to reach out via email: sammykzinski@gmail.com