Revenue Automation: Designing a Trust-First Invoicing System at Scale
Revenue Automation: Designing a Trust-First Invoicing System at Scale
Revenue Automation: Designing a Trust-First Invoicing System at Scale
How we reduced fee payment defaults and operational load for schools managing thousands of invoices.
Scope:
Scope:
Product Feature
Product Feature
/
For:
For:
Zenda
Zenda
/
Duration:
Duration:
3 months
3 months
Year
Year
2025
2025
/ TL;DR
/ TL;DR
If you’re short on time
If you’re short on time
Schools rely on timely fee collection to function, but existing invoicing workflows were manual, fragmented, and difficult to scale.
Schools rely on timely fee collection to function, but existing invoicing workflows were manual, fragmented, and difficult to scale.
I designed a structured invoicing system that balances flexibility with control-improving collection reliability, reducing admin effort, and building trust at scale.
I designed a structured invoicing system that balances flexibility with control-improving collection reliability, reducing admin effort, and building trust at scale.
/ Context
/ Context
When invoicing powers daily operations,
Reliability matters more than flexibility.
When invoicing powers daily operations,
Reliability matters more than flexibility.
Invoice collection is one of the most critical operational workflows for schools. Delays directly affect salaries, infrastructure, vendors, and day-to-day operations.
Invoice collection is one of the most critical operational workflows for schools. Delays directly affect salaries, infrastructure, vendors, and day-to-day operations.
At Zenda, schools ranged from 500 to over 10,000 students, which meant invoicing had to work reliably across vastly different scales and invoice types — from tuition fees to uniforms, exams, and operational charges. This wasn’t just about generating invoices; it was about designing a system schools could depend on.
At Zenda, schools ranged from 500 to over 10,000 students, which meant invoicing had to work reliably across vastly different scales and invoice types — from tuition fees to uniforms, exams, and operational charges. This wasn’t just about generating invoices; it was about designing a system schools could depend on.
/ The Problem
/ The Problem
Before this system, fee collection relied on scattered tools and manual processes:
Before this system, fee collection relied on scattered tools and manual processes:
Announcements across messages, emails, websites, and notice boards
Repetitive copy-pasting of amounts and due dates
No single source of truth for payment status
Parents discovering dues late or missing deadlines
Admin teams spending disproportionate time on follow-ups
Announcements across messages, emails, websites, and notice boards
Repetitive copy-pasting of amounts and due dates
No single source of truth for payment status
Parents discovering dues late or missing deadlines
Admin teams spending disproportionate time on follow-ups
Over time, this led to delayed payments, frequent disputes, and increasing operational overhead as schools grew.
Over time, this led to delayed payments, frequent disputes, and increasing operational overhead as schools grew.
/ My Role
/ My Role
My responsibilities as a product designer on this project
My responsibilities as a product designer on this project
I led the end-to-end design of the invoicing system—owning UX, UI, IA, and edge cases—while working closely with product, finance, operations, and customer support teams.
I was directly involved in shaping how partial payments should function at a system level, not just how they appeared in the interface.
I led the end-to-end design of the invoicing system—owning UX, UI, IA, and edge cases—while working closely with product, finance, operations, and customer support teams.
I was directly involved in shaping how partial payments should function at a system level, not just how they appeared in the interface.
/ Shout Out To The Whole Team
/ Shout Out To The Whole Team
Madan
Madan
Product Designer
Product Designer
Jagadishwar
Jagadishwar
Product Manager
Product Manager
Rohith
Rohith
Product Head
Product Head
Vithin
Vithin
Tech Lead
Tech Lead
Jithesh, Fibin, & Divya
Jithesh, Fibin,
& Divya
Jithesh, Fibin,
& Divya
Engineering team
Engineering
team
Engineering
team
/ Key Constraints
/ Key Constraints
Why this was hard
Why this was hard
Invoicing here wasn’t a CRUD problem.
Invoicing here wasn’t a CRUD problem.
The system needed to handle:
Wide variance in student volume
Complex fee structures
Partial payments without breaking accounting logic
Bulk creation through CSV/XLS uploads
Communication across multiple channels
Performance constraints at scale
Auditability and reconciliation accuracy
The system needed to handle:
Wide variance in student volume
Complex fee structures
Partial payments without breaking accounting logic
Bulk creation through CSV/XLS uploads
Communication across multiple channels
Performance constraints at scale
Auditability and reconciliation accuracy
Any gap in the system translated directly into financial and trust issues.
Any gap in the system translated directly into financial and trust issues.
/ Goals
/ Goals
The System We Designed
The System We Designed
Instead of treating invoicing as a form, we designed it as a controlled financial workflow.
Instead of treating invoicing as a form, we designed it as a controlled financial workflow.
At a high level, the system supports:
Individual and bulk invoice creation
Component-based fee structures
Clear invoice states (paid, unpaid, partial, overdue)
Embedded communication with parents
Student-level invoice history
Audit-friendly tracking and reconciliation
At a high level, the system supports:
Individual and bulk invoice creation
Component-based fee structures
Clear invoice states (paid, unpaid, partial, overdue)
Embedded communication with parents
Student-level invoice history
Audit-friendly tracking and reconciliation
The focus was consistency and predictability across schools of all sizes.
The focus was consistency and predictability across schools of all sizes.
/ Design Implementation - Generating Invoices
/ Design Implementation - Generating Invoices
Structured Invoice Creation at Scale
Structured Invoice Creation at Scale
Designing invoice generation that works for one student or ten thousand.
Designing invoice generation that works for one student or ten thousand.
Schools needed the flexibility to generate invoices individually or in bulk, depending on operational needs. We designed a system that supports both structured CSV/XLS uploads and single-student creation, while validating data before issuance to reduce downstream errors.
Schools needed the flexibility to generate invoices individually or in bulk, depending on operational needs. We designed a system that supports both structured CSV/XLS uploads and single-student creation, while validating data before issuance to reduce downstream errors.
Invoices were built around clearly defined fee components, aligning with how schools already structure their finances. Once issued, payment links could be shared instantly across selected channels, ensuring parents could act immediately without additional follow-ups.
Invoices were built around clearly defined fee components, aligning with how schools already structure their finances. Once issued, payment links could be shared instantly across selected channels, ensuring parents could act immediately without additional follow-ups.
The goal wasn’t speed alone-it was reliable issuance at scale.
The goal wasn’t speed alone-it was reliable issuance at scale.
/ Design Implementation - Communication
/ Design Implementation - Communication
Communication as Part of the Transaction
Communication as Part of the Transaction
Invoicing doesn’t end at invoice creation—it ends when payment is completed.
Invoicing doesn’t end at invoice creation—it ends when payment is completed.
So communication lived inside the invoicing flow:
Payment links could be sent directly from invoice and student views
Admins could choose one or multiple channels (Email, SMS, WhatsApp, InMail)
Payment status and communication history stayed visible in one place
So communication lived inside the invoicing flow:
Payment links could be sent directly from invoice and student views
Admins could choose one or multiple channels (Email, SMS, WhatsApp, InMail)
Payment status and communication history stayed visible in one place
Tone and frequency were carefully controlled:
Professional, friendly language
Guardian-first communication
Daily limits to avoid spam
Templated messaging for consistency
Tone and frequency were carefully controlled:
Professional, friendly language
Guardian-first communication
Daily limits to avoid spam
Templated messaging for consistency
This reduced manual follow-ups and laid the groundwork for automation.
This reduced manual follow-ups and laid the groundwork for automation.
/ Design Implementation - Partial Payment Configuration
/ Design Implementation - Partial Payment Configuration
Designing Partial Payments Without Chaos
Designing Partial Payments Without Chaos
Partial payments weren’t optional.
Most schools already allowed phased payments for high-value fees, and parents expected that flexibility.
Partial payments weren’t optional.
Most schools already allowed phased payments for high-value fees, and parents expected that flexibility.
The challenge was enabling this without compromising clarity or control.
The challenge was enabling this without compromising clarity or control.
Key decisions:
Partial payments were allowed at the component level, not the invoice total
Smaller components remained full-payment only
Item-level partial payments were intentionally deferred
Partial payments were disabled by default and explicitly enabled
Configuration could be applied selectively or through advanced rules
Key decisions:
Partial payments were allowed at the component level, not the invoice total
Smaller components remained full-payment only
Item-level partial payments were intentionally deferred
Partial payments were disabled by default and explicitly enabled
Configuration could be applied selectively or through advanced rules
This gave parents flexibility while preserving accounting integrity and audit clarity.
This gave parents flexibility while preserving accounting integrity and audit clarity.
/ Design Implementation - Design Decisions
/ Design Implementation - Design Decisions
Key Design Decisions
Key Design Decisions
Some of the most impactful decisions were structural:
Some of the most impactful decisions were structural:
Manual + scheduled syncing:
Manual + scheduled syncing:
To prevent performance issues at scale, data synced on demand and through background jobs.
To prevent performance issues at scale, data synced on demand and through background jobs.
Intentional simplicity
Intentional simplicity
This tool is used daily. Predictability mattered more than expressive UI.
This tool is used daily. Predictability mattered more than expressive UI.
Constrained flexibility
Constrained flexibility
Not every configuration was allowed—limits kept the system usable.
Not every configuration was allowed—limits kept the system usable.
Deferred complexity
Deferred complexity
Item-level partial payments and over-customised communication were consciously postponed.
Item-level partial payments and over-customised communication were consciously postponed.
Each decision protected the system’s long-term reliability.
Each decision protected the system’s long-term reliability.
/ Outcomes & Impacts
/ Outcomes & Impacts
Results that mattered
Results that mattered
After launch:
Fee payment defaults reduced noticeably
Collections became more predictable
Invoicing-related support requests dropped
Admins gained clearer visibility into payment status
Schools trusted the system to handle scale
After launch:
Fee payment defaults reduced noticeably
Collections became more predictable
Invoicing-related support requests dropped
Admins gained clearer visibility into payment status
Schools trusted the system to handle scale
The invoicing feature became a stable foundation for further automation.
The invoicing feature became a stable foundation for further automation.
/ What I Learned
/ What I Learned
My Key Takeaways
My Key Takeaways
Financial systems reward restraint
Trust is built through consistency
Constraints make complex systems usable
“Boring” UX can be the right UX
Strong systems absorb complexity quietly
Financial systems reward restraint
Trust is built through consistency
Constraints make complex systems usable
“Boring” UX can be the right UX
Strong systems absorb complexity quietly
Why this matters
Why this matters
This project reinforced my approach to product design:
design systems that scale calmly, earn trust quietly, and work reliably under real-world pressure.
This project reinforced my approach to product design:
design systems that scale calmly, earn trust quietly, and work reliably under real-world pressure.
Next → Scheduling automated reminders
Next → Scheduling automated reminders
With structured invoicing in place, the next step was designing automated reminders to reduce manual follow-ups and improve on-time payments. Click here to go through that case study.
With structured invoicing in place, the next step was designing automated reminders to reduce manual follow-ups and improve on-time payments.
Click here to go through that case study.
With structured invoicing in place, the next step was designing automated reminders to reduce manual follow-ups and improve on-time payments.
Click here to go through that case study.
Madan Murali
Madan Murali
I’m always open to conversations, whether it’s about design challenges, collaborations, or just sharing ideas.
I’m always open to conversations, whether it’s about design challenges, collaborations, or just sharing ideas.