This case study is password protected
MonetizeNow unifies CPQ, billing, and metering on one product catalog. I joined as solo design in a tiny startup and built the design practice while shipping onboarding, quoting, and sales visibility as the company grew from 2 to 10 customers.
MonetizeNow unifies CPQ, billing, and metering on one platform with a single product catalog.
BDR teams are the main users: configure quotes, send contracts through DocuSign, and run billing, including usage-based products where consumption is tracked and invoiced in the same system. The company wins when more customers run quote-to-cash on the platform end to end.
When I joined there were two customers and no real design foundation. My work sat on two sides: onboarding each company's catalog and pricing models in our system, and the quoting and sales experience (revenue recognition, dashboards, and the flows BDRs live in daily). You cannot quote reliably until that catalog setup is right.
The quoting tool only works if the customer's products, rates, and pricing rules are configured correctly in MonetizeNow first.
More customers on the platform, and onboarding that does not take months.
We were not ready for how companies actually price: scheduled changes on multi-year deals, minimum commitment, trial pricing, and models the tool did not support yet.
Every onboarding change had to scale holistically so one customer's pricing setup did not break another's, not case-by-case patches on a shared platform.
I talked directly with customers in a small startup. I was there when onboarding took about three months, and later when we could look back and say a mid-size company could launch in about three weeks with the features we had shipped.
Retrospective from implementations as we added pricing models and self-service setup, not a formal benchmark study.
Company growth over 2.5 years while quote-to-cash surfaces matured.
Design system, design workflow, and quote-to-cash UX with the founders.
I owned the design practice: Figma file structure, design kickoff, design reviews, and a component library with prototypes where before there was only copy-paste UI. I mentored our second designer on design best practices. Most product decisions ran through the CEO and CTO.
The product only works when onboarding, quoting, billing, and usage connect. Every new customer surfaced pricing edge cases; quote and PDF contract parity and a small eng team shaped how fast we could generalize versus patch.
Quote-to-cash surfaces on one catalog:
Shipped work below: onboarding and rates first, then quoting at signing risk, then sales visibility.
Customers could not configure pricing with enough flexibility, and it was unclear which pricing model applied among similar options like tiered by dollar versus tiered by percentage.
We supported eight rate types on one page in one form, including minimum commitment and tiered structures that look alike but behave differently. The UX had to help teams choose the right model and set it up without breaking customers already live on the platform.
On multi-year contracts, buyers and BDRs need to see future rate changes at signing; if the quote and contract hide them, the liability is real.
The design problem was how to show scheduled rate changes on a quote so people understand what changes and when, in the live BDR tool and in the export customers sign. The quote and contract stay in parity: same deal, two formats.
Design system foundations (same period):
If contract data already shows how deals perform, BDRs and team leads should see it in the product.
The sales dashboard gives reps a view of personal goals and performance; team leads can see how their group is doing. Smaller in scope than rates or scheduled changes, but visibility closes the loop after quoting.
Revenue recognition for finance and leadership (same platform):
