--- type: Article name: The request behind your booking button is what matters. id: "https://selfe.ai/insights/agent-ready-transactions/your-booking-button-is-not-the-point" url: "https://selfe.ai/insights/agent-ready-transactions/your-booking-button-is-not-the-point" publisher: "did:web:selfe.ai" description: "A booking button helps a person start a journey. An agent needs to establish the terms of a specific request, know what it may do and carry the relevant context into the next step." datePublished: 12 September 2026 author: The Selfe team --- # The request behind your booking button is what matters. > A booking button helps a person start a journey. An agent needs to establish the terms of a specific request, know what it may do and carry the relevant context into the next step. ## In short - A visible checkout or booking button is not a complete transaction contract. - A real request carries details that shape availability, price, terms and fulfilment. - The best hand-off preserves the question already answered instead of returning the customer to a blank form. A bike hire shop can let an AI agent check availability, compare bike types and assemble a specific request on its own, while still keeping payment or an unusual booking for a person to confirm. Where that boundary sits is a business decision, not a technology limit. A bike hire shop lists an e-bike alongside a "Book Now" button that works well for a browsing customer. Ask an AI agent to book that same bike for a specific week, a specific height, and one rider who needs a step-through frame, and the button alone answers none of it. ## A button starts a human journey A booking or checkout button is designed for a person who can read around the page, make a judgement and supply missing information as they go, checking whether a step-through frame is available, noticing the size chart, emailing if the dates look tight. It is an important part of a customer journey, but it does not tell an AI agent what can be booked, on what terms or under which constraints. For an agent, the question comes first. A request for the bike hire shop might include dates, a rider's height, an accessibility need, whether a child seat is required. The transaction only becomes meaningful once those details can be checked against what the shop can offer that week, not against a generic booking form built for a person to fill in by hand. ## A purchase is a specific request Two customers can click the same "Book Now" button and need entirely different answers. A step-through e-bike for a rider with a knee injury and a standard mountain bike for an experienced rider are not interchangeable, even if both show as "available" on the same page. A bike in stock for one week may be already booked the next. A child seat may be available in principle but need a day's notice to fit. The transaction surface therefore needs more than a destination URL. It needs a way to express the actual request, return the relevant conditions, and make clear whether the next step is a confirmed booking, a request the shop needs to check, or a conversation with staff about a specific need. ## The useful boundary is permission Not every bike hire shop should let an agent complete every step on its own. The decision is about permission, not technological theatre. A shop can let an agent check availability, compare bike types, and assemble a specific request, while keeping payment, a damage deposit, or an unusual request for a group of twelve for a person to confirm. When that boundary is explicit, the experience is safer for everyone. The agent knows exactly when to stop and hand over, the customer knows what's been booked versus what still needs confirming, and the shop receives a request with the real context, dates, sizes, the knee injury, already attached. ## A good hand-off does not throw away the work The common failure is sending a customer from an agent's informed recommendation, this bike, these dates, this size, back to a generic enquiry form that asks for all of it again. The shop then asks the same questions a second time, and the value of everything the agent already worked out disappears. A good hand-off carries the request, the specific bike, the dates, the accessibility need, forward intact. A business's real booking system, the one that knows this week's stock and sizes, connected to something an AI agent can check and complete a specific request against directly, rather than a button built only for a person to click and then explain themselves: that's the specific gap Selfe closes. That is what makes a transaction agent-ready: not a button an agent can see, but a reliable route from a specific need to the next permitted commercial step. ## Does every business need to let an agent complete a full booking automatically? No. A business can let an agent discover, compare and assemble a request while still keeping payment or an unusual case for a person to confirm. ## What happens to details an agent has already gathered if a person has to step in? A good hand-off carries them forward, the specific dates, sizes, and any unresolved question, so nobody has to ask the customer to repeat themselves. ## Act on this - [Check whether an agent can buy from you](https://selfe.ai/agentic-commerce/buyability-check) — the free readiness scan. - [Discover venues](https://selfe.ai/api/registry/discover) — `POST`, semantic browse across the registry. - [Match a bookable answer](https://selfe.ai/api/registry/match) — `POST` with dates and party size. - [Verify Selfe's identity](https://selfe.ai/.well-known/did.json) — `did:web:selfe.ai`. - [Agent card](https://selfe.ai/.well-known/agent-card.json) — how to connect over A2A or MCP.