From query to condition

For most of search’s history, we’ve relied on people turning up and asking for something. They type a query, get some possible answers, and decide what to do next. We research the language they use and compete to appear among the results, then spend a considerable amount of time arguing about which department deserves credit if they buy anything.

When none of the answers is suitable, the customer has more work to do. Suppose I’m looking for a hotel near a conference venue, under £200 a night, where I can arrive late and bring the dog. I might spend an evening comparing places without finding anything that works. My interest survives after I close the browser, but taking another look means remembering the requirements and repeating much of the exercise.

Instead, imagine being able to leave an instruction: “Keep looking for somewhere that meets those requirements, and tell me when a room becomes available.” An agent could retain the brief after I closed the browser, checking new availability against it. My query would have become a standing condition, which the system could continue evaluating while I got on with something else.

If that request remained active for three weeks, a hotel could win my booking at the end of that period without me searching again. It would be competing for a purchase I’d already described, perhaps long before it had anything suitable to offer. The opportunity would arise when its circumstances changed enough to meet my requirements.

Of course, we already delegate some of that work to price alerts and saved searches. They can cover multiple products and, through comparison services, multiple suppliers. Their usefulness still depends on how well our requirements fit the service’s filters, and whether a suitable offer appears among the sources it monitors.

To handle my whole hotel brief, though, a system might need to combine information from several places. A booking service could have the room, while the hotel’s own website explains how late arrivals work. Establishing whether it’s a practical walk from the venue could require inspecting the route, rather than measuring the distance between two dots. I’d prefer not to discover the motorway junction after checking in.

An agent could carry the brief between those sources and retain what it learned. It could also ask about compromises: perhaps I’d accept a slightly higher rate to avoid a taxi journey. Having established that, it could apply the answer when assessing other properties, including somewhere I hadn’t heard of when I started looking.

The task could therefore remain useful even if every hotel I initially considered became unavailable. I wouldn’t need to pick another property to monitor or reconstruct the requirements inside another website’s filters. The system would still know what an acceptable booking looked like, and could keep looking for ways to fulfil it.

How well it did that would depend on its access and incentives. An agent relying on one affiliate feed could inherit the blind spots of a comparison service, then explain its recommendation with considerably more confidence. We’d need to establish how widely it actually looked before assuming that a helpful conversation represented a thorough search.

But provided it could find and evaluate suitable offers, the request could stay open across changes of product and source. Businesses might become relevant to it days or weeks later, without the customer returning to ask again.

When the hotel qualifies

So suppose the agent has that brief and has identified a hotel which would otherwise be ideal, except its dog-friendly rooms are fully booked. Excellent reviews and a prominent position in search results won’t make it suitable for this trip. I might negotiate a little on the budget, but the dog is coming regardless of how authoritative the website is.

Three weeks later, somebody cancels. The hotel now has a room which meets the requirements, at a price I’m willing to pay. An agent still working on my brief would have a reason to reconsider it, even though nothing about my request had changed.

That opportunity would last until the room was booked again. During the available window, the agent would need to discover the room and establish that the booking worked as a whole. The headline rate might fit my budget, for example, but an additional charge for the dog could take the total over it.

For the hotel, a position in a generic ranking would explain very little about this opportunity. It could remain highly visible throughout, while its ability to accommodate me changed from one day to the next. Understanding why it was excluded, and what made it eligible again, would be much more useful.

It could then consider whether some of those exclusions were worth addressing. Making late check-in possible might open up demand that better content about late check-in would never satisfy. Other restrictions might be commercially sensible, but there would at least be a reason to examine them beyond finding another topic for the content calendar.

The offer has to reach the agent

Before any of that could produce a booking, however, the agent would need to know that the hotel had become suitable. The booking system might record the cancellation immediately, while the information available elsewhere still said there were no dog-friendly rooms. The hotel could spend several hours able to fulfil my request without giving the agent any reason to reconsider it.

Even after the availability updated, the rest of the offer might remain difficult to establish. Reception knows how late arrivals work, but the website contains an old check-in policy. A third-party listing says pets are prohibited, while the homepage promises a warm welcome for the whole family. Presumably the dog is meant to appreciate the ambiguity.

Faced with that discrepancy, the agent could investigate further, contact the hotel or ask me to intervene. It could also recommend somewhere whose suitability was easier to establish. Relying on someone else’s software to persevere through contradictory information seems an optimistic approach to distribution.

To recommend the booking, it needs enough information to evaluate the actual offer. The available room, applicable policies and total price have to belong together. A general claim that pets are welcome won’t help if the room doesn’t permit them, and a low headline rate won’t settle the budget question if compulsory charges appear later.

Solving that problem involves more than choosing a machine-readable format. Structured data, feeds and accessible HTML can help expose what the business knows, but they need to reflect the same offer and update while it remains available. Making three contradictory prices machine-readable gives the agent a better-documented problem.

Technical SEO should be able to follow this through. We ought to understand where the current answer lives, how it reaches the outside world, and what prevents another system from establishing whether a customer can buy. The fix might involve the booking platform, a stale feed, or a policy nobody has bothered to publish. An audit which stops at recommending schema could leave the hotel technically improved and just as difficult to book.

Now suppose the hotel gets those details straight and publishes the availability in time. The agent discovers the room, checks it against the brief and contacts me. Assuming I still need somewhere to stay, I can book without repeating the evening’s research that produced the requirements in the first place.

From my perspective, the process has responded to something changing in the world. Underneath, the software might have searched or polled sources repeatedly, but those checks all related to an existing request. I wouldn’t have needed to generate another query to keep my interest visible to it.

That distinction matters when we try to measure demand. I could remain willing to buy throughout the three weeks without another search of my own. Counting every automated check as fresh demand would be misleading; assuming my interest had disappeared because I stopped searching would be equally unhelpful.

The eventual booking could depend on a cancellation and a timely availability update, long after the original interaction. Reporting might capture plenty of activity without explaining why the sale became possible that morning. A higher ranking wouldn’t have released the room, and another visit from me while it was unavailable would have achieved very little.

For the business, this would make the reasons for exclusion worth investigating. Which requirements repeatedly prevent bookings? Which could it meet without making the offer uneconomic? Marketing can spend a remarkable amount attracting people with the same unmet need while an operational decision, made by someone who left in 2017, quietly prevents the sale.

Those decisions would still belong to the business. An agent wouldn’t make every request worth fulfilling, any more than it would turn every stored instruction into a guaranteed purchase. But it could keep a customer’s requirements active long enough for a change in the offer to create an opportunity.

Before commissioning another page about dog-friendly hotels, I’d want to understand what those waiting customers had asked for. What would need to become true for them to choose us, and would their software be able to tell when it did?

1 Comment

This is one of the agentic developments I see happening for people with disabilities – not just a blind person with a guide dog, but a wheelchair user needing flat access, a deaf person requiring visual alarms, etc.