Skip to content

Booking status, postponement and cancellation

A CRM contact stage, a vendor’s commitment, a wedding’s status, and an invoice’s payment status describe different things. Check the booking and invoice together before promising a date is secured.

What you see What still needs to happen
Booking requested Review the details and any outstanding vendor acceptance
Vendor acceptance pending The vendor must respond to the request
Booking fee pending The booking fee must be recorded as paid
Confirmed The booking has met its confirmation requirements
Date change pending Review the proposed replacement dates and any required amendment
Declined or cancelled Do not treat the request as an active confirmed commitment

A public booking form records the details, accepted agreement, and payment schedule first. Its booking fee must be paid through Stripe or recorded by the vendor before confirmation and calendar creation. A form-submission email is not proof of payment.

When adding an existing booking manually or importing it, record its actual status. This records business history; it does not take a payment or complete an unsigned agreement for you.

A member with wedding-management permission can open the wedding’s edit form and use its Status control. Business access follows that business’s wedding permissions; it does not give someone authority over every wedding on the platform.

Before changing status, check the selected wedding, its linked contact, and invoices. Save the change, then check the updated workspace and calendar.

Use Postponed when the wedding is delayed and a replacement date has not been settled. Review outstanding payments, reminders, and appointments with the couple. Postponement does not arrange a new date with each vendor.

When replacement dates are known, use the date-change workflow. A date awaiting vendor approval should not be treated as a newly confirmed date.

Choose Cancelled and record the reason and any useful note. The cancellation lifecycle updates the wedding’s operational state and can notify the wedding team. Check linked calendar entries and pending work after saving, and contact anyone who needs a direct explanation.

Cancelling a wedding does not issue a Stripe refund or return a manual payment. Handle refunds through the original payment provider and tell the couple what you have done. Existing invoices and accepted agreements remain records of the booking.

After the final booking day ends in the venue’s timezone, an unfinished wedding moves to After wedding on the dashboard and wedding list. Finish follow-up tasks there, then mark it completed. This is a view of ongoing work, not automatic completion, payment settlement or cancellation. Postponed bookings awaiting a date stay separate.

Use Completed when the booking has finished. Keep any outstanding delivery work or final payments recorded separately; marking a wedding completed is not evidence that every invoice is paid. A completed wedding can only stay completed or move to cancelled, so check before saving this status.

Past, completed, postponed, and cancelled bookings remain findable through the dashboard’s booking search. Use data export if you need a portable reference copy.

Archiving a CRM contact keeps it outside the active pipeline. It is different from cancelling a shared wedding.

Some older standalone weddings without a linked contact offer an archive action. That first puts the wedding through cancellation. Permanent deletion is a separate confirmed action and is available only to the creating business when the archived wedding is isolated: no linked contact, invoice, contract, or other active member. It is not a general way to delete a wedding’s shared history.

If you chose the wrong status, reopen the edit screen and review the available controls. Reinstating a status does not automatically settle an invoice or replace a vendor agreement. For a stuck request, see Troubleshooting.