The Customer Portal — Letting Customers Self-Serve

Most of the calls that interrupt your day aren't real problems — they're customers asking for things they could get themselves. "Can you resend my receipt?" "What did I owe again?" "Can you update the card on file?" "When was my last service?" Every one of those is a two-minute interruption that adds up to hours a week.

The Customer Portal is a branded, self-service website your customers sign into to answer those questions on their own. They can see their receipts, pay an invoice you've locked, keep a card on file for next time, and look back at their job/contract/reservation history — without a phone call and without a password to forget.

This article is about turning it on, deciding what to expose, and getting it in front of customers. It's written for the staff member setting it up, not the customer using it.

What your customers can do

Once you enable it, a signed-in customer sees a small set of tabs (only the ones that apply to them):

Home — a "needs your attention" dashboard that surfaces anything outstanding (starting with missing, rejected, or expired required documents), so a customer sees what to fix the moment they sign in.
My Profile — their contact details. You control which fields they can edit (more on this below).
Messages — notices you send them (marina announcements, account alerts). Appears only when they have a message; unread ones are flagged and counted.
Support — open a ticket, follow the conversation, and reply. This is how customers message you; see Running a help desk with tickets.
My Reservations — the stay they're on right now, everything they have booked, and every stay they've had before. Read-only. Only appears when the account actually has a reservation.
Surveys — questionnaires you publish for customers to complete. Only appears when a customer has a survey available to them.
Waitlist — for marinas/campgrounds: the lists a patron is already on (with their live position), and any lists you've opened to the portal that they can join.
My Boats — the assets (boats, RVs, trailers — whatever you rent slips or sites to) that belong to their account, which they can review and, if you allow it, edit.
Documents — the documents their assets require (registration, proof of insurance, and so on): upload, track approval status, and see past versions.
Contracts — contracts still waiting for their signature (a job work authorization, a service agreement, a reservation agreement), plus a Signed Contracts list of the copies they've already signed. Only appears when they have at least one of either.
Invoices & Receipts — receipts for anything paid or closed, and — if you allow it — a way to pay invoices you've finalized.
Payment Methods — cards saved on file (only if you take card payments and leave the section on).
AutoPay — for customers with an automatic recurring charge (a monthly slip fee, a subscription), a place to choose which saved card that charge uses. Only appears when they actually have such an arrangement.
History — their past jobs and contracts, read-only. (Reservations have their own tab.)

They can't see anything you haven't finalized, they can't see other people's accounts, and they never touch your staff system. The portal is a completely separate front door. The My Boats and Documents tabs only appear for customers who actually own assets — a service customer with no reservations assets never sees them.

Turning it on

