Superintelligence Prep for Marinas: Slip Waitlists and Service Bookings

An AI agent for a marina can answer the questions boat owners ask most, such as where they stand on a slip waitlist or whether an engine service is booked, but only when the marina's records hold the facts behind those answers. The practical starting point is not the chat window. It is the waitlist and the service booking data, captured with clear states, timestamps and owners, so the agent reports what the marina knows and hands off what it does not.

Key takeaways

• Status answers are only as accurate as the states behind them. Define each waitlist and booking state before connecting any agent.
• Capture the vessel facts that decide eligibility, such as length, beam, draft and requested slip class, in one linked record instead of in side notes.
• Give every change a timestamp and a responsible person, so the agent can say when a status moved and who moved it.
• Set approval boundaries: the agent may report and prepare, while staff confirm offers, berth releases, ranking changes and price exceptions.
• Review permissions and the agent's answer logs on a schedule, because marina rules, staff and booking tools change over time.

Why status questions come first

Boat owners rarely ask for a service in the abstract. They ask where they are. Questions like 'Am I next for a slip in the north basin?' or 'Has the rigging inspection been scheduled?' arrive by phone, text, email and the marina's website, often outside office hours. Each one pulls a staff member away from the dock or the yard, and each wrong or vague answer creates a second call. An agent is well suited to the repetitive part of this work, but only if it reads from the same facts the office would give.

This is where many marinas get stuck, and the cause is rarely the software. Waitlists live in a binder, a spreadsheet and the memory of whoever answers the phone. Service bookings live on a whiteboard, in text messages and on the mechanic's paperwork. An agent connected to any one of those sources will produce confident answers that are sometimes out of date. Before adding an agent, the marina needs one place where status is written down in a consistent form, and a short list of questions the agent is expected to answer from that place.

What to capture in a slip waitlist

A useful waitlist record is more than a name and a date. For each applicant, capture the following:

• The owner and the vessel as separate records, linked so one owner can hold more than one boat.
• Length, beam and draft, measured the way the marina measures them, with the unit stated on the record.
• The slip class or berth type requested, and whether the owner accepts an alternative or a different dock.
• The date the application was received and the ranking rule that applies to it, such as first come, first served within a category, or a priority category the marina defines.
• Offer history: each offer made, its date, the owner's response and the reason for any decline or deferral.
• Hold or pause periods, with start and end dates and the staff member who approved them.
• The contact preference and the named person authorized to accept an offer on the owner's behalf.

The ranking rule deserves particular care. If the marina ranks applicants by application date within a category, the agent must be able to explain both the category and the date it used. If part of the ranking depends on staff judgment, write that down as a rule staff apply, and make sure the agent does not present the position as purely mechanical. An owner who is told a position is final, and later learns it was changed without explanation, will remember that exchange longer than the wait itself.

Owner contact details and vessel registration information are personal data in most jurisdictions. Limit what the agent can see to what it needs to answer a status question. A waitlist position does not require the owner's full address, payment history or identity documents, and the agent should not have access to them.

How to model service bookings so status stays accurate

Service work moves through more stages than a booking calendar displays. A model that works for many marinas uses these states: requested, quoted, approved, scheduled, in progress, waiting on parts or a third party, complete, and invoiced. Each state should have one owner and one timestamp. Most bad status answers come from two patterns: a booking marked scheduled with no date attached, and a booking marked in progress for a long stretch with no note explaining why.

Keep the vessel and the work order as separate records. A single boat can have an annual inspection, a bottom job and a winterization in the same year, and each carries its own history. The agent should be able to say which work order it means, and it should not have to guess from the most recent message in the thread. When a part is on order, record it as its own status with the supplier's promised date, and clear that status the moment the part arrives, even if the job has not yet started. That single habit prevents many follow-up calls.

For each work order, decide in advance which updates staff must log and which the agent may summarize. A short written standard, one page long, is usually enough. It should name the states, the required fields for each state, and the person responsible for keeping the record current on a working day.

If the record has no confirmed date, the agent should say so and hand the question to the office.

Decide what the agent may say and what staff must confirm

Accuracy depends on approval boundaries as much as on data. A practical decision guide sorts every possible action into one of three groups.

