← Back to work
JivaIC

How we improve cash rotation and reduced CX calls by 9%

Introduced a way for our user to learn how much money they owed to Jiva, which helped increased cash rotation.

How we improve cash rotation and reduced CX calls by 9%

Summary:

How we improve cash rotation and reduced CX calls by 9%" discusses how Jiva improved its credit system for users, known as Sahabat Jiva or Micro-collectors (SJs/MCs). Previously, SJs had difficulty finding information about their outstanding credits, as this data was scattered throughout the app. This lack of clarity led to missed repayment deadlines, resulting in longer cash rotation times—averaging around 14 days—and increased customer support calls.

To address these issues, we restructured the app's information architecture. We prominently displayed outstanding credit amounts on the home screen, making it easier for SJs to access and manage their credit information. This change improved user experience, reduced the average cash rotation time, and decreased customer support calls by 9%.




Let’s start with some context:

Jiva operates on transactions, and these transactions require credit. We provide credit to our users, whom we refer to as Sahabat Jiva or Micro-collectors (SJs/MCs). Every credit issued comes with a repayment deadline. Users must either conduct a transaction with us or repay the credit on time. Following these rules is crucial to keep things running smoothly and avoid problems.

💡
Each transaction falls under a specific bucket or type of credit. There are four types of buckets Jiva provides for SJs:

For this system to function effectively, our SJs need access to clear, timely information about the credit to know how much they owe to Jiva. They should know: Do I have a credit nearing its due date? How much credit has Jiva extended to me? Which buckets does this credit fall into?

However, we failed to provide this information in a usable way. While the data exists, finding it feels like hunting for a needle in a haystack. Without a clear system to locate these details, even the most determined user would struggle—and likely give up. I know I would.


So what was the problem?

  • Scavenger Hunt: As mentioned earlier, finding the “outstanding” credit amount felt like a treasure hunt. This information was scattered across the app because Jiva issued different types of credits based on the transactions SJs performed.
  • Help Me, Help You: We didn’t make it easy for anyone. Poor communication and lack of clarity frustrated our internal teams and annoyed the SJs as well.
  • A Heads-Up Would Have Been Nice: Credits had due dates, and failing to repay them had costly consequences. Yet, we failed to notify users in advance. This led to a bad experience and poor communication overall.
  • Cash rotation: One of the most important metric in Jiva. Because knowing your outstanding was a struggle in it self, our user often forgot [Out of sight, out of mind] to repay it on time. At Jiva, this averaged around 14 days, which was far too long. I’ve tried explaning out Cash Rotation meant in Jiva’s context in the video below👇🏽

How bad was it?

  1. There were a couple of factors that led to this problem — the Information Architecture of the home screen was broken or rather never design to accommodate future requirements. Each team added their own features without thinking about the overall user experience. No one stepped back to ask, “How will the user navigate this?”
  2. Secondly, we misjudged the problem. We assumed our users were negligent or lazy, which is why they weren’t repaying credit or transacting with us in a timely manner.

UI back in the day and the issues with it:

  • While we thought we prioritised wisely, our decisions didn’t help anyone. The data visualisation on the app’s home screen showed the number of farmers an SJ was connected to. But why was that the first thing users saw? No one could say. In practice, this data wasn’t even meaningful—there was no hard limit of 100 farmers per SJ. They could connect with as many as they wanted, making the display irrelevant and unhelpful.
  • The remaining space was used to display the outstanding amount, but the transaction section lacked important context. It showed a running ledger of all activities—how much the user paid to Jiva, how much Jiva paid to them, and their balance—but the information wasn’t connected. One section might say the user would receive a payment, while another indicated they owed Jiva. This confusion left users unsure of what was expected, leading to more customer support calls.
  • Lastly, without a design system, UI decisions were often based on individual judgment. Each person determined what they thought was the best balance and how to communicate information effectively, leading to inconsistency and confusion.

Now that we were pretty clear on the problem statement and had enough space on the roadmap to pick it, we started drawing some rectangles. What should make us feel that we solved the problem or rather gave a good shot at it?

  1. Consolidated view of the outstanding amount which was easy to understand by SJs
  2. Easy to find where it is in the app
  3. Scalable design to incorporate future needs (By this point, several ideas were being discussed, and we needed a design that could adapt to future needs. We were also considering penalties for SJs who didn’t adhere to credit timelines, but more on that later.)

My design process at Jiva:

The focus on "my" process highlights that every designer has their own approach. Some find clarity by writing documents, others by creating low-fi wireframes in Figma, and some, like me, by screaming into the void before opening a notebook. I fall into the latter group—paper feels less intimidating, and the eraser is my friend.

Another good starting points was looking how others were solving a similar problem.
Another good starting points was looking how others were solving a similar problem.
Here, I liked out the most important number stood and I took that into my iterations.
Here, I liked out the most important number stood and I took that into my iterations.

So, what assumptions did I make when I started sketching? Well, I assumed that our users would better understand data visualisation—specifically pictorial representations—rather than long lists on a screen. That’s where I began. I used the old home screen as a reference. No one had said it didn’t work, so I figured it was a good starting point. In reality, no one said anything because we never asked. Looking back at my early sketches, I realise I was quite set on having some form of data visualisation on the screen.

At this point in my process is where I take this sketches to my PM and the Tech lead who is going to eventually pick this up. I avoid
At this point in my process is where I take this sketches to my PM and the Tech lead who is going to eventually pick this up. I avoid "design by committee" or decisions made simply because the majority agrees. These 1:1 conversations help me understand if the design is considering business priorities, the technical considerations like APIs, and any potential edge cases we might encounter.

The fun begins!

After more discussions and design critiques, I felt confident about the screen’s direction. I chose a long scroll layout to display everything at once—the amount, due date, bucket, and a pictorial representation to tie it all together. The next logical step was creating a quick, scrappy prototype and testing it with our users. The prototype we shared also included penalty concept as we wanted to see if the users were able to comprehend how it get calculated.

UT Goal: To check if MCs understand the information they see on the Total Outstanding screen on the MC app. With introduction of penalties at transactions level, can they identify transactions which are accruing penalty + how is the penalty calculated for each transaction and what is the amount they have to deposit using the cash deposit flow.

👇🏽 Here’s the Indonesian version of the prototype:


What did we learn from the UT?

The SJs we spoke with understood majority of things happening on this screen except the bar graph at the top. It was a clear indication that it was helping them, while creating more confusion.


What changed post release?

  • This initiative aimed to reduce the cash rotation metric. Following the introduction of penalties the next month, cash rotation dropped from 14 days to 10 days. While penalties played a role, I believe this initial step was the true game-changer. The design also improved communication of critical OS-related information to users, making it more effective.
  • No more hunting for information—the scavenger hunt finally ends!
  • We also observed a 9% reduction in customer support inquiries related to outstanding amounts, especially during the peak season.