Explainer2026-09-14T19:47:41.232Z

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

The honest answer to "how long will this take" depends far less on how hard the technical work is than on how quickly a business can find the one fix an AI agent is genuinely waiting on.

4 min read

The Selfe team
Agentic commerce infrastructure
Ask how long this takes and the honest answer has two very different numbers hiding inside it: a few days to find the real blocker, then days to a couple of weeks to fix it, once the diagnosis is actually right.

The technical work is usually a matter of days

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 what actually sets the timeline

This site's own piece on finding the one fix that matters covers the mechanics of testing rather than guessing at the blocker. Applied to timeline specifically: 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. Testing a real request through an agent first usually finds the real gap in days, because the test shows exactly where the agent stops rather than where a guess suggests it might.

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.

For most small operators, it's days to test and a week or two to fix

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.

Shortening the diagnosis is the real saving, not just shortening the fix. Selfe tests against a business's real systems to find where an agent actually 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.