Selling in installments

An installment plan lets a client pay for a one-off purchase, like a program or a package, across several smaller payments instead of one charge. You set the due dates and amounts up front; the client’s balance is worked off as each payment comes in.

Installments only apply to one-time purchases. Subscriptions already bill on a repeating cycle, so the “Pay in installments” option only appears when the purchase is a one-time price.

Turning on installments

You can start a plan from either of the two places you create a purchase: the quick add on a client’s profile, or the full purchase details page. Both work the same way, a switch labeled Pay in installments, and both show the same schedule editor underneath it once it’s on.

Building the schedule

• Click Add installment for each payment you want, then set its due date and amount.
• You need at least two rows to make a plan. If there’s really only one payment, leave the switch off and sell it as a normal one-time purchase.
• Every row needs a due date and an amount greater than zero.
• The rows must add up to exactly the purchase price. The total line under the table shows the running sum against the price, and flags how far off you are (“remaining” if you’re under, “over” if you’re over) until they match. You can’t save the purchase while they’re mismatched.

Editing a plan after the purchase exists

Open the purchase’s full details page and use Edit schedule on the Installment Schedule section to change due dates or amounts, add a row, or remove one.

Rows for installments that are already fully or partially paid are locked. You can’t change their date or amount, and you can’t delete them. This keeps a plan from silently rewriting a payment a client already made. You can still add, remove, or adjust the remaining unpaid rows, as long as the schedule keeps summing to the full purchase price.

Recording a payment

Each row in the schedule has a Record payment action. It opens a small dialog defaulted to today’s date and to the installment’s full outstanding balance, so a normal full payment is just confirming the defaults. To record a partial payment, change the amount to whatever the client actually paid; the row stays open for the remaining balance. There’s also a Mark fully paid shortcut next to it that records the full outstanding balance in one click, without opening the dialog.

Above the schedule, the purchase shows a running line: “Collected $X of $Y ($Z outstanding)”. That figure adds up every payment recorded against every installment so far. It’s the same number whether the client paid in full on one row or chipped away at several with partial payments.

Seeing what’s due, due soon, or overdue

On the purchase itself

Each row in the schedule carries a status chip that’s worked out from its due date and how much of it has been paid:

A row reads Due soon once it’s within about a week of its due date and still unpaid, and Overdue once that date has passed with anything still owed on it. This recalculates itself every time you look at the page, so there’s nothing to refresh.

Across your Purchases list

The purchases list has a filter row above the table that sorts every installment plan into one of four states, plus columns showing where each plan stands:

Every plan sits in exactly one state, worked out from its earliest payment that is still owed:

• Overdue is that payment’s date having already passed. Someone owes you money now.
• Due soon is that payment landing within about a week. Nothing is late yet.
• On track is a client who has paid everything that has come due, with payments still scheduled further ahead. Nothing to chase, and this is the state most healthy plans sit in.
• Fully paid is every payment on the plan collected.

Because the four states cover every plan exactly once, they add up: Overdue plus Due soon plus On track plus Fully paid is your whole installment book.

Each filter searches your entire list on the server, not just the page you happen to be looking at, so a client whose payment is due on Thursday is found whether they sit on page one or page four. The result count under the table always describes the same set as the rows above it.

Two columns fill in the detail without opening anything:

• Next due is the date of the next payment still owed. Sort by it to work down your list soonest first.
• Progress counts the payments collected and the money collected, for example “2 of 4, $600.00 of $1,200.00”.

Paused, canceled and expired plans are left out of all four states, and show a dash in the Plan column. A paused client isn’t expected to be paying right now, so chasing them would be wrong; their Next due and Progress still show, so you can see where the plan stood when you paused it.

Reminders and alerts

Installment plans can remind your client before a payment is due, and tell you when one goes late. All of it lives on one screen: Shop → Settings → Payment Reminders, reachable from the Payment reminders button on the Shop overview.

What your client can receive

Two reminders, each switched on separately, each sent by push, email, or both:

• Ahead of time, using the due soon window above. With the default 7 days, a payment due on the 28th is announced on the 21st.
• On the due date itself.

Both are off until you turn them on, so nothing goes out to anybody because this feature exists. Neither one is sent for a plan you’ve paused, or for a payment that’s already settled.

Write the wording yourself. These placeholders are filled in when the message is sent, and the preview under each box shows exactly what your client will read:

Anything you type that isn’t on this list is left alone, so a typo like {clientName} shows up in the preview instead of quietly vanishing from the message.

What you receive

• When a payment is late. On by default, after a grace period you set (3 days to start), as a notification in the app and, unless you untick it, an email. The grace period is why a payment that arrives a few hours after midnight doesn’t bother you.
• When a payment comes due. Off by default. One notification on the day itself, before anything is late, for coaches who’d rather see it coming.

By default these go to the account owner. Use Send payment notifications to to point them at specific team members instead.

Late alerts use {daysLate} as well as the placeholders above.

Two things worth knowing

Nothing is sent retroactively. When you first switch reminders on, payments that came due more than a couple of weeks ago are marked as handled and left alone, so enabling this can’t email a client about installments from months back.

Each message is sent once. A reminder is recorded against the installment as it goes out, so a payment that stays unpaid won’t generate the same message again the next day.

What this doesn’t do yet

Your client is never told a payment is late. Only you are, through the alerts above; chasing the conversation is still yours to have. There’s also no repeating nag: each reminder fires once, and there’s no SMS or digest.