Recurring Service: Approve once, get paid for every visit

01The core screen

One question turns an estimate into an agreement.

Step 3 of creating an estimate. Switch on Do any of your services repeat on a schedule? and the card asks only for what a schedule needs, while the preview on the right lists every visit it will create.

app.swivl.io · Create Estimate

02The problem

Repeat work ran on effort and memory.

Most of a home-service business’s money comes from repeat work: the same house every week, the same office every month. Swivl could only price, approve and bill one visit at a time, and Jobber, ServiceTitan and Housecall Pro all handle repeat work.

1. 01

   One visit at a time

   A 12-visit contract had nothing the customer could approve in one go, so the deal lived in calls and emails.

2. 02

   The same admin, every visit

   Every visit needed its own task, made and assigned by hand. Miss one and the crew never shows up.

3. 03

   Payments waited on memory

   Every visit needed its own invoice too. If nobody sent it, work already done went unpaid.

4. 04

   No view of the whole contract

   Nothing showed visits done, money billed, what was paid and what was still owed.

A weekly service with 12 visits meant 12 tasks and up to 12 invoices made by hand, all after a yes on the phone. Nothing was written down for the customer to approve, so the deal was easy to dispute later.

Before

After

Drag to compare

03Ideation

Make the estimate the agreement.

No new module to learn. Recurring work starts where every job already starts, in an estimate, with one question.

• Reuse what people know

  The same three steps, form on the left, live preview on the right. Nobody learns a new screen.

• Approved means locked

  After approval nothing changes by accident. Edits to a running job touch only future visits.

• Automate the paperwork, not the people

  Swivl creates every visit, but a person still decides who goes: tasks start Unassigned.

01

When does an invoice go out?

Ruled outOn a calendar date

Every visit billed on a fixed day, whether or not the crew has been.

Shipped24 hours after the work

Per visit, after each task is closed; or once, after the last one. The business picks.

WhyNot the calendar, the work. A customer is only ever billed for a visit that happened, and nobody has to remember to send it.

What it costsMoney arrives a day after each visit rather than on a set date. A customer who wants one bill gets the one-time charge instead.

02

Who decides who goes to each visit?

Not in v1Assign a crew automatically

Every new visit lands on someone’s schedule the moment the customer approves.

ShippedEvery visit starts Unassigned

Swivl creates the task; the team decides who goes, and when.

WhyAutomate the paperwork, not the people. A twelve-visit agreement should not quietly fill twelve days in a crew’s calendar.

What it costsOne manual step per visit for the dispatcher. Automatic assignment is on the list of what comes next.

03

How much goes into the first release?

Left out of v1Preferred days, holidays, pausing a series, compliance tracking

Each one real, each one another control in the card and another case for QA.

ShippedA name, a schedule, when it ends, how it is billed

The smallest card that turns an estimate into an agreement.

WhyCut from the final plan to ship a clean first version, on web, mobile web and the app at once. It went live 51 days after the first design review.

What it costsA business with seasonal or irregular visits still edits by hand until a later release.

Ruled out for v1

Shipped

04The solution

One approval. Then it runs itself.

The same journey on every screen: build the agreement, the customer approves it once, and the job with all its visits is waiting. These are the real screens, played as a prototype.

1 2 3 4 5

1. One question turns it on.Do any of your services repeat on a schedule? sits in step 3 of the estimate everyone already uses. No new module to find.

2. It says what will happen, before it happens.A job and its tasks will be created automatically. The PDF and the dialogs repeat it, so nothing arrives as a surprise.

3. The weekday, spelled out.On Tuesday under the frequency. It was added after launch, when a walkthrough showed the day was easy to misread.

4. Swivl does the date maths.Set 12 visits and it works out the end date; pick an end date and it counts the visits.

5. Invoices follow the work.Per visit, 24 hours after each task is closed, or once after the last. Either way nobody has to remember to send it.

100%

Fit

Drag to move · Ctrl + scroll or pinch to zoom · double-click a screen to focus it Swipe sideways to move · pinch to zoom · ⤢ for full screen

05The effort

Three weeks of design, seven weeks to live.

About three weeks of design, from the first review on 30 Mar 2026 to handoff on 22 Apr, then four weeks of build that I supported until launch on 20 May.

• 44WebScreens and states in the final file.
• 20Mobile webScreens and states in the final file.
• 16iOS and Android appScreens and states in the final file.
• 78Engineering ticketsBackend, frontend, mobile, QA and product, all shipped.

Live on 20 May

After 24 Jun

06Business outcome

Live on 20 May 2026, on every platform.

Recurring Service went live in release 4.24.0, on web, mobile web and the iOS and Android app. What changed for a business on Swivl, in the words of the launch note:

• 1

  Predictable revenue they can plan around, because every visit in an agreement is billed on its own.

• 2

  Less admin per contract. The job, its tasks and its invoices are created for them.

• 3

  Clearer expectations, fewer disputes. The customer signs the full schedule, billing and terms before work begins.

• 4

  One source of truth. Every task, invoice and visit links back to the original agreement.

The launch note makes no usage claim, so neither does this page. The numbers to watch: how many estimates turn recurring, the share of visits billed without a manual step, and what is still owed on recurring jobs. Next: auto-pay, agreement templates and automatic crew assignment.