In October 2024, one of our broker clients came to us with a specific request. They were already using payment-by-link functionality, but through a system outside of Mobius. They wanted this capability integrated into our platform so they could manage everything in one place instead of switching between systems.
On the surface, it seemed straightforward. Enable brokers to send payment links to policyholders via SMS or email. The policyholder clicks the link, pays, and the policy converts to active. We were essentially adding one more option to a payment method dropdown. Simple enough.
But I've learned that in a complex policy administration system like Mobius, UI simplicity often masks workflow complexity. Adding "Pay by Link" to a dropdown isn't just a UI change. It's introducing a new asynchronous payment state into a system built around synchronous transactions. It touches quote management, payment processing, policy conversion, document generation, status tracking, and broker workflows that have evolved over years.
As I started working with our Product Owner to understand the requirement, I realized we were making assumptions about how brokers actually handle payments. We had one client's workflow in mind, but what about the others? How did different brokers manage the gap between quote and payment? What were their expectations about when a policy becomes "live"?
I proposed we pause before designing and talk to multiple clients first. If we were building this capability into the platform, we needed to understand the range of payment workflows across our broker base, not just optimize for one client's process.
Over three months, I conducted discovery interviews with four broker clients. I drafted the interview questions and paired with our Product Owner to run the sessions, walking each client through an early prototype to gather their reactions and requirements.
What I expected: Some variation in preferences around SMS vs. email, maybe different opinions on link expiry timing.
What I found: Four fundamentally different approaches to managing the gap between quoting and payment, shaped by their size, client base, and regulatory interpretation.
A mid-size broker focused on direct consumer sales. They wanted payment links sent automatically the moment a quote was generated. Speed was everything because customers shopping on comparison sites would move on within minutes. Their tolerance for manual steps was near zero.
A specialist broker handling high-value commercial policies. They never wanted automatic payment links. Their process involved days of back-and-forth with clients, adjusting coverage, negotiating terms. A payment link was the final step after a verbal agreement. Sending one too early would feel presumptuous to their clients.
A large broker with strict regulatory oversight. They needed payment links to include specific regulatory disclosures and wanted full audit trails of when links were sent, opened, and completed. Link expiry wasn't a preference; it was a compliance requirement.
A growing broker transitioning from manual to digital processes. Some of their agents wanted automation, others preferred manual control. They needed both options available and the ability to configure defaults per team or per product line.
The discovery interviews made it clear that building one rigid payment link workflow would satisfy at most one of our four clients. The others would either reject it or work around it.
I designed a system built around three principles: configurable automation (brokers choose when links are sent), flexible communication (SMS, email, or both, with customizable templates), and transparent status tracking (clear visibility into where each payment stands).
The configuration layer lets each broker set up pay-by-link to match their existing workflow. Broker A gets automatic sending. Broker B gets manual triggering after verbal agreement. Broker C gets compliance-ready templates with audit trails. Broker D gets per-team defaults with manual override.
The design is complete and has been validated with all four broker clients. Development is scheduled to begin once current platform priorities are delivered. The discovery and design work means the engineering team has clear specifications and edge cases documented upfront, reducing the risk of rework during build.
Talk to multiple clients before designing for one. The original request came from a single broker. If I had designed for their workflow alone, three other clients would have been underserved. Discovery across four clients revealed that what looked like one feature was actually a configurable platform capability.
UI simplicity can mask system complexity. Adding a dropdown option sounds simple. But introducing asynchronous payment into a synchronous system required thinking through state management, timeout handling, partial payment scenarios, and reconciliation workflows.
Configuration beats compromise. Rather than finding a middle ground that partially satisfied everyone, building configurable automation let each broker get exactly the workflow they needed. The extra design effort upfront reduces support overhead and customization requests later.
