Inside a Bohaus Sprint: A Marina

The situation

The client is an owner-led marina with wet slips, dry stack storage, a service department and a small ship store. The owner runs the business and is often on the dock. There is a dockmaster, a service manager, a few mechanics, seasonal dockhands, and an office person who handles billing. Slips, contracts and invoicing run through marina software such as Dockwa, Molo, DockMaster or similar, or through spreadsheets.

Launch requests come by phone, by text and in passing at the fuel dock. They go on a whiteboard in the dock office. Service tickets live on paper or in the service manager's notes. Boat owners call to ask whether their boat is ready, whether the part arrived, when it can go in. The slip waitlist is a spreadsheet only the office person understands.

Every spring, new dockhands start, and the whiteboard becomes the training.

What the sprint finds

In Discover, we spend a weekend morning in the dock office and a weekday with the service manager.

The work itself is clear. The knowledge sits with two or three people. Launch requests, service status and the waitlist all concern the same customers and the same boats, but they live in different places. When the dockmaster is out, launches slow down.

Bringing in outside help here carries a risk the owner names on day one: a system only the consultant understands is no better than a whiteboard only the dockmaster understands. So the hand over is planned from the start. The dockmaster and the service manager are named as system owners in the first week and work alongside us through the build.

In Diagnose, self-serve launch requests and service status texts rank first. The slip waitlist moves to the roadmap.

What it builds

In Build, we set up launch requests and service updates inside the marina's existing software, or in a connected booking tool where the software lacks the feature.

Boat owners request a launch or a haul-out from their phone by choosing a time window. Requests land in one queue for the dockmaster, who confirms or adjusts. Dockhands see the day's launch list on a tablet, in order. Customers get a text when the boat is in the water and ready.

Service tickets are entered once. When a ticket changes status, such as waiting on parts, in progress or ready, the customer gets a text automatically. Estimates and approvals go out by link instead of phone tag.

Hand over

In Hand over, the dockmaster and the service manager, who helped build it, take full ownership. They learn how to change time windows, message wording and status steps without us. Dockhands get a short session on the tablet, and the playbook doubles as spring training for new seasonal staff.

The owner gets a dashboard of launch requests, service tickets by status and customer messages, plus a 30/60/90-day roadmap. Ongoing support is available, but the marina does not need it to keep the system running.

What changes

The whiteboard retires. Boat owners request launches without calling. Fewer is-my-boat-ready calls reach the service desk. New dockhands learn from a playbook and a screen instead of shadowing someone for a season. When the dockmaster takes a day off, boats still go in on time.

The marina owns its system, and the people who run it helped build it.

What this means for your business

When you bring in help, decide who will own the system on the first day, not the last.

For a marina, that is the dockmaster and the service manager. For a self-storage operator, the site managers. For a pool company, the office lead.

That is a Bohaus Sprint: six weeks, fixed scope, four phases (Discover, Diagnose, Build, Hand over), and one live system inside the tools you already use, with a trained team, a playbook, a dashboard and a 30/60/90-day roadmap.