• The agent may report facts already recorded: a waitlist position with its ranking basis, a booking state, the date of the last update, and who made it.
• The agent may prepare but not commit: draft a quote request, propose open dates from the calendar, or assemble an offer for a staff member to send.
• Staff must confirm: accepting an owner into a slip, releasing a berth, changing a ranking, approving a price exception, or telling an owner that work is complete and ready for pickup.

When the agent cannot answer from the records, the correct behavior is a clear handoff with the question logged, not a best guess. Write that behavior into the agent's instructions as the default, so it does not depend on how a particular message is phrased. The agent should also avoid giving an owner a date that the yard has not agreed to, even when the calendar appears to have an opening, because the calendar may not reflect a lift, a crew or a part that is still on the way.

Illustrative scenario and what it shows

Illustrative scenario: an owner texts to ask whether a haul-out for bottom work is booked. The record shows the work order as approved but not scheduled, with a note that the yard is waiting for a lift slot. The agent replies with the approved status, the note, and the fact that no date is confirmed. It then creates a staff task with the owner's question and the vessel details, so the yard lead sees it at the next check. On a later message, the owner asks again. The agent can point to the logged question and the staff update rather than starting the conversation over, and it still does not choose a date. The exchange works because the marina decided in advance what the agent is allowed to say.

Keep the records trustworthy after launch

Launch is the beginning of the work, not the end. Log each status answer with the record it used, the time it was given, and whether a staff member later corrected it. The OpenTelemetry observability primer describes the basic vocabulary of traces, metrics and logs, which is a useful reference when deciding what to record. Limit access to the minimum each function needs: the agent reads the waitlist and bookings, creates staff tasks, and does not write to ranking fields. The OWASP authorization guidance offers a practical checklist for deciding who and what can view and change each record. The NIST AI Risk Management Framework helps structure the question of how much human review each action needs, based on its consequences for the owner and the marina.

Be Human designs the marina's agent around one useful role, usually a status and intake role for waitlists and service bookings. The design defines the memory and tools that role needs, the approval boundaries described above, and the success criterion, such as a correct status answer or a complete staff handoff. Under managed operations, Be Human monitors the agent's answers, runs recurring evaluations against a fixed set of real owner questions, maintains the integrations when the booking tool changes, reviews permissions on a schedule, responds to incidents, and makes controlled improvements when a status category needs a new rule. The marina keeps control of its identity, records and operating context throughout.

The same pattern applies outside marinas. A golf course's tee sheet and member records raise the same questions about ranking and holds, and the approach is described in the golf course guide. A business that manages vehicles, returns and damage history faces a similar split between facts the agent may report and decisions staff must make, as covered in the car rental guide.

Where to start this month

Start with the status questions, not the full system. A sensible first sequence looks like this:

• List the twenty or so questions owners ask most often by phone, text and email, and mark which ones concern waitlist position or booking status.
• Write the states and ranking rules for the waitlist and for service work, and get the office and yard leads to agree on them in writing.
• Clean the records for the open waitlist entries and the current work orders, adding missing timestamps, owners and dates.
• Define the three groups of allowed actions, and the exact wording the agent should use when it hands off.
• Run the agent against a set of past owner questions, check each answer against the record, and fix the rules where it fails before it talks to an owner.

If you want to find the first task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI agent tell a boat owner their exact place on the slip waitlist? It can, provided the waitlist record holds the ranking rule, the application date and every offer made. The agent should state the position as the record shows it and say when the list was last updated. If staff apply judgment to ranking, the agent should say that changes are confirmed by the office rather than presenting the position as final.

Does the agent need a direct connection to our booking software? Not necessarily at the start. Many marinas first give the agent a structured, current copy of the waitlist and work order data, then connect live systems once the states and fields are agreed. Any live connection should be read-only for statuses and limited to creating staff tasks, with access reviewed on a schedule.

What should happen when the agent cannot find a booking? The agent should say it cannot confirm the booking, avoid inventing a date, and create a staff task containing the owner's question and the vessel details. Staff then answer, and the answer is logged so the next question about the same vessel gets a better reply. Over time, the logged questions show which records need clearer fields.

Is this only useful for large marinas with many slips? No. Smaller marinas often feel the same pressure during peak months, when the same few questions repeat across phone, text and email and the people who know the answers are busy on the dock. The first task is usually the status answer, and it can be handled with a short list of states and a clean waitlist.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.