Choosing software for a dock and lift company

Every dock company we have talked to has run the same three-step progression. A spreadsheet, then a general field-service tool because the spreadsheet stopped scaling, then the spreadsheet again alongside it — because the tool had nowhere to put the things the spreadsheet was actually for.

This is not a page about which product is better. It is a page about the shape of the software, because the shape is what decides whether the second spreadsheet appears.

The shape of a general field-service tool

Jobber, Housecall Pro, ServiceTitan, Service Fusion and everything in that category share one model, and it is a good model: a customer has a job, the job is assigned to a technician on a date at an address, the technician arrives, does it, and it is invoiced. Lawn care, HVAC, plumbing, pest control and cleaning all fit that shape, which is why the category is worth billions of dollars.

Put a dock season into it and three assumptions break at once.

The date is a guess, and everybody knows it

Ice-out moves three weeks year to year. You build a 340-row spring plan in March and by the second week of May it is fiction: half the lakes opened late, a north wind closed the exposed side of two of them, and about a third of your customers rang the week they actually arrived at the cabin. The plan is not wrong because you planned badly. It is wrong because the thing it is a plan about has not happened yet.

What you re-plan around is a calendar full of appointments that now all need moving, one at a time, with a customer notification attached to each one.

The address does not find the work

A geocoded lakeshore address lands on the road side of the lot. The dock is a hundred metres away through the trees, and the boat only ever arrives from the other side. A general tool has a field for an address and nowhere at all for "the second dock down from the green boathouse, and the lift stacks against the retaining wall, not the seawall."

The unit of work is not the visit

A property is not one thing. It is a sectional dock, a canopy, a boat lift, and a PWC port — four pieces, four different amounts of work, four different reasons one of them might not get done today. Marked as one visit that is either complete or not, the two you finished and the one that was frozen in are the same row, and every spring argument about what was actually billed starts there.

What the work actually needs

Three things, and none of them is a better calendar.

An inventory of the pieces, each pinned where it goes

Not "12 Lakeshore Drive." A dock, a lift and a canopy, each with a point in the water where it is installed and a point on shore where it stacks, each with its own dimensions and its own notes. That inventory is the asset register of the business and it is what a new crew member steers by on their first day. It also outlives the customer relationship: a lift that got sold still owns nine years of history.

Dispatch by zone, not by sequence

You do not send a boat to an appointment. You send it to a lake, with a set of zones and a set of services it can do with the gear aboard, and it takes whatever is still open there. When the wind pushes it to the calm side, the work on the calm side is already available to it — no reassignment, no notifications, no plan to rebuild. The pending pile is a live query, not a list somebody owns.

This is also why route optimisation is beside the point. Optimising a route presupposes an assignment and a fixed sequence, and out here the sequence is decided by the person who can see the wind. The crew app ranks what is open by distance and bearing from where the boat actually is, and the operator picks.

A crew app that works with no signal

Not "works offline" as a feature bullet. The work happens on the water, and the water is where the bars are not. Every write a crew makes — the clock, a finished piece, a skip with a reason, a corrected pin, a photograph — has to land on the device and go up when the boat comes back into range, with nothing lost and nothing double-counted. If the crew has to remember which taps are safe out of range, they will stop making them.

The honest trade

A tool shaped for one trade gives up the breadth of a tool shaped for all of them. LakeOps has no calendar and will not get one. It does not do route optimisation. It produces no invoices, has no invoice numbers, and does not sync with QuickBooks or Xero — a job prices itself from your price list when it is finished and the customer is emailed what was done with a link to pay, and every report exports to CSV for whoever keeps your books. We keep a whole page of what it refuses to do, because knowing that quickly is worth more to you than a demo.

If your work is genuinely appointment-shaped — a technician, a date, an address, a signature — the general tools are better at it than we will ever be, and you should use one. If your season is decided by ice and wind and your work is a set of pieces sitting in the water at a few hundred properties, the calendar is the part that was never going to fit.

How to tell which one you are

One question, and it is not about features. When the wind comes up at ten in the morning and you move a boat to the other side of the lake, how much of your software do you have to re-do?

If the answer is "nothing — the work over there was already waiting for them," the shape fits. If the answer is a morning of dragging appointments, it does not, and no amount of feature comparison is going to change that.