The portal is off until you enable it. You'll find the Customer Portal page under Online & Waitlist in the left sidebar. It only appears if your role has the Manage Customer Portal permission — if you don't see it, ask whoever manages users to grant that permission (it's the same permission that protects every setting described here).

On that page, flip Enabled on and save. Nothing is public until you do. Everything below is configured on the same page.

Registration — do you let strangers in?

There's a registration toggle that decides what happens when someone enters an email you've never seen before:

Off (recommended for most): only people already in your system can sign in. An unknown email gets a polite "check your inbox" message and nothing happens. This is the safe default — nobody creates an account you didn't intend.
On: an unknown email can confirm itself and then fill out a short form (name, phone, address). That creates a brand-new residential account in your system, exactly as if they'd walked in the door — plus a notification so your staff knows a new customer self-registered.

Turn registration on only if you actively want the public to be able to create accounts — for example, a campground that wants first-time guests to self-onboard. If you're a service company whose customers all already exist in your books, leave it off.

Profile locks — why name and email are locked by default

Under the profile settings you'll see locks for name, email, phone, and address. Name and email are locked by default, and you should almost always leave them that way.

Here's the reasoning. A customer's login is their verified email, and the account is matched to that email. If you let a customer freely change the name or the email on the account, you've handed them a way to quietly turn your record for "Jane Smith" into a record for someone else entirely — an account handoff. Phone and address are safe to unlock (customers move, numbers change, and it saves you data-entry). Name and email are identity, so they stay locked; if a customer genuinely needs a name or email change, they contact you and you make it — with a full audit trail.

(There is a built-in, safe way for a customer to change their own login email: the portal emails a confirmation code to the new address and only switches once they prove they control it. That's separate from the profile lock and always available.)

Showing invoices — and the one rule that trips people up

By default the portal shows customers their receipts: anything paid or closed. That's low-risk and universally useful.

The "allow customers to pay locked invoices" toggle goes one step further: when it's on, a customer can also see and pay an invoice you've locked but not yet paid. Turn this on if you want customers paying their own balances online — it's the single biggest phone-call saver in the portal.

Reservation charges are labeled with the reservation they belong to, and a customer running a marina/campground can filter the list to just those and pay them ahead of the due date — a guest who wants to pre-pay next month's slip fee can, as long as the charge has been turned into a locked invoice. (Paying an arbitrary advance amount before an invoice exists is a separate, planned capability — every payment still becomes a real invoice.)

The rule that surprises people: open, unlocked invoices are never shown to the customer — ever, regardless of this toggle. An invoice you're still building, still editing line items on, still deciding about, is invisible in the portal until you lock it. This is deliberate and mirrors how the emailed-invoice link works: nothing half-finished is public. If a customer says "I can't see my invoice," the answer is almost always that it hasn't been locked yet.

Letting customers manage their boats

If you run a marina, campground, or RV park, the assets your customers own — their boats, RVs, trailers — are already in your system, attached to their reservations. The portal can show each customer the assets on their account so they can keep the details current instead of calling you to say "actually the new engine is a 250, not a 225."

Two toggles under Assets & documents on the Customer Portal page control this:

Show the My Boats / Assets section — whether customers see their assets at all. It only ever appears for customers who actually own assets, so turning it on costs a service-only customer nothing.
Let customers edit their asset details — whether the fields are editable or read-only. Leave editing on if you'd rather customers keep their own specs accurate; turn it off if you want the data to be staff-maintained and view-only.

Edits apply immediately, but nothing is ever lost. Every change a customer makes is saved right away and the previous value is written to an audit trail. If a customer "corrects" their boat length from 32 ft to 12 ft to dodge a per-foot slip fee, you still have the original value, who changed it, and when — you can see the whole history on the asset in your staff system and put it back. That's the safety net that makes it reasonable to let customers edit at all.

Required documents — self-service upload into your existing approval queue

Marinas live and die by paperwork: current registration, proof of insurance, sometimes a signed liability waiver. The portal lets a customer upload those documents themselves, and — this is the important part — the uploads land in the same approval queue your staff already use. Nothing new to check; a customer upload shows up right beside a staff upload in the document approval screen, flagged as a customer upload.

Here's how it fits together:

You define which documents each asset type requires (for example, every "Boat" needs a Registration and Proof of Insurance). That's the same required-documents setup you already use on the reservation screen.
A customer opens the Documents tab and sees each required document for each of their boats, with a clear status: Missing, Awaiting approval, Approved, Rejected, or Expired.
They upload a file. If that document type is set to require approval, it goes into your approval queue as Awaiting approval; if not, it's live immediately.
Your staff approve or reject it in the usual place. Rejecting now records a real "rejected" status with your reason — which the customer sees on their end ("Not accepted: illegible, please re-scan") so they know to try again, instead of the rejection silently disappearing.

A few things worth knowing:

Only document types you've marked as customer-uploadable show an upload button. If a document is staff-only (say, an internal inspection report), the customer sees the requirement's status but can't upload against it.
Every version is kept. When a customer replaces an expired insurance certificate, the old one isn't deleted — it's superseded, and both you and the customer can open the full version history for that document.
Documents follow the boat, not the reservation. A registration uploaded for a boat satisfies that requirement on every reservation that boat is on — the customer doesn't have to re-upload it each season. The Home dashboard still nudges them when a document a current reservation needs is missing.

Sending messages to customers

The portal has a built-in message inbox, so you can push a notice to customers instead of blasting an email that lands in spam. You compose these on the Portal Notifications page (in the sidebar next to Customer Portal), not on the portal itself.

Each notice goes to one account or to all portal customers (a broadcast — useful for "the fuel dock is closed this weekend" or "rates change January 1"). A customer sees it in their Messages tab the next time they sign in; unread notices are flagged and counted, and a broadcast is tracked as read separately for each account, so the read count on your end tells you how many customers have actually seen it.

Good uses for this:

Operational alerts — closures, storm prep, hours changes. Broadcast, styled as an "Alert."
Account-specific nudges — "your insurance expires next month," aimed at one account.
Good news — "your slip is ready," styled accordingly.

It's a one-way channel today: you send, they read. If you need a customer to reply, point them at your phone or email in the message body for now.

To remove a notice, delete it from the Portal Notifications list — it disappears from customers' inboxes immediately.

Letting customers message you back

Customers message you through the Support section — a real ticket with a status, an owner, a due date and a full audit trail. Enable it under Support on the Customer Portal page, then control which categories customers may submit into (and whether they can set a priority or mark a ticket resolved) per category under Ticketing. See Running a help desk with tickets.

There used to be a lightweight Contact Us form that dropped notes into a staff Inbox page. That was always a placeholder for ticketing, and it's gone — along with the Inbox page and its two permissions. If you were relying on it, turn Support on; it does the same job and doesn't lose track of anything. Any messages already in the old Inbox are still in your database, but there's no longer a screen for them, so deal with anything outstanding before you upgrade.

Waitlists in the portal

If you run waitlists (slips, campsites, storage), the portal lets patrons manage their own place in line instead of calling to ask "where am I on the list?"

Two things show up for a customer:

The lists they're already on — with their current position and status. This shows regardless of any setting — someone you added to a list by hand still sees it. If they owe an application fee, the portal tells them to pay it under Invoices & Receipts.
Lists they can join — only the lists you've explicitly offered on the customer portal. That's a per-list switch on each waitlist's builder page, off by default, so a list is never public by accident.

When a patron taps Join, the portal hands them straight to your standard waitlist sign-up form — the very same one the public uses — where they pick their preferences and complete any extra steps (like adding their boat). Because they're already signed in, they skip the usual email-verification step and their contact details are pre-filled, and a Return to your portal link brings them back when they're done. This means there's only ever one sign-up form to maintain, and every kind of list is joinable the same way.

On that same builder page you can set an application fee. That fee becomes a normal invoice paid online — same card/bank flow as any other invoice, through whichever processor you use. If you allow portal customers to pay locked invoices, they can settle it right inside the portal with a saved card; otherwise the confirmation page links them to your standard pay page. Their spot is confirmed once it's paid.

A few things to know:

Joining respects your per-list entry limit. If a list caps entries per person, the portal enforces it — a patron at the limit is told to contact you rather than piling on duplicate applications.
Joining briefly leaves the portal tabs. The sign-up form is your normal public registration page, so it looks a little different from the portal shell — that's expected. The Return to your portal button at the end (and after paying) brings them back.
Every kind of list works, including "separate entry per preference." Those multi-queue lists used to be website-only; now they join through the portal too, because the portal hands off to the full sign-up form rather than trying to shortcut it.
Contact info updates live here too. A patron can update their name, phone, and address from the Waitlist tab (subject to the same field locks as their profile), so your waitlist contact details stay current without a phone call.

Surveys — asking customers what they think

The portal has a built-in survey tool, so you can gather structured feedback — a post-season satisfaction survey, a "what amenities do you want next year" poll — without a third-party form service. You build surveys on the Portal Surveys page (in the sidebar); customers fill them out in the portal's Surveys tab.

The workflow:

Create a survey, give it a title, and choose the audience — everyone, or one specific account.
Add questions. Each question has a type: short text, paragraph, single choice, multiple choice, dropdown, a 1–5 rating, or yes/no. Mark the ones that are required.
Publish it. A survey sits in draft (invisible to customers) until you publish it; you can close it later to stop collecting responses without deleting the data. A survey needs at least one question before it'll publish.
Read the results on the same page — every response, with each customer's answers, and a link back to their account.

A couple of judgment calls:

Keep it short. Response rates fall off a cliff after a handful of questions. Ask what you'll actually act on.
"Allow multiple submissions" is usually wrong. Leave it off so each account can answer once — that keeps your results clean. Turn it on only for something like a recurring "rate today's service" prompt.
Surveys aren't anonymous. Each response is tied to the account that submitted it. That's a feature (you can follow up), but don't promise anonymity you can't deliver.

Signing contracts online

If you use e-signatures, the portal closes the loop: a customer can sign anything still waiting on their signature — a job's work authorization, a service agreement, a reservation agreement — without you having to email each one separately. The Contracts tab lists everything outstanding, and below it a Signed Contracts list of everything they've already signed. The tab appears only when they have at least one of the two, so it's not clutter for a customer with no paperwork at all.

Under the hood it uses the exact same signing page as your emailed signature links, so a signature captured in the portal is identical to one captured any other way — same record, same place in the contract. The difference is convenience: the customer signs several documents in one sitting instead of hunting through their inbox. The signer's IP address is now recorded at signing, which strengthens the record if a signature is ever disputed.

Opening an already-signed contract shows it read-only — the full agreement exactly as they signed it, with their signature and the date on the bottom. That means a customer can answer "what did I actually agree to?" themselves, at 9pm, without calling your office. It also means the signature can't be re-drawn or the contract re-submitted once it's signed; the document is locked.

You control this with the Show the "Documents to Sign" section toggle under E-signatures on the Customer Portal page. There's nothing else to configure — whatever you already mark as needing a signature simply shows up for the customer.

Amount due and AutoPay

Two more financial toggles live under Balance & AutoPay on the Customer Portal page.

Show the customer's account balance puts an Amount due figure on the portal home. It's read-only — a number, not a payment button. Its job is to answer "what do I owe?" without a phone call. They still pay through the Invoices section (which is where the actual, itemized, payable invoices live). Leave this on unless you have a reason to hide balances — a customer seeing "$0.00, all paid up" is one fewer call.

The number is the total still outstanding across the invoices that customer can see in their portal, so it always reconciles with the Invoices & Receipts list right below it. If the figure looks lower than you expect, the difference is almost always an invoice you haven't locked yet — unlocked invoices aren't shown to customers at all, so they can't be counted here either.

Show the AutoPay section is for customers who are on an automatic recurring charge — a monthly slip fee that settles to a card on file, or a recurring subscription invoice. The section does exactly one thing: it lets the customer choose which of their saved cards that recurring charge should use. A customer whose card is expiring can move their monthly billing to a new card themselves, at 11pm, without calling you — which is the single most common "please update my card" request a marina gets.

What it deliberately does not do:

It doesn't let a customer turn AutoPay off. Cancelling automatic billing is a conversation, not a self-service toggle — so the portal only ever moves the charge to a different card, never removes it. If someone wants off AutoPay entirely, that still comes through you.
It only shows arrangements that already have a card. The AutoPay tab appears only for customers who are actually enrolled in a recurring charge; everyone else never sees it.
The change takes effect on the next charge. Swapping the card points future runs at the new card. An already-scheduled, in-flight charge for the current cycle isn't retroactively moved — so a card swap is a "from now on" change, which is what customers expect.

Branding

The portal should look like your business, not ours. You can set:

Display name — the heading customers see (falls back to your company name if you leave it blank).
Accent color — the button and header color.
Welcome text — a line on the sign-in screen.
Intro text — a line on the portal home after they sign in.

Your logo comes automatically from your company settings — there's no separate logo upload here, so if the logo looks wrong, fix it in Company Settings.

Getting it in front of customers

Two ways to share it, and you can use both:

Hosted link. The portal lives at its own page you can link from anywhere — an email signature, a "Pay my bill" button, a receipt footer. Copy the link from the admin page.
Embed the widget on your own website. The admin page gives you a small paste-in snippet (a <div> and a <script> tag). Drop it into any page on your existing website and a compact "sign in" box appears right there. When a customer signs in through the embedded box, it hands them off to open the full portal in a new tab — so it works even on browsers that block third-party cookies.

How customers sign in (no passwords)

There are no passwords. A customer enters their email, and you send them a one-time 6-digit code and a matching magic-link button — both in the same email. They either click the button or type the code. That's it. The link and code expire in 15 minutes and only work once.

If one email is attached to more than one account — common with property managers, spouses, or a business owner who's also a personal customer — the customer gets an account picker and chooses which one to open. They can switch between them at any time without signing in again.

Saved cards — and the one thing customers can't remove themselves

If you take card payments and leave the payment-methods section on, customers can save a card and reuse it. They can also remove a card themselves.

The one exception: a card that's wired into a scheduled or retrying payment can't be self-removed. If a customer has a payment plan or an automatic charge pointed at a card and tries to delete it, the portal stops them and tells them to contact you. This is on purpose — silently deleting that card would make the scheduled charge fail later with no warning. Handle those removals yourself so you can move the schedule to another card first.

Reservations in the portal

If you rent slips, sites, or rooms, My Reservations is the tab your guests will open most. It shows their bookings in three groups, in the order a guest actually cares about:

Here now — the stay they're checked into, or a dated stay we're inside right now.
Booked — everything ahead of them, soonest first.
Previous stays — everything that's over, cancelled, or a no-show, newest first, 25 at a time.

The first two are never truncated: a guest always sees every current and upcoming booking at a glance. The Home dashboard repeats the current stay and the next three booked ones, so the answer to "which site am I on?" is on the first screen after sign-in.

Open-ended (indefinite) stays stay in Here now for as long as they're active, and anywhere an indefinite stay's end date would show, the portal displays "Indefinite" rather than the far-future placeholder date.

It's read-only. A guest can see the booking, not change it — cancellations and date changes still come through you.

Upgrading from an earlier version? Reservations used to live inside the History tab, and only past ones appeared there — a guest who was checked in couldn't find their own stay anywhere. That's what this tab fixes. Nothing changed in your reservation data; the customer's view of it did.

The History tab hides empty sections

The History tab shows Jobs and Contracts — but only the categories that customer actually has. A campground guest with no service jobs never sees an empty "Jobs" heading. This is by design, so don't go looking for a setting to turn those off — an empty category simply doesn't render. Reservations aren't here at all; they have their own tab.

Common mistakes

Portal is on but no payment features appear. The payment-methods and pay-invoice features require an active card processor. If your payment processor is set to "none," customers can still see receipts and history, but there's nothing to pay with and no card to save. Connect a processor first (Stripe or USIO), then the payment sections light up.
"I never got the email." Two usual causes. First, it's in spam — sign-in emails are transactional and sometimes get filtered, so tell customers to check. Second, there's a rate limit of three sign-in emails per email address every 15 minutes to stop abuse; a customer who mashes "resend" a few times will stop getting new emails until the window resets. Have them wait a few minutes, not keep clicking.
Expecting open invoices to show up. As covered above, only locked or closed invoices reach the portal. If you want a customer to be able to see or pay something, lock it. An in-progress invoice is invisible to them on purpose.
Picking an accent color nobody can read. You can set the accent to any color, but a very light color would normally make button text unreadable. The portal automatically flips the button text between white and near-black to keep it legible, so you won't create an invisible button — but a garish color still looks unprofessional. Pick something close to your brand and check it on the live portal.
"Customers can't upload their insurance." Two things have to be true: the document type has to be marked customer-uploadable, and it has to be a required document on that asset type. If a customer sees a document requirement with no upload button, it's set staff-only; if they don't see the requirement at all, it isn't attached to their boat's asset type yet. Fix it in the required-documents setup, not the portal.
Turning off asset editing to "lock down" the data, then fielding correction requests. Read-only assets mean every spec change comes back to you as a phone call. Because edits are fully audited and reversible, leaving editing on is usually the lower-effort choice — you get accurate data maintained by the people who know it best, and you can still catch and undo any bad change.
Expecting the balance number to be a "pay" button. The amount due on the home screen is informational. Customers pay specific, itemized invoices under Invoices & Receipts — that's deliberate, so a customer always pays against something rather than sending an unattributed lump sum. If a balance shows but nothing is payable, the charge hasn't been turned into a locked invoice yet.
Looking for Contact Us. It's gone — customer-to-office messages are Support tickets now. Turn the Support section on and the customer gets a better version of the same thing.
Assuming a card swap fixes a charge that already failed. AutoPay changes point future charges at the new card. If this month's charge already ran and declined, moving the card doesn't retry the failed one — you handle that failed charge the usual way. The swap prevents next month's failure.

Required documents per asset type
Document approvals
(Once "Connecting Stripe" is written, link to it here.)
Working with property managers and multi-account setups