Edves Billing Manager
At Edves, the first version of the billing problem I was handed sounded simple: schools pay through bank transfer, and it's slow. The real problem lived somewhere else entirely.
I started with the finance team, not because they were the easiest stakeholder but because they were the ones absorbing the cost of the current process every week. I sat with them and mapped, transaction by transaction, how a school's payment actually moved from a bank transfer notification to a reconciled line in our system. It was slower than I expected, and messier. A payment would come in, someone would have to manually match it against an invoice, chase a school for a missing reference number, correct a mismatched amount, and update records by hand. Multiply that across 2,000-plus schools and you get a team spending hours a week on work that added no value to anyone, just friction removal.
That gave me the shape of the internal pain, but I didn't trust it as the full picture, so I went to the schools next. Proprietors and finance staff at the school level had a different complaint. Bank transfers meant waiting for confirmation, sometimes days, before their account reflected payment, which caused its own headaches with parents and term deadlines. Nobody on either side loved the current process, but nobody could tell me exactly what would fix it either. That's usually the signal that you need a third conversation, so I went to Paystack.
Meeting with Paystack was less about the finance team's pain or the schools' pain and more about constraints: what could we actually build, what would a real payment integration require from us technically, what would it cost, what would the settlement timeline look like for schools, and where were the limits of what "self-service" could mean given the rails we'd be building on. That conversation reshaped what I thought the solution was. I'd been assuming some kind of automated reconciliation layer bolted onto the existing bank transfer flow. Paystack made it clear the more durable fix was to remove bank transfer as the primary path altogether and let schools pay directly through the platform.
With those three sets of conversations done, I mapped the user journeys, mostly the school proprietor initiating a payment and the finance team reconciling it, and wrote the PRD. Then came the part I actually enjoy most: prototyping. This was 2023, before any of the AI-assisted design tooling existed, so I built the flows by hand in Figma, screen by screen, testing the logic of each state as I went. What happens if a payment fails halfway through. What does a partial payment look like. How does a school with three children enrolled see their invoices versus a school administrator managing five hundred students. There was no shortcut for that thinking; it was hours of manually wiring frames together and asking myself where the flow would break.
The prototype worked because it was shaped by three different rooms, not one.
I brought that prototype back to the people I'd started with. Schools clicked through it and told me where it didn't match how they actually thought about paying fees. Finance told me where the reconciliation view didn't give them what they needed to trust it over their spreadsheets. Some of that feedback was small, labeling and sequencing. Some of it changed real structure, like how partial payments were represented and how a school's payment history was surfaced. I iterated through a few more rounds before it shipped, because the first version being wrong in these smaller, specific ways was expected. The point of showing it early was to find that out before it was expensive to fix.
Once it launched, we watched two numbers closely as leading indicators before we could say anything about revenue: how many schools were actually switching from bank transfer to the self-service flow, and what percentage of payments people started were payments people finished. Both moved in the right direction quickly, and the finance team's manual reconciliation hours dropped steadily as more schools switched over. Three months after launch, revenue was up 25 percent.
I don't think that number means much on its own. What made it real to me was that it traced back to a specific, findable point where money was getting stuck, one we only found by talking to the people actually stuck at it rather than assuming leadership's read on the problem was complete. The prototype worked because it was shaped by three different rooms, not one. The revenue number is the headline, but it's only credible because of the weeks of unglamorous mapping and iteration underneath it.
Payments integration (Paystack) · User & stakeholder research · PRD writing & user-journey mapping · Figma prototyping · EdTech domain