ZENSKAR · Q2 2024

From pilot dropout to first invoice in minutes : redesigning Zenskar's billing module.

Zenskar is a billing and revenue recognition platform for usage-based SaaS. When I joined as founding designer, pilots were getting sandbox access and disappearing before generating a single invoice. The brief was better UX. The real problem was that the product assumed users would read the docs. I rebuilt the experience from the mental model out.

Role
Founding product designer. End-to-end IC, sole designer for 11 months.
Team
1 designer, 4 engineers, 1 PM. Direct line to the CEO and head of revenue.
Timeline
14 weeks to closed beta. 6 month rollout in production.
Status
Shipping July 2026. Powers 40+ weekly demos today.
Zenskar contract canvas, product cover
01 Context

Sales-led growth with a product that wasn't keeping up.

Zenskar's growth was sales-led, with about 40 demos happening every week. The sales team tagged the design team for qualified prospects, which meant we were learning directly from potential customers what was working and what wasn't. Each enterprise customer had their own dedicated Slack channel for feedback and communication.

The problem was structural: pilot users received sandbox access with dummy data and then were largely left to figure it out. Usability issues were stacking up, new customer requirements kept coming in, and the roadmap had ambitious features that couldn't land without a better foundation.

My job was to find the patterns beneath the noise and redesign the product around the user's actual mental model, not the system's internal data model.

02 Users

Two very different people, one product.

Zenskar's primary users are sales representatives and accountants at companies selling usage-based services. Both share one primary goal: automatically generate correct invoices at scale. Everything else is a means to that end.

01 Sales representative

Owns the customer relationship.

Sets up products, creates contracts, negotiates pricing.

Knows the customer's contract inside out. Lives in 40-minute discovery calls and three-month pilots. The product is a tool to win the next deal.

Needs speed & clarity.
02 Accountant

Owns invoice accuracy.

Verifies billing, approves invoices before they reach customers.

Sensitive to ambiguity in numbers. Won't sign off on an invoice they can't trace. Their job is to be the last person who saw it before it left the building.

Needs confidence & trace.
03 Four challenges

Four structural problems blocking the primary goal.

Discovery surfaced one big symptom (pilots not generating a first invoice) and four root causes. The redesign had to address all four, in order.

01

Documentation dependency

Pilot users got sandbox access with dummy data but spent hours in documentation before touching the product. Many lost interest before creating a first invoice.

02

No product reusability

The same API sold at $0.10/min to one client and $0.20/min to another, but there was no mechanism to reuse a product with different pricing. Users duplicated products instead.

03

Contracts as a black box

Complex contracts gave users no feedback while building. They couldn't see what an invoice would look like until after publishing.

04

Flexibility vs complexity

The advanced price editor was powerful but nearly unusable for non-engineers. Flexibility existed but was locked away from the people who needed it.

04 Conceptual model

Before any screens: map the mental model.

Most confusion came from a mismatch between how users thought about billing and how the system worked internally. Before touching Figma, I built a conceptual model from the user's perspective and validated it with engineering.

One four-noun chain had to be visible throughout the product, not hidden in navigation or docs.

Metering
Usage of Product A
Usage of Product B
Usage of Product C
Contract
Contract info
Contract Period
Billing Cycle
Products
Product A Pricing
Product B Pricing
Product C Pricing
Features
Discount
Tax
Credits
Invoices
Invoice 1
Invoice 2
Invoice 3
Invoice N
Contract Duration
Products contain Prices. Prices go into Contracts. Contracts generate Invoices. Every screen, URL, search result and empty state was rebuilt to reinforce that order.
05 Onboarding

Teach the model before the modules.

The conceptual model was the diagnosis. The Getting Started guide is the direct product-level response to Challenge 01, the documentation dependency killing pilot conversions. Rather than pointing users to external docs, we embedded a structured onboarding flow directly in the product.

01

Tasks are time-boxed

5 min, 4 min, 3 min. Each step is small enough to feel achievable. Users see a checklist, not a learning curve.

02

Video surfaces the concept first

Before touching anything, users can watch a short explanation of how Zenskar works. Conceptual understanding before controls.

03

The model made actionable

Generate Invoice turns the conceptual chain into a sequence: Add customer, Create Product, Publish Contract, Generate Invoice.

04

In-product, not in docs

The guide replaces the need to leave the product. Users orient without Slack, external docs, or a customer success call.

Zenskar Getting Started, Intro to Zenskar with embedded explainer video
Zenskar Getting Started, Generate Invoice step-by-step checklist
Zenskar Getting Started, Set up Usage step-by-step checklist
Zenskar Getting Started, Explore Accounting step-by-step checklist
Getting Started · in-product onboarding
06 Products module

Empty states that teach, not just prompt.

The first thing a new user sees is an empty product list. This was redesigned from a blank page with a "Create Product" button into an educational moment, explaining what a product is, what it's used for, and how it connects to generating invoices.

The most important insight came from watching real users: people were creating duplicate products just to have different pricing for different customers. I introduced Prices as a first-class concept within a Product. One product, multiple pricing instances. No duplication.

Zenskar Products empty state, educational copy and a Create Product CTA
Create Product side panel with name, description, SKU, tax code, and tags
Email Service product detail, Add Price empty state with product information sidebar
Products module · empty state, create flow, product detail
07 Add Price

Tame pricing complexity, without hiding it.

Pricing gets complex fast: flat fee, per-unit, tiered, volume, matrix. Combined with billing cycles, free credits, discounts, and minimum commitments, the configuration space is enormous. Four principles guided the solution.

01

Group, not list

Data inputs grouped by meaning (rate, billing, discounts), not stacked in one long form.

02

Always-accessible tour

First-time users get a guided tour. The info icon makes it re-accessible anytime, even months later.

03

Real-time output preview

As config is entered, a live invoice preview updates. Users see the output before they commit.

04

Metering bridge

Usage-based products require metering. Price creation becomes a natural introduction to that module.

Add Price editor, pricing model tour step 1 of 3 with live invoice preview
Add Price editor, Usage tour step 2 of 3 explaining metered vs non-metered
Add Price editor, Billing Cadence tour step 3 of 3 explaining prepaid vs postpaid
Email Service product detail with Per Unit 10 and Volume Price configured
Add Price editor · guided tour and configured prices
08 Contracts module

Redefining what "contract" means in this context.

A contract in the legal sense is a broad document. In Zenskar, it has a more specific meaning: the subset of agreement data related to usage, pricing models, and billing terms. This had to be made explicit in the UI, otherwise users conflated it with their actual legal contracts.

Contracts landing page with educational copy and Create Contract CTA
Create Contract side panel with optional plan import, customer, period, currency, and renewal
Empty contract with Products tour tooltip 1 of 3
Empty contract with Phases tour tooltip 2 of 3
Empty contract with Publish tour tooltip 3 of 3
Add Product side panel listing product library and pricing details
Draft contract with Email Service product added and the right-hand timeline populated
Successful publish confirmation with confetti and Go To Invoices
Contracts module · landing, create flow, in-context tour, add product, publish
09 Contract timeline

The feedback loop that was completely missing.

The biggest pain: users couldn't see what a contract would produce until after they published it. Once products are added to a contract, a live timeline generates automatically, showing when each invoice will fire and for how much. Try it below.

Contract detail with right-side timeline. A tooltip explains that for prepaid products, the first invoice is sent on the contract start date and follows the billing cycle thereafter.
The billing cadence is finally something I can show to a customer without needing to explain what everything means first.
Enterprise customer · via Slack
10 Edit product panel

Simple by default, advanced when needed.

Simple mode is the default, a flat form covering around 80% of cases. Advanced mode activates automatically the moment any attribute gets a second version. No toggle. No settings to find. Delete the second version and the interface returns to simple.

Advanced Editor for Add Price, showing the form on the left and a node graph on the right with Billing Cadence, Usage, Discount, and Per Unit Price nodes wired together.
11 Invoice preview

Seeing the output before you commit.

A reactive, card-based layout showing each future invoice as it will appear to the customer. Quantities are editable inline on upcoming invoices. Amounts recalculate in real time as configuration changes. New line items are explicitly flagged. Drag the sliders.

Contract invoices tab with Upcoming and Draft tables. Inv_001 shows an editable tooltip Click to view the invoice.
Draft invoice Inv_001 detail panel with service line, totals, and bank transfer instructions.
Invoice preview · upcoming list and per-invoice detail
12 Outcome

Phased release, strong signal.

The redesign was released to existing customers in phases. Feedback was excellent and two insights immediately shaped the next release cycle.

Financial relationship view

Users navigate repeatedly between a customer and their contracts. A customer-level revenue view (revenue to date, active contracts, upcoming invoices) became the natural next build.

Collaborative editing

Multiple users working on the same contract were missing each other's changes. A collaboration layer with change tracking is planned for the next release.

40/wk

Demos supported by a self-explanatory product.

2

New roadmap directions surfaced by usage patterns.

↓

Pilot drop-off and documentation dependency.

Zenskar is an ongoing engagement. The advanced price editor and accounting integrations are covered in a separate study.

Keep reading

Two more deep dives.

CogniCor · 2018 – 2024

Closed a $1M ARR deal by renaming "Knowledge Graph" to "Knowledge Base."

Platform redesign across three modules for a top-3 US wealth manager. Beta in 3 months. Studio acqui-hired.

Read case study →
Awesome Daddies · 2014 – 2018

Built a 10-person product studio in Kerala. Sold it to CogniCor.

Founder & lead designer for 40+ B2B clients. Acqui-hired on a three-year contract.

Read case study →
Available · one engagement · starting Q3 2026

Looking for a founding designer who has done it before?

I'm taking one new engagement starting Q3 2026. Series A or post-pre-seed, B2B, AI-native preferred. Open to founding hire, design partner, or a six-month "ship the second version" contract.

paul@paulemiljohnson.com Book a 30-min intro call →
Replies within 48h, usually faster.
Best fitSeries A · B2B SaaS
Engagement3–6 months
RemoteUTC+5:30, NYC overlap