Why This Matters
We ask for deposits for two completely different reasons, and the right behaviour depends on which one applies:
- Cashflow — for events that are happening regardless. Annual recurring bookings (grads, convocations, government conferences, annual fundraisers) where the producer has the budget already and is functionally indifferent to paying us 50% in advance. The deposit smooths our cash, not our risk.
- Risk filter — for events that might waste our time. New or unproven clients where we want to know they are committed before we release planning resources. The deposit is the gate that turns a maybe into a yes.
Confusing these two purposes leads to either (a) chasing deposits on rock-solid annual events and harming the relationship, or (b) burning planning hours on quotes that were never real.
This is how we "Hit Our Marks" on cashflow without losing the ability to "Win Together" with our long-trust clients.
Four Fields Drive Behaviour
The deposit policy reads off four fields on the event record:
1. Status — x_studio_selection_field_kt_1j462te0b
Where the event is in its lifecycle. Set by the Sales Manager at quote build time and updated as the event progresses (or by automation — see Deposit Collected below).
| Value | Internal label | Meaning |
|---|---|---|
tentative |
Tentative | The event might not happen. Some Tentative events are speculative new bookings; others are long-trust clients lightly penciling a date. |
confirmed |
Firm | The event is real and going forward. |
planned |
Showbook Ready | Showbook is built and the event is ready to execute. |
event_in_progress |
Event In Progress | Live event days. |
closed |
Event Closed | Post-event, financials closing. |
2. Deposit Required — x_studio_deposit_required (boolean)
Whether a deposit is being asked for at all. Set by the Sales Manager at quote build time; checked when the event meets the threshold and is not exempt.
3. Deposit Purpose — x_studio_deposit_purpose
Why the deposit is being asked for. Only meaningful when Deposit Required is True. Set by the Sales Manager at quote build time.
| Value | Internal label | Effect on planning |
|---|---|---|
cashflow |
Cashflow | Planning proceeds normally per Status. The deposit smooths cash timing, it does not gate work. This is the default. |
risk_gate |
Risk Gate | Planning resources do not release until the deposit is paid in full. When the deposit lands, automation flips Status from Tentative to Firm. |
4. Deposit Collected — x_studio_deposit_collected (boolean)
Whether the deposit has actually arrived in our account. The Customer Support Admin ticks this checkbox by hand at the moment she posts the deposit payment to the deposit invoice in Xero (which she does daily as part of the Accounts Receivable Processing Guide).
Asking is not the same as receiving. The "Ask for Deposit" mail activity tracks the chase — sending the invoice, leaving a voicemail, replying to a billing question. Sandra may complete that activity multiple times across follow-up rounds without the cash ever landing. Only the boolean flipping to True signals "money is in."
Automation listens for this field flipping to True. When it does on an event whose Deposit Purpose is Risk Gate and Status is Tentative, automation also flips Status from Tentative to Firm in the same write — releasing Planning automatically. (For Cashflow events the flag still flips, but Status is unchanged because Planning was never gated.)
The boolean is editable by anyone with edit rights on the event record — same as every other event field. It exists so Planning, dashboards, and reports have a clean column to read.
The Status and Purpose Fields Are Independent
A Tentative event can be Cashflow (long-trust college lightly penciling a maybe-event). A Firm event is rarely Risk Gate, but could be. The Sales Manager picks both at quote build time.
The Walkthrough — Why All Four Fields Are Needed
Imagine NLC College, a long-trust client we work hard to keep, asking us to lightly pencil in an event that might not happen. The Sales Manager sets:
- Status = Tentative (the client themselves said "might not happen")
- Deposit Required = True (event total is over $2,500)
- Deposit Purpose = Cashflow (long-trust account; we don't want to gate them)
- Deposit Collected = False (until Sandra flips the activity)
The result: Customer Support invoices the deposit, Planning sees "Cashflow" and proceeds lightly per Status. NLC College feels respected, we still get the cash on time if it comes.
For a brand-new client we've never worked with, the Sales Manager sets the same fields except Deposit Purpose = Risk Gate. Planning sees "Risk Gate, not collected" and waits. When Sandra posts the deposit payment in Xero and ticks Deposit Collected, automation flips Status to Firm and Planning releases resources.
The Rule
A deposit is required on every event whose total quoted value is $2,500 or greater, regardless of Status. The threshold is the same for Firm and Tentative.
| Field | Standard |
|---|---|
| Threshold | Total quoted value ≥ $2,500 (before tax) |
| Amount | 50% of total quoted value |
| Due | On contract / quote acceptance |
| Invoice | Customer Support Admin issues the deposit invoice the same business day the quote is accepted |
What changes is the purpose of the ask (Cashflow vs. Risk Gate), the gating behaviour on Planning, and the refund rule on cancellation.
Cashflow Deposits
Planning, gear holds, and labour booking proceed per Status. Cashflow deposits do not gate work. Customer Support chases the deposit because we want the cash on time, but if it is late we keep moving.
If a Cashflow deposit ultimately is not paid and the event happens, the unpaid amount rolls to the final invoice. If the event cancels and we have committed resources, the refund schedule applies the same as for any Firm event.
Typical Cashflow situations:
- Annual recurring events on the calendar history (grads, convocations, annual conferences, annual fundraisers)
- Government and Crown corporation events with confirmed budget allocation
- Hotel partner events under master service agreements
- Long-trust corporate and education accounts (3+ years of paid-on-time history) — including events those clients lightly pencil in as Tentative
Risk-Gate Deposits
The deposit is the gate. Planning does not allocate resources until it lands. When the deposit is paid in full, automation flips Status from Tentative to Firm and Planning releases resources.
Typical Risk-Gate situations:
- New clients with no payment history
- Bookings that feel speculative — the client themselves seems unsure
- High-effort quotes where wasted planning would hurt if the event evaporates
- Any quote where the Sales Manager wants commitment before investment
If a Risk-Gate deposit never arrives, the event stays Tentative and times out on its own. There is no exposure — we just move on.
Exemptions
Some events that meet the $2,500 threshold should not be asked for a deposit at all. The Sales Manager approves exemptions on a per-quote basis.
When to consider an exemption:
- Government clients with purchase-order processes that prohibit deposits
- Repeat clients where requesting a deposit would damage the relationship more than the cash protects us
- Hotel partners under master service agreements that already define payment terms
The exemption process:
- The Sales Manager flags the quote as deposit-exempt before sending it to the client.
- The reason for the exemption is documented on the event record (a short note such as "Govt — PO process. Approved by Sales Manager 2026-05-03.").
- The General Manager is notified — the exemption appears in the next L10 quote review so visibility is automatic, not optional.
- If the General Manager disagrees, the exemption is reversed and the deposit is requested.
Exemptions are nearly always for Firm events. Tentative events without a deposit have nothing gating them, so an exempt-and-Tentative event is a contradiction — flip it to Firm or do not exempt it.
Non-Payment & Escalation
The "Ask for Deposit" activity (sales item #41) tracks every event where a deposit is required and outstanding. The metric is the Events with Deposit Required scorecard — target is 0 outstanding.
Day-by-day escalation when a deposit goes past due:
| Day past due | Action | Owner |
|---|---|---|
| Day 0 (due date) | Friendly reminder email + phone call | Customer Support Admin |
| Day 1 | Escalate to Sales Manager. Sales Manager calls the client directly to understand what's blocking payment. | Sales Manager |
| Day 5 | Escalate to General Manager. General Manager decides: extend, reclassify Firm → Tentative, or cancel the booking. | General Manager |
The goal of escalation is to solve the problem with the client, not to punish them. Most late deposits are accounting confusion, not bad intent. The Customer Support Admin and Sales Manager work the problem together before the General Manager is pulled in.
For Tentative events specifically: the escalation chain still runs, but the consequence of non-payment is just that the event stays Tentative and times out on its own. The General Manager's decision on Day 5 is usually "drop it and move on."
Cancellation Refunds
The refund rule depends on the event's Status at the moment of cancellation:
Tentative — Fully Refundable
If a Tentative event is cancelled and the deposit happens to be on file (e.g., it landed but the Status hadn't flipped to Firm yet), it is refunded in full. While Tentative we have not committed planning resources or gear, so there is no cost basis to retain.
Firm — Sliding Scale by Days-Out from Event Date
Once the event is Firm, planning is committed. The refund schedule reflects our cost-commit timeline:
| Cancellation Window (Firm events) | Refund |
|---|---|
| More than 30 days before event | 100% — full refund |
| 30 to 14 days before event | 50% — half refund |
| Less than 14 days before event | 0% — deposit forfeited |
Deposits paid for events that have already happened are not subject to this refund schedule — they apply to the final invoice.
Roles & Accountability
| Role | Responsibility |
|---|---|
| Sales Manager | Classifies quotes as Firm or Tentative at build time. Identifies which quotes meet the deposit threshold. Approves exemptions and documents reasons. Backs up the Customer Support Admin on day-1 escalation calls. |
| Customer Support Admin | Issues the deposit invoice on quote acceptance. Tracks the "Ask for Deposit" mail activity (the chase) and completes it after each round of asking. When she posts the deposit payment to the Xero invoice, ticks the Deposit Collected checkbox on the event — automation handles flipping Status Tentative → Firm for Risk-Gate events. Owns the Events with Deposit Required scorecard. |
| General Manager | Receives notifications of deposit exemptions. Decides hold/extend/cancel/reclassify on day-5 escalations. |
| Finance & Admin Manager | Reconciles deposit payments in Xero. Flags refund requests for Sales Manager review. |
Related Articles
- Scorecard: Events with Deposit Required
- How-to: Accounts Receivable Processing Guide
- Sales Scorecard — All Items Reference
💡
If you have any questions about whether a specific event should be Firm or Tentative, or whether to ask for a deposit at all, stop and ask the Sales Manager. A two-minute conversation about a borderline quote prevents either a damaged relationship with a long-trust client or wasted planning hours on a speculative one.