Overview
Paying for a course should be the easy part of a sale. It wasn't. Pay Bill makes it simple for everyone: the agent creates the bill from the student's profile in our CRM, and the student pays it the way they already pay an electricity bill, in the bKash app or with cash at any bKash shop. The money arrives already attached to the right student, course and agent.
The spec is complete and the feature is in development with our CRM and backend engineering teams.
The problem
- Agents had to teach payment. On almost every sale, the agent explained how to pay in the app, and sometimes walked the student through it step by step. Hard for the student, and a lot of extra effort for the agent just to complete one payment.
- Booking money was handled by hand. To hold a seat, students sent booking money to the agent's supervisor, who then managed it internally. Manual work, with room for loopholes.
- Many students simply couldn't pay. The app and website only take payment from a student's own bKash wallet, not bKash bill payment. A student with no money in their bKash, or no bKash account at all, couldn't pay through a bKash shop.
The result was a lot of money arriving outside the system. About 85% of collections were bKash Send Money to personal numbers, with no link to a student or a course, so a person matched each one by hand. That's where money landed on the wrong student, sales were credited to the wrong agent, and payments went missing or were counted twice.
Goals
- Paying is easy for the student. They pay themselves, in the bKash app or at any bKash shop, without help from the agent.
- Money that matches itself. Every payment arrives already attached to a student, a course and an agent, so nobody matches it by hand.
- One honest view for the agent. What the student owes and has paid, without arithmetic and without asking anyone.
- Every sale has a channel. Recorded the moment the order is created, so collections can be split by campaign, partner and team.
The solution
A Make Payment button in the student's profile, with Pay by Bill as its first tab. The agent picks the course, the phase and a coupon, then how the student pays: in full, or booking money now and the rest later. Creating the order sets the student's phone number as the reference and sends the steps on WhatsApp or SMS from the same screen.
The student opens bKash, taps Pay Bill, finds Shikho and enters their own number. Before any money moves, bKash asks Shikho what that number owes and shows the payer Shikho's name and the amount, which protects them from paying the wrong biller. After payment, bKash confirms back with a transaction ID, the CRM shows the payment, and a full payment unlocks the course. Paying the balance later walks exactly the same steps.
Decisions and trade-offs
The phone number is the bill
It's the one thing every student already knows, and bKash shops already take bill payments the same way as an electricity bill. No new number to give out, nothing to lose.
No manual payment entry
An agent saying "the money arrived" is the exact problem Pay Bill exists to end. An earlier plan had a Record Booking Payment button. It was built, reviewed and removed.
One open order per student
The reference is the phone number, and bKash can only answer with one amount for it. A second order is refused, and the screen names the order that already exists.
A coupon on every order
Every sale must carry a channel, so each order is tied to the team or campaign that made it.
Booking amounts in settings, not code
The booking options can change without a release, and only amounts that leave a real balance are offered.
The CRM does no maths
Every figure, date and status comes from Shikho's backend. The CRM keeps a copy and shows it, so two systems can never disagree about what a student owes.
Stale but correct, never wrong
If an update hasn't arrived, the screen shows the last figures it read rather than guessing. And if bKash sends the same payment twice, the second one changes nothing.
What we left out
- Bank transfers. About 10% of collections, at higher values. A real gap, left for later on purpose, because it needs its own integration.
- A student portal. The journey starts with the agent, by decision.
How we'll measure it
Pay Bill isn't live yet, so there are no results to show. These are the numbers it will be judged by, 8 weeks after launch:
The share of off-platform money that arrives through Pay Bill.
The one number to watch. Measured in taka, not payments, because a full course fee and a small part-payment aren't the same event.
- Total collections must not drop. The guard on the number above. If Pay Bill is harder than Send Money, students stop paying instead of switching.
- Unmatched money trends to zero. Money that arrives without a matching order is shown loudly, never silently credited or dropped, and the pile should shrink every week.
- Most students pay before the bill expires. Measured as the median time from order to first payment, so a few very late payers don't skew it.
What I learned
The most important decision was taking a feature out. A shortcut that lets people record money by hand brings back the problem you set out to remove.
The CRM and Shikho backend engineering teams are building it.
Back to all work