Payment recurrence
Overview
Remessa Online is a SaaS provided by the fintech Beetech and it has a dedicated platform for natural persons and another for legal persons (which we call Remessa Online for Business). I had the opportunity to work with them due to a partnership between R.O and the software house I was working at the time.
The recurring payment feature for businesses was something that many users had been requesting. Legal person customers with a remaining balance and a completed shipping operation couldn't redo this operation in an automated way. It was mandatory to do it all over again each transaction: sending all the documents, waiting for back-office approval, etc. It usually caused a false duplicity feeling and triggered flow locks that had to be solved offline, losing track of operations.
DISCOVERY
The first move was to onboard us inside the R.O team and the product itself. We had a one week immersion to get to know the existing team, its cerimonies, rituals and also learn about the financial world: how international transactions work, relations between banks, taxes, etc.
The second step was to analyze all the research files the client already did, such as market insights, qualitative and quantitative data about both platforms, costumer behaviors, target audience and its needs.
Creating a backlog
After analyzing all documents and data received my team elaborated a backlog with all the demands and pain points. We took this massive backlog and presented it to the client's product owner.
They didn't know for sure what were the priorities in a stakeholder point of view so we planned a CSD matrix with several stakeholders and our squad, in order to list the points of attention, identify improvements and assemble a consistent backlog.
With the results I was able to collect data and insights but we still needed to develop a backlog with real tasks. To resolve this issue we created an impact versus effort matrix which indicated the most voted and debated item: payment recurrence.
This feature, despite having high complexity, after execution, would bring benefits in automation, not only for users but for back-office employees who worked with contracts as well. Until that time, they had to deal manually with thousands of document pages and locking mechanisms, in addition to unlocking many features that relied on a recurrence flow to be implemented.
How it happened
To develop this feature, I met with the product owner and engineering team so we could discuss all the business rules, acceptance criteria and technical limitations. I had to keep in mind I would need to separate completed operations from those in progress and that a few inputs, like currency, type of operation and beneficiary data couldn't change after the first transaction.
Results
I created an interactive prototype that still had to be adjusted a few times, due to new business rules. I came up with a simple solution that only took three steps to be completed.
After the prototype was approved by the client, it was time to hand it to development. So, I put together a handoff document for engineers with assets, local components, content guide, etc.
Next steps
✦ Checking backlog to start smaller tasks that depends on recurrence, bringing more comfort to transactions;
✦ Sharing lessons learned and results with the client's team in order to have 100% alignment between squads;
✦ Adding an NPS metric to the product to ensure we are giving voice to customers.
