A System for Customer Disputes


Customer Care Solution

Since launch, 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, 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.

    My Role

  • Product Manager

    Project Goals

  • (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

    What I did

  • user flows
  • wireframes
  • prototypes
  • project management
  • timelines
  • release planning
  • scope estimations
  • strategy definition
  • development requirements

    Project Challenges

  • business emphasis on time to market with a technically challenging feature set

Identifying The Problem

The 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.

time and location 1
time and location 1

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.

time and location 1

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.

time and location 1
time and location 1

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.

time and location 1

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.

time and location 1
time and location 1

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.

time and location 1


The disputes functionality was completing development just as I transitioned from to Dinamundo. In my first few weeks at Dinamundo, I continued to work with the team at to devise a strategy for disputes moving forward. The Customer Care agents were thrilled with the additional functionality.


Stress Free Parking

view next project