Limos.com
A System for Customer Disputes
Customer Care Solution
Since launch, Limos.com had grown from 4 employees to just over 55 and revenue rose to more than $6 million in just the first two years of business. The customer care was feeling the burn of this growth and the biggest pain points surrounded settling the payment of a ride. Similar to payment the way it works in most hotels, full payment for the Limo ride was not recouped until after the service was completed when all add-ons and upsells could be accounted for. As the middleman in the exchange, Limos.com would receive a detailed account of charges from the Operator post ride and subsequently charge the customer based on the submitted amount. Most times, this system worked quite well. But sometimes, our customer service agents would find themselves in the middle of a heated battle between the operator and the customer, each providing different accounts of the service that occured and the payment that should be rendered.
Disputes was a feature that provided admins with the functionality to address these customer and operator complaints regarding payment. The lack of functionality had been a burden on the Customer Care team for some time and there was a unique window of opportunity on the development front to tackle some of the features needed.
The main emphasis on the project was a speedy solution. The Customer Care agents needed something to help resolve disputes and they needed it fast. As Product Manager, it was my goal to devise a strategy that would solve the needs of the Customer Care agents, avoid the technical complexities and get the tool in the hands of the agents as quickly as possible. In order to do that, I had to first identify the problem, then determine the range of solutions and finally derive the strategy.
Project Summary
Through user research and technical scoping, I formed this product strategy to solve the major pain points surrounding payment disputes for the Customer Care Representatives as quickly as possible.
- Product Manager
My Role
- (1) Identify the main pain points surrounding payment dispute resolution
- (2) Examine existing functionality to determine what could be repurposed
- (3) Preemptively understand and avoid the technical complications that could arise and devise an approach that solves the most pressing needs quickly
Project Goals
- user flows
- wireframes
- prototypes
- project management
- timelines
- release planning
- scope estimations
- strategy definition
- development requirements
What I did
- business emphasis on time to market with a technically challenging feature set
Project Challenges
Identifying The Problem
The Limos.com system was complex and there were many areas that were ripe for optimization, especially as far as the customer care agents were concerned. We only had a defined window of development time alloted for the project though and so, the first step was really refining the scope of work to focus on the main problem in regards to payment disputes only.
Mapping Out The Timeline
As the first step in identifying the problem, I created a timeline of the key events in the reservation payment cycle. The ride was booked, it was serviced, the operator closed out the ride for the actual charges, the customer was charged and finally, the operator was paid. I labeled the phases in between these key events with numbers to frame the discussion. For each of the phases, I identified which statuses the reservation could take, what functionalities exist for payment adjustments and status changes, and what email communications occur.
Talking with Users
I then worked with Senior Customer Care Agents to generate a list of the most common use cases and in what phases of the payment cycle they occurred. I analyzed each of the use cases to derive a list of feature priorities.
Framing the Problem
I found that the main pain points would be solved with:
(1) ability to stop the payment cycle from moving forward once a dispute was identified
(2) functionality to adjust amount [to be] charged to customers both before and after the charge has occurred
(3) ability to debit the operator after the charge or prevent him from being paid if the charge has not occurred.
Understanding the Solutions
The next step was understanding the range of possible solutions given the development timeframe and the limitations of the existing system.
Translating the Need into Requirements
Next, I went back to the Reservation Payment Timeline to find the holes in the current functionality. I found that admins already had sufficient functionality for adjusting payments before customer charge. What we needed was a pause payment functionality and the ability to issue refunds and debits after payment.
Understanding Limitations
The next step was to understand the technical complexities surrounding payment adjustments and derive the most technically simple solution. After a discussion with the engineers, I found that adjusting payments in State #6 was most complex, however, it was essential to the feature priorities. So I asked, how can we make it less complex? We determined that:
(1) keeping the customer refund equal to the Operator debit
(2) not supporting charging the customer more would reduce a significant amount of complexity with adjusting payments in state 6.
Validating Assumptions
Then, as the last step of understanding the context, I went back to the Customer Care use cases to be sure the most use cases would be solved even with the technical limitations that customer refund must equal operator debit and customer cannot be charged more after they have already been charged.
Deriving the Strategy
Armed with the customer service use cases and feature priorities, a full assessment of the existing functionality as well as the technical limitations, I was equipped to determine a product strategy that met the end goal of solving the major pain points as quickly as possible. The key strategy pillars were as follows.
Leverage existing functionality
As displayed in the Overall Flow document, agents would have two different flows for ending the dispute based on the state of the reservation; it’s not ideal, but it saved us a lot of time on development, so it was a necessary compromise.
Create process flows
Because the feature made compromises for time, I wanted to make sure the SVP of Customer Care and the Customer Care agents were all comfortable with the work flows before development began.
Focus on main priorities
Ability to freeze payment cycle once a dispute was identified and issuing refunds and debits after the payment had occurred. The Dispute Forms show how this we focused the feature development only on these priorities.
Conclusion
The disputes functionality was completing development just as I transitioned from Limos.com to Dinamundo. In my first few weeks at Dinamundo, I continued to work with the team at Limos.com to devise a strategy for disputes moving forward. The Customer Care agents were thrilled with the additional functionality.