Example payment schedule
In this example the customer pays a 30% deposit when booking and the rest 42 days (six weeks) before the booking date. If someone books less than 49 days in advance, they pay everything at once when booking. The workflow then moves the status along, sends a reminder and rejects unpaid bookings. The meaning of each field is explained in What are payment schedules?.
1. The two rules of the payment schedule
| Field | Rule 1: Deposit | Rule 2: Balance |
|---|---|---|
| Name / Description | Deposit | Remaining amount |
| Target text "description" after merge | empty | Payment of the full amount |
| Target text "date" after merge | empty | At moment of booking |
| Default | Yes | Yes |
| Product | empty | empty |
| Priority | 1 | 2 |
| When | 0 days · At moment of booking | 42 days · Before date of booking |
| Amount | 30 · Variable - based on full amount | 70 · Variable - based on full amount |
| Time before | 0 days | 7 days |
| Time after | 0 days | 0 days |
| Merge | Next (does nothing here) | Previous |
| Who / Direction | Client · Incoming | Client · Incoming |
The values in bold are the safety net. Rule 2 says: if the balance falls less than 7 days after the deposit, merge me with the previous one. The target texts are on rule 2, because rule 2 is the rule that is absorbed into rule 1 in a conflict. What the customer then sees is one line "Payment of the full amount", "At moment of booking".
2. How it works out on the timeline
- A. 120 days ahead. The deposit falls on day 0, the balance on day 78 (120 − 42). That is well over 7 days apart, so there is no conflict: two payments.
- B. 45 days ahead. The balance would fall on day 3 (45 − 42). That is within the 7 days of Time before, and Merge is set to Previous: the 70% is added to the deposit. The customer pays 100% when booking.
- C. 30 days ahead. 42 days before the booking date was already 12 days in the past. A payment moment never falls before the booking, so the balance moves to now. It then falls at the same moment as the deposit and is merged: 100% when booking.
So the boundary is 42 + 7 = 49 days. Anyone who books 49 days or more in advance pays in two parts. Anyone who books later pays everything immediately.
Why not "Time after 49 days" on the deposit?
An earlier version of this example set Time after 49 days with Merge Next on rule 1. That does something different from what it seems. Time after counts from the payment itself, not from the booking date. For every booking made less than 91 days (49 + 42) in advance, the deposit then moves on into the balance. The customer pays nothing when booking and the full amount 42 days before the booking date, or immediately if that moment has already passed. And because rule 1 has already moved on, the Time before of rule 2 never gets its turn.
If you do want a late booker to pay everything later, Time after with Merge Next is the right choice. Pick one per conflict.
3. The workflow: moving the status along
The payment schedule decides what has to be paid and when. The workflow decides what happens when that does or does not happen. You set this up on the object, under Workflow › Automatic transitions. In this example the statuses are 20 Booking, 21 Reminder, 29 Deposit paid, 30 Fully paid and 80 Rejected.
| # | From → to | After this event | Waiting time | What it does |
|---|---|---|---|---|
| 1 | 20 → 29 | Payment Schedule: schedule which is paid | 1 minute | The deposit has come in. |
| 2 | 20 → 30 | Time for which booking has been paid | 1 minute | Everything was paid at once. |
| 3 | 29 → 30 | Payment Schedule: schedule which is paid | 1 minute | The balance has come in. |
| 4 | 20 → 21 | Date/time of creation of booking | 7 days | Nothing paid a week after booking: reminder. |
| 5 | 21 → 80 | Last status transition | 14 days | Still nothing two weeks after the reminder: reject. |
| 6 | 21 → 29 | Payment Schedule: schedule which is paid | 1 minute | Deposit paid after all, after the reminder. |
| 7 | 21 → 30 | Time for which booking has been paid | 1 minute | Everything paid after all, after the reminder. |
All transitions have Valid for: both parent and child and the action change transition. You enter the waiting time in the days and/or minutes field.
The reminder: transition 4 with an e-mail
A reminder always goes together with an e-mail transition on the same status change:
| Status transition old → new | 20 Booking → 21 Reminder |
| E-mail to | To client |
| Copy to BCC | Yes |
| Valid for | Both parent and child |
| Template | Booking_Reminder1 |
Put a payment link in this e-mail, so the customer can pay right away, and state the deadline: within 14 days, or the booking is rejected. On transition 5 you can link an e-mail in the same way, so the customer knows the booking has been rejected.
If you also want a reminder for the balance, create the same set starting from status 29, with the event Payment Schedule: schedule which must be paid.
