Marina CRM: What a Berth-Holder and Guest Record Should Hold

A marina CRM record has to hold four things a generic contact list cannot: the vessel with its real dimensions, the agreement the customer is on, the documents that expire, and the history of what was charged and communicated. Get those four right and allocation, billing, renewals and reporting all read from the same place. Get them wrong and the office spends the season cross-referencing a spreadsheet, an inbox and a filing cabinet to answer questions that should take seconds. This guide sets out what each record should contain and why each field earns its place.

Key Takeaways

• The customer and the vessel work best as two linked records that point at each other.

• Length, beam and draft belong in structured fields, because allocation depends on filtering them.

• The agreement type decides how someone is billed, so it belongs on the record itself.

• Documents that expire need an expiry date the system can act on.

• Contacts are plural: owner, skipper, crew and an emergency contact are different people.

• Charge and communication history is what lets you answer a dispute without reconstruction.

• Consent and contact preferences belong in the record rather than in someone's memory.

• Access controls decide who can see and change what, which matters once the team grows.

The customer and the vessel are two records that point at each other

The most common structural mistake is holding everything on one entry. Boats change hands, owners buy a bigger boat, a berth holder keeps the berth and arrives in a different vessel, and a charter company owns twenty boats between them. When the vessel lives inside the customer entry, every one of those events forces someone to overwrite history.

Two linked records solve it. The customer record holds who is responsible for payment and communication. The vessel record holds the boat itself, with its own identity and history, linked to whoever currently holds it. A berth then references the vessel, and billing references the customer, which is exactly how the operation actually works.

Vessel dimensions belong in structured fields the system can filter and match on

Length overall, beam and draft decide which berths a boat can safely take, so they have to be structured fields the system can filter and match on. Written into a free-text note they are invisible to allocation and useless for answering a question at scale, such as which arrivals next weekend need a berth over fifteen metres.

Alongside the dimensions, the record should carry the name, registration or flag, boat type, and where relevant the draft at loaded condition, since that is the figure that matters on a shallow berth. How those fields feed allocation is covered in the guide to automating berth allocation.

The agreement type on the record decides how someone gets billed

A marina bills several kinds of customer from the same system, and the record has to say which kind each one is. An annual berth holder on a contract with a renewal date behaves differently from a seasonal holder, a monthly account, a visiting boat paying on departure, or a charter company invoiced in arrears.

Holding the agreement type, its start and end dates, the rate applied and the renewal terms on the customer record means billing is generated rather than remembered. It also means a renewal can be flagged before it lapses rather than discovered afterwards. The billing mechanics behind this are in the guide to eliminating manual billing.

Documents with expiry dates need a field the system can act on

Insurance certificates, registration papers, safety documents and, where you require them, proof of ownership all expire. A copy filed in a folder is a record; an expiry date attached to that copy is a control. The difference shows up when an insurance certificate lapsed in March and nobody noticed until an incident in August.

Store the document against the vessel or the customer as appropriate, with its expiry date, and let the system surface what is about to lapse. That single field turns a filing habit into something the office can manage in advance rather than audit afterwards.

Contacts are plural, because the owner is often not the person on the boat

A single contact field fails the first time a skipper arrives without the owner. A usable record distinguishes the owner or account holder, the skipper or regular user, any crew contact, and an emergency contact, each with their own phone and email.

It should also record which of them receives what. Invoices go to the account holder, arrival information goes to whoever is bringing the boat, and an emergency contact is used once and has to be right. Keeping these apart is what stops a berth invoice reaching a skipper who cannot pay it and an arrival message reaching an owner who is not coming.

Charge and communication history is what lets you answer a dispute in seconds

The record should show what this customer has been charged, what they paid, what was corrected and what was sent to them, in one timeline. That history is the difference between answering a query immediately and rebuilding the answer from three systems while the customer waits.

It also changes how the office handles a difficult conversation. A berth holder who disputes a power charge is easier to satisfy when the reading, the rate, the invoice and the reminder that was sent are all visible on their record with dates attached.

Consent and contact preferences belong on the record, not in someone's memory

If you send anything beyond operational messages, the record needs to hold what each customer has agreed to receive and when that was captured. Operational communication about their own booking is a different category from a newsletter or an offer, and the record should distinguish them.

The practical benefit is that the office stops guessing. The person sending a seasonal offer can see who is in scope without asking anyone, and a customer who asks to be removed from marketing stays removed after the person who took the call has gone home. Confirm the specific requirements for your own jurisdiction with your own adviser rather than from a general guide.

Access controls decide who can see and change each record

Once more than two people use the system, the question of who can do what becomes real. A seasonal dock hand needs to see arrivals and record a charge. The office needs to raise invoices and issue credits. Someone has to be able to change a contract rate, and it should not be everybody.

Roles with defined permissions handle this, and they also produce something useful afterwards, because each change carries a user against it. That record of who did what is what makes a reconciliation defensible, which is covered further in the guide to mooring revenue that survives an audit.

Audit your current records against this list before you migrate anything

Take fifty of your existing customer entries and check them against the eight areas above. Most marinas find the same gaps: dimensions in notes rather than fields, one contact where there should be three, expiry dates missing entirely, and no link between the customer and the boat currently in their berth. Fixing that before a migration is far cheaper than discovering it afterwards.

To see what a connected record looks like against your own customers and vessels, book a demo and bring a sample of your current list. The wider evaluation framework is in the buyer's guide for harbour masters.

Frequently Asked Questions

1. What fields should a marina customer record contain?

Contact details for the owner, skipper and an emergency contact, the agreement type with its dates and rate, a link to the vessel or vessels, charge and payment history, communication history, stored documents with expiry dates, and contact preferences. The test for any field is whether the office currently has to look somewhere else to answer a routine question about that customer.

2. Why should the vessel be a separate record from the customer?

Because boats and owners change independently. A berth holder replaces a boat, a boat is sold to another customer, and a charter company holds many vessels at once. Two linked records let each keep its own history, so selling a boat does not erase what happened at your marina while it was there.

3. Can we keep vessel dimensions in a notes field?

You can store them there, and they will not do any work for you. Allocation, availability searches and reporting all need length, beam and draft as structured fields to match a boat against a berth that fits. Dimensions in free text cannot be filtered, so the matching stays manual and the mistakes stay possible.

4. How should a marina CRM handle insurance and registration documents?

Store the document against the vessel or customer with an expiry date recorded as its own field, so the system can surface what is about to lapse rather than relying on someone to check the folder. Decide which documents you actually require, since every extra one is something the office then has to chase.

5. What is the difference between a marina CRM and membership software?

A marina CRM holds the customer, vessel, agreement and history that daily operations read from, while membership software focuses on dues, renewals and member communication. A club or member-based marina needs both to connect, which is covered in the guide to member management software.

6. How many contacts should a berth-holder record hold?

At least three: the account holder who receives invoices, the skipper or regular user who receives arrival information, and an emergency contact. Record which channel each prefers, because sending a berth invoice to a skipper who cannot pay it and an arrival message to an owner who is not coming both waste the office's time.