How long it actually takes to go from unready to bookable.

The technical part is often measured in days, not months

A boat-trip operator wants one number: how long until an agent can book a trip directly. The honest answer splits into two different questions hiding inside that one, how long the technical work takes, and how long it takes to work out which technical work is worth doing, and the second is almost always the longer one, the one most timeline estimates skip entirely.

Once the actual blocker is known, connecting a live booking calendar to something an agent can check, or getting accurate trip-capacity figures into a checkable form, is frequently a matter of days for a business this size, not the months a full "digital transformation" project might suggest. The work itself isn't usually the slow part. What's slow is figuring out, with any confidence, that this particular fix is the one worth doing.

Diagnosis is the real timeline, and it depends on testing, not guessing

An operator who guesses at the problem, assuming it's the booking calendar because that's the newest system, might spend three weeks improving something that was never the actual blocker. The same operator testing a real request through an agent first, the way a proper readiness check does, usually finds the real gap in days, because the test shows exactly where the agent stops rather than where a guess suggests it might. The technical fix that follows is often the fast part; the accurate diagnosis is what determines whether that fast part happens once or three times over.

Seasonal businesses face a sharper version of this

For a boat-trip operator, most of the year's bookings cluster into a handful of months, so a slow diagnosis has a real cost beyond the delay itself: a summer spent chasing the wrong fix is a summer of agent-driven bookings missed entirely, not just postponed. This is exactly why testing the real blocker early matters more here than for a business whose demand is spread evenly across the year.

It also changes when the test itself is worth running. An operator who waits until the first warm weekend of the season to find out where an agent gets stuck has already lost the busiest early bookings to whatever the problem turns out to be. Running the same test in the quiet months, when a wrong guess costs nothing but a few days, is the same diagnostic step done at a point where getting it wrong is nearly free instead of genuinely expensive.

A realistic answer, stated plainly

The honest timeline for most small operators looks like this: a few days to properly test where an agent gets stuck, then days to a couple of weeks to fix that specific thing, not months, provided the diagnosis was right the first time. The businesses that take longer are almost always the ones that skipped the testing step and fixed something plausible-sounding instead.

Selfe's job is shortening the diagnosis, not just the fix: a live check against where an agent genuinely gets stuck, so the days spent testing replace the weeks a business might otherwise spend improving the wrong thing.

So how long should we budget, realistically?

Days to test and identify the real blocker, then days to a couple of weeks to fix it, for most small operators, provided the first step isn't skipped.

What if we don't have time to test properly before the season starts?

That's exactly when testing matters most. A guessed fix that turns out wrong costs an entire season, which is longer than the testing step would have taken.