Invoice and estimate revamp

Context

Swivl is field-service software for small trade businesses: plumbers, HVAC and electrical contractors, roofers, landscapers, cleaners. Everything about a job lives in one app, from the first call to the payment. The office books the work, technicians do it on site, and the business quotes it with an estimate and bills it with an invoice.

Who touches an invoice

Office admin

creates and sends

Technician

bills on site

Owner

reviews

An estimate is the quote: the work, the price and the terms, sent to the customer to approve or to pay a deposit on. Once it's approved or the deposit is paid, the business turns it into an invoice with one click. The customer, line items, tax, terms and deposit all carry over, and the invoice goes out only when someone sends it.

Image The V0 screen (last year's design) annotated with red callouts.

Problem statement

Office admins billed a finished job through a four-step form, and only saw the invoice their customer would get at the very end. Once it went out, every invoice just said "Open", so owners couldn't tell who had paid, who was late or who to chase. This case study is about turning that form into one page where you build the invoice, send it and get paid.

Pain points

4 steps

No preview while creating, so mistakes were found at the end

You only saw the invoice after all 4 steps. A wrong tax rate typed in step 2 meant going back and reopening that step.

0 discounts

No discounts, so pricing happened outside the invoice

There was no discount field, and the job's costs sat in a separate calculator.

0 pay links

No way to pay from the invoice, so payments were logged by hand

The invoice couldn't collect money. A payment was only recorded in a dialog after it had already arrived.

1 status

One status for every unpaid invoice, so owners couldn't see who was late

Every sent invoice said "Open", so a waiting, a part-paid and an overdue invoice all looked the same.

Three lenses

Customer

time, errors, cash collected

Business

activation, churn, upsell

Sales

demo objections, lost deals

The evidence loop

Every round started from the same four inputs. Customer feedback named the pain, the sales team said what it cost in demos, the recordings showed where it happened, and the numbers showed how big it was. When the same problem turned up in at least ⟨5⟩ recordings and ⟨3⟩ tickets within a month, it was big enough to start a round.

Customer feedback

Which step hurts, in the customer's words, heard in support tickets, in-app feedback and calls.

Volume: ⟨about 60⟩ items

Sales-team feedback

What comes up in demos and lost deals, heard in debriefs with the sales team.

Volume: ⟨12⟩ sessions

PostHog recordings

Where people stall and what they do instead, seen in sessions filtered to the invoice builder.

Volume: 106 recordings

Usage numbers

How many, how long and how often, measured on the funnel from New invoice to Send.

Volume: 559 invoices sent, Apr–Sep 2026

The choices that shaped the product

Key decisions

Revamp 1February 2026

Decisions: 1

Drop the wizard, keep the PDF in view.

One full-screen page: the form on the left, the PDF on the right, updating as you type.

Why: the parts of an invoice depend on each other, and a discount on one line moves the total, the tax and the fee. Seeing it happen catches a mistake while it is cheap.

Cost: the preview takes half the screen and the form got narrower, so I checked the layout on a 2560 px screen and as one long scroll before committing.

2

One card per line item.

The item, its full description, a quantity stepper, rate, one Tax % field and a discount.

Why: people read an invoice line by line, and a card holds the whole description. One tax field replaced the switch and the percentage.

Cost: each card is about 360 px tall, so a 15-item invoice becomes about 5,400 px of form. Round 2.1 paid that back.

3

Two kinds of discount, explained once.
ImageA line discount (struck price, “$23 off”) and the invoice discount, with the show-once tooltip

A discount on a line, in percent or dollars, shown as the old price struck through with "$23 off", and a discount on the whole invoice. The first time someone adds a line discount, a tooltip explains both: "Apply it per line item or once across the whole invoice after adding your products." After that it never shows again, on any invoice, session or device. I wrote nine rules for when it appears, down to "opens the field and types nothing".

Why: line and invoice discounts answer different conversations, a bundled job and a loyal customer.

Cost: two discount types to explain, and a rule set to keep in sync across sessions and devices.

4

The card fee as a choice.
ImageThe processing-fee toggle with its plain-words explanation, and the fee line on the PDF

A toggle decides who pays the 3.5% processing fee, with the consequence spelled out: "If you want customers to cover the platform fee, turn this on. If you leave it off, the fee is taken from your payout." The PDF shows it as its own Standard Processing Fee line, and the invoice page shows it in a banner.

Why: the fee changes either the customer's total or the business's payout, so the business should decide it knowingly.

Cost: one more decision on every invoice.

5

Deposits that can be undone.
Image“Deposit Not Received?” with Undo Payment and its confirmation dialog

A deposit paid on an estimate carries into the invoice it becomes. For a deposit that never arrived, I designed the way back under the question "Deposit Not Received?": two methods, ⟨what each did and which one shipped⟩, and Undo Payment on the deposit-paid estimate, with a confirmation before it runs.

Why: a deposit marked paid by mistake breaks the balance on every document after it.

Cost: ⟨what the shipped method cost, and why you passed on the other⟩.

6

An invoice page built from data.
ImageThe round 2 invoice page: products, customer and job, terms, cost breakdown, fee banner and media

After saving, the invoice page listed the products with their discounts and tax, the customer and job, the terms and the estimate it came from, the cost breakdown, the fee banner and the attached media.

Why: the office needed every field of the invoice in one place.

Cost: the page stopped showing the document the customer received.
Shipped: February 2026, on web: the full-screen builder with the live PDF, item cards, line and invoice discounts with the show-once tooltip, costs and markup in the form, the card-fee toggle, Import from Job for the job's photos and files, the deposit reversal, and the new invoice page.

Revamp 1.1July 2026

The invoice becomes how you get paid

Trigger: Round 2 put the document in view. The next layer was the money: the form ended in Next, sending and payment lived on another page, and once an invoice went out, the business could only wait. ⟨The evidence that started round 2.1, and whether the push for Swivl Payments was part of it⟩.
Decisions: 1

Finish where you build.
ImageThe footer: Cancel, the running total, Take Payment and Send, with the send options open

The form footer reads: Cancel, the running total, Take Payment, Send. Send opens email or SMS in place, and a confirmation follows.

Why: once the invoice is right, the next move is sending it or getting paid, and both depend on the total.

Cost: four things share one footer on a laptop screen, and the less common send and payment options moved into dropdowns.

What I replaced: my own round 2 footer, which ended in Next.

2

Ways to pay, on the document.
ImageThe Pay Now button on the PDF, next to the part-payment, instalment and sign-then-pay options

One toggle puts a secure payment link on the PDF as a Pay Now button. The business can accept part payments, set fixed or flexible instalments, record a payment made without the link, and ask for a signature before payment: a five-step flow that ends with the card charged, the signature attached and a receipt emailed.

Why: the round 1 dialog recorded money after it arrived; these options go and collect it.

Cost: every option needed its own states, emails and receipts, from a partial-payment email and SMS to instalment tracking in the list.

3

Statuses that say what to do next.
ImageThe invoice list with the six statuses: Awaiting Payment, Partially Paid, Past Due, Paid, Draft, Void

Round 1's "Open" became three statuses: Awaiting Payment, Partially Paid, and Past Due with its date, next to Paid, Draft and Void. Each status has its own invoice page and its own actions.

Why: "Open" told the owner nothing about what to do.

Cost: six versions of the invoice page to design and keep consistent, on web and on mobile.

4

The invoice page leads with the PDF.
ImageThe PDF-first invoice page with the side rail: amount paid, payment due, the estimate and the job's costs

The page shows the document the customer received, with pages, zoom, print and download, and a side rail with the payment details (amount paid, payment due, the estimate it came from) and the job's costs.

Why: after sending, the owner asks two things: what did the customer get, and how much is left.

Cost: the round 2 data tables shrank to a side rail, and a long product list now reads inside the PDF.

6

Mark what the customer never sees.
ImageExpense Manager with its Internal Only tag, and the Additional options toggles

The cost tool became Expense Manager, tagged Internal Only: "Track your labor, materials, and other costs to see the profit on this job." The invoice description carries the same tag. Optional fields moved into Additional options (work order number, customer notes, internal description, customer signature), each a toggle that asks before it deletes what was typed.

Why: once costs lived inside the form, the line between internal and customer-facing had to be visible.

Cost: optional fields sit one click deeper, and removing one takes a confirmation.

7

See the whole document, on any screen.
ImageThe Form / Preview switch showing the PDF full width, and the mobile web invoice page with its bottom sheet

A Form / Preview switch hides the form and shows the PDF full width, and the PDF links the customer to the attached photos and documents. The invoice page exists on mobile web for every status, with actions in a bottom sheet.

Why: a three-page invoice needs full width to proofread, and the people on site carry phones.

Cost: two modes to switch between, and a mobile version of every status page to maintain.
Shipped: June 2026, on web and mobile web: the new footer, the pay link and the payment options, six statuses with their own pages, the PDF-first invoice page, compact line items with tiers, a customer card and job import that prefill the invoice ("Link your job to fetch estimate, media and cost details to prefill the invoice easily"), Internal Only labels and Additional options, the Form / Preview switch, an instalments view in the list, and the mobile web invoice pages. Through August I kept tuning: Take Payment became Record Payment, Form / Preview became Default / Preview, the customer card gained an Edit action, and a bug-fix pass went through the form.

Image

Beforethe round 2 builder, with its footer ending in Next

Image

Afterthe round 2.1 builder, with the total, Take Payment and Send in the footer.

Moved: Average time from New invoice to Send went from ⟨3 min 25 s⟩ to 2 min 10 s. 38% of paid invoices came through the Pay Now link, and ⟨7%⟩ were paid in instalments.

Decision depth

#01The live PDF beside the formRound 2

Principle

Show the document while people build it. Behind a button in round 1, beside the form in round 2, full width on demand in round 2.1.

Problem

In round 1 you saw the invoice only on the review page, after four saves. So a wrong tax rate typed in step 2 showed up at the very end, and fixing it meant going back and reopening that step. We saw it in ⟨recordings of people going back from the review page, tickets about wrong totals, a funnel step⟩.

Solution

One full-screen page: the form on the left and the PDF on the right, updating with every field, so a mistake shows up the moment you make it, while it's still cheap to fix. On a 1440 px screen the form gets 712 px and the PDF 726 px. I checked it on a 2560 px screen and as one long scroll before committing.

Ideas I dropped: ⟨the options you tried first, for example a preview panel inside the steps⟩. The trade-off: the form lost half its width, so every field had to work in a narrower column.

#02Who pays the card feeRound 2

Principle

Let the owner choose, and say what the choice does. Anything that changes what the customer pays, or what the business keeps, is a choice the owner makes on purpose.

Problem

Every online payment carries a 3.5% fee. It comes out of either the customer's total or the business's payout, so the business should get to decide which. Round 1 gave them no say in who paid it. We heard it in ⟨feedback or sales conversations about the fee⟩.

Solution

A toggle on each invoice lets the business choose, with the consequence in plain words: "If you want customers to cover the platform fee, turn this on. If you leave it off, the fee is taken from your payout." The PDF shows the fee as its own line. In round 2.1 the invoice page also names the payer: "⟨Customer⟩ is covering the 3.5% standard processing fee."

Ideas I dropped: ⟨for example one account-wide setting, or always passing the fee on⟩. The trade-off: one more decision on every invoice, and a total that changes with it.

#03Send and payment beside the totalRound 2.1

Principle

Put the next action next to the total. Send and payment moved from a review page, to the invoice page, to the form footer.

Problem

My round 2 footer ended in Save Draft and Next. Sending and taking payment lived on the invoice page, one step away from the total they depend on. So even when the invoice was ready, you had to leave the form to send it or get paid. We saw it in ⟨the funnel step and the recordings: whether people dropped between Next and Send⟩.

Solution

Once the invoice is right, the next step is sending it or getting paid, and both depend on the total. So the footer now holds Cancel, the running total, Take Payment and Send. Send opens email or SMS in place, and the less common options sit in the dropdowns. On the PDF, one toggle adds a Pay Now link. After release, Take Payment became Record Payment.

Ideas I dropped: ⟨for example keeping a review step before sending⟩. The trade-off: four controls in one footer at laptop width, and I threw out my own round 2 footer four months after it shipped.

#04Six statuses instead of OpenRound 2.1

Principle

A status should say what to do next. "Open" hid the difference between waiting, part-paid and overdue. Six statuses with their own actions show it.

Problem

In round 1 every sent invoice read "Open", defined in the product as "sent to the customer and awaiting their approval/payments". A waiting invoice, a part-paid one and an overdue one looked the same, so owners couldn't see who was late. We heard it in ⟨tickets or feedback from owners chasing payments⟩.

Solution

Six statuses that say where the money is: Awaiting Payment, Partially Paid and Past Due (with its date), next to Paid, Draft and Void. Each has its own invoice page and action menu, on web and mobile web, so the status also tells the owner what to do next.

Ideas I dropped: ⟨for example one Unpaid status with a due-date badge⟩. The trade-off: six versions of the invoice page and six action menus to keep consistent.

Edge cases

What if…?

A deposit was marked paid but never arrived?

The risk: The balance is wrong on the estimate, on the invoice it becomes, and on every payment after
The decision: Undo Payment on the deposit-paid estimate, behind a confirmation, plus ⟨the method that shipped for invoices⟩

What if…?

The customer pays only part?

The risk: Under one "Open", a part-paid invoice looks unpaid, and the owner chases money that already came in
The decision: A Partially Paid status with its own page, a partial-payment email and SMS, and instalment progress in the list: "Installment 1 of 3 · Amount paid (33%) $40 / $120 · Next due"

What if…?

The business needs a signature before it takes the money?

The risk: Paid work with no sign-off, or a signature with no payment behind it
The decision: An optional step, off by default. The customer signs (draw or upload), the signature is attached to the invoice, then the customer pays: "Signature captured and attached to the invoice. A receipt has been emailed to the customer."

What if…?

A line discount and an invoice discount meet on one invoice?

The risk: ⟨The discount deadlock: what broke, and what the user saw⟩
The decision: ⟨What you shipped⟩

Killed idea

One card per line item (Revamp 1, decision 2)

What we assumed

People read an invoice line by line, so each item deserved a card: its full description, a quantity stepper, rate, one tax field and a discount.

What users experienced

⟨What the recordings or feedback showed⟩. In the round 2 designs, each card is about 360 px tall, so a 15-item invoice runs to about 5,400 px of form.

Why we killed it

The idea was only half right. People do read line by line, but they don't need every line open as a full editor at once. The card made one line easy to read and the whole invoice hard to get through. The more items there were, the longer the scroll.

What replaced it (round 2.1)

Rows about 85 px tall, with one inline editor open at a time. The same 15 items now take about 1,275 px, plus the one line you're editing.

The idea I pushed back on

Passing the 3.5% card fee to every customer by default

The ask: The sales team wanted the 3.5% card fee added to the customer's total on every invoice, by default. In demos, owners kept asking why they should lose 3.5% of each payment, and a default looked like the quickest answer.

What I argued: A default changes the customer's total without the owner ever choosing it. A customer who approved an estimate at one price would get an invoice asking for more, and the PDF would no longer match what they agreed to. So I argued for a switch on each invoice, with what it does written right next to it. I showed both versions to ⟨5⟩ owners on sales calls, and ⟨4⟩ of them wanted to decide job by job.

How it ended: We shipped the switch on each invoice, with the consequence in plain words and the fee as its own line on the PDF. Sales got a one-click way to pass the fee on, and since round 2.1 the invoice page says who is covering it, which is easy to show in a demo. We also started tracking how many invoices pass the fee on. It's a row in the Impact table.

User flows & states

Estimate to invoice

The rule
What the customer approved and paid arrives without retyping; a paid deposit shows as Deposit Paid

Image

The estimate page with its deposit

Image

the invoice built from it
Send

The rule
Send sits next to the total it depends on

Image

Send ▾ in the footer

Image

the email or SMS pop-up, then Invoice Sent
Pay through the link

The rule
The customer pays from the document they received

Image

The payment-link toggle

Image

Pay Now on the customer's PDF
Pay in parts or instalments

The rule
Every payment shows what is paid and what is due next

Image

The fixed or flexible instalment set-up

Image

the list card with "Installment 1 of 3"
Record a payment

The rule
Money collected outside the link still lands on the invoice

Image

Record Payment in the footer

Image

the record-payment screen for an invoice sent without a link
Sign, then pay

The rule
The signature is attached before the card is charged

Image

The signature step

Image

the payment confirmation
Undo a deposit

The rule
Nothing reverses without a confirmation

Image

Undo Payment on the deposit-paid estimate

Image

the confirmation pop-up

Days from sent to paid: ⟨21⟩ → ⟨12⟩

Impact

The headline number is the time from New invoice to Send, 6 min 20 s on average in August 2025 and 2 min 10 s in June 2026. It moved more than anything else across the three rounds. Round 1 is the earliest version I have screens for, so it is the baseline.

Metric	Feb 2026 · round 2	June 2026 · round 2.1	Source
Average time from New invoice to Send	⟨3 min 25 s⟩	2 min 10 s	PostHog funnel
Started invoices that get sent	⟨78%⟩	⟨86%⟩	PostHog funnel
Invoices with a discount	⟨14% of invoices⟩	⟨23% of invoices⟩	Billing data
Invoices where the customer covers the card fee	⟨29% of invoices⟩	⟨34% of invoices⟩	Payments data
Invoices paid through the Pay Now link	no link	38% of paid invoices	Payments data
Invoices paid in instalments	no instalments	⟨7% of paid invoices⟩	Payments data
Days from sent to paid	⟨20 days⟩	⟨12 days⟩	Billing data
Invoicing support tickets per month	⟨14⟩	⟨9⟩	Support tool
Invoices sent per week (safety)	~20 a week (May 2026)	~34 a week (Sep 2026)	PostHog

THE SAFETY METRIC. Invoices sent per week held at about 20 through the round 2.1 release, then rose to about 34 by September 2026, in a flow businesses bill through every day.

Rebuilt Swivl's invoice three times in ten months: from a four-step form to a document customers pay from.

Numbers

Problem

Constraints

Key insight

Solution

My role

The deep dive

Context

Who touches an invoice

Office admin

Technician

Owner

Problem statement

Pain points

No preview while creating, so mistakes were found at the end

No discounts, so pricing happened outside the invoice

No way to pay from the invoice, so payments were logged by hand

One status for every unpaid invoice, so owners couldn't see who was late

Three lenses

Customer

Business

Sales

The evidence loop

Customer feedback

Sales-team feedback

PostHog recordings

Usage numbers

Key decisions

Drop the wizard, keep the PDF in view.

One card per line item.

Two kinds of discount, explained once.

The card fee as a choice.

Deposits that can be undone.

An invoice page built from data.

The invoice becomes how you get paid

Finish where you build.

Ways to pay, on the document.

Statuses that say what to do next.

The invoice page leads with the PDF.

Mark what the customer never sees.

See the whole document, on any screen.

Decision depth

Edge cases

A deposit was marked paid but never arrived?

The customer pays only part?

The business needs a signature before it takes the money?

A line discount and an invoice discount meet on one invoice?

Killed idea

The idea I pushed back on

User flows & states

Estimate to invoice

Send

Pay through the link

Pay in parts or instalments

Record a payment

Sign, then pay

Undo a deposit

Before & after

Building the invoice

Line items

Sending

Taking payment

Where the money is

Impact