Requesting documents from customers

Every new booking arrives half-finished. The slip is reserved, the deposit cleared, and now somebody has to get a certificate of insurance, a current vessel registration, and a signed liability waiver out of a customer who has already mentally moved on. That chase — three emails, three links, two phone calls, one spreadsheet — is where most of the administrative cost of a reservation actually lives.

The fix is to ask once, ask for everything, and give the customer a single place to answer. That's what this workflow does.

What "required documents" actually means here

Document requirements are attached to asset types, not to reservations. A 40-foot wet slip requires proof of insurance because slips require proof of insurance. A customer's boat requires a registration because boats do. Configure this once, on the asset type, under Reservations → Asset Types → Required Documents.

That has two consequences worth internalizing:

A reservation inherits requirements from every asset on it. Book a boat into a slip and you may inherit requirements from both.
Requirements follow the asset even when you own it. If your slips require the tenant's insurance certificate, that requirement lives on the slip — which you own — but it's the customer's document to provide. The system handles this correctly: customers can upload documents for company-owned assets on their reservations, but they can't edit those assets.

Asking: the three ways it happens

1. Automatically, when a booking is made

Turn on Automatically request required documents when a new booking is made on the reservation type (Reservations → Reservation Types → Required Documents).

From then on, every new booking of that type triggers one email to the customer covering everything they owe. If they owe nothing — a returning customer whose insurance is already current and approved — no email goes out. Silence is the correct behavior; don't email people to tell them they're done.

This is the setting most operations should turn on and forget about. The manual buttons below are for exceptions.

2. From the reservation

Open the reservation. Under Required Documents you'll see a summary bar — "3 documents outstanding — never requested" or "Requested 3 docs on 6/14" — and a Request Documents (3) button.

Click it and you get a preview of exactly what will be asked for and which address it's going to, before anything sends. Confirm, and one email goes out.

The count may be higher than what's on the reservation in front of you. That's intentional: the request covers everything that customer owes, including documents for their other boats and their other active reservations. Asking for four documents in one email is strictly better than asking for three now and one on Thursday.

3. From the Expiring Soon dashboard

For documents that already exist and are about to lapse. Same sender, same one-email-per-customer behavior. See Staying ahead of expiring documents.

What the customer receives

One email. It names each document, says which boat or site it's for, and says why you're asking — "has not been provided yet," "expires Aug 14," "was not accepted — please send a new copy."

If the customer portal is enabled, the email carries a single Upload your documents button. Clicking it signs the customer in and drops them directly on their Documents page, where every outstanding item has its own upload box. No password. No separate link per document. A banner at the top tells them how many things need their attention.

If the portal is off, the email lists each document with its own upload link to the classic no-login upload page. Still one email — just several links inside it.

Two things to know about the portal link:

It's a sign-in link. It grants that customer access to their whole portal — invoices, saved cards, the lot — for seven days, or until it's used once. The email tells them not to forward it. You should assume they might anyway, and treat it with the same care as any password reset link.
It only works for a customer whose email matches an account in your system. If the address on the reservation doesn't resolve, the system quietly falls back to the classic per-document upload links rather than emailing a link that goes nowhere.

What you get back

Uploads land in the same approval queue as everything else. If the document type requires approval, the new file sits as Awaiting approval until someone signs off; if it doesn't, it goes live immediately. See Document approvals.

On the reservation, each document slot shows its real state: Missing, Awaiting Approval, Approved, Expiring in N days, Expired, or Rejected. In the portal the customer sees exactly the same states, in the same words. When you reject something, they see the reason you typed — so type a useful one. "Policy expired" is useful. "No" is not.

When you'd use each

Turn on auto-request for reservation types where paperwork is the norm: seasonal slips, annual sites, anything with a lease.
Leave it off for transient one-night bookings where you'd be emailing a stranger about paperwork they don't owe.
Use the reservation button when a customer's situation changed mid-stay — they bought a new boat, or their carrier lapsed.
Use the Expiring Soon dashboard for the routine weekly sweep of documents you already hold.

Common mistakes

Configuring requirements on the reservation type. They live on the asset type. The reservation type only controls whether the ask is automatic. This trips up nearly everyone once.
Expecting one email per document. It used to work that way and it was awful. Clicking "Request Documents" on a customer's second reservation right after their first will correctly report that there's nothing left to ask for. Work by customer, not by row.
Turning on auto-request before configuring the asset types. You'll send a lot of nothing, or worse, nag customers for a document type you were still drafting. Set up the requirements, verify the states look right on an existing reservation, then flip the toggle.
Marking a document type "customer upload allowed" when it shouldn't be. Contracts you generate, inspection reports you write — these shouldn't be replaceable by the customer. Leave the flag off and those items appear in the email with a "please contact us" line instead of an upload box.
Not putting an email on the account. No email, no request, and the button will say so. It's worth a periodic sweep of accounts missing a primary contact email — they're invisible to every automated nudge in the system, not just this one.
Assuming the customer saw it. The email is queued and sent through your configured SMTP. If your outbound mail is landing in spam, none of this works. Send yourself a test request against a known-good address before you rely on it at scale.
Rejecting a document without a reason. The customer sees the reason field verbatim in their portal. A blank or curt rejection guarantees they upload the same wrong thing again.