Can an AI assistant book you a dentist appointment? We ran five sessions. None of them could.

The short answer

Booking is the flat no. On all five sites the session ended the same way — with a link, a web form or a phone number for the patient to use themselves. There is no version of "and then the assistant made the appointment", because there was nowhere to send one.

Reading is the mixed result, and it is the more useful half. Two practices answered the price question perfectly well: their number sat in plain text, next to the name of the service, in a sentence or a row anything could parse. That matters, because it means this is not a hard problem that needs a platform to solve. It is a formatting problem. The other three showed what happens when the formatting goes slightly wrong: one price could only be worked out by joining table rows back to a column header, one existed only inside a booking application, and one practice gave three different answers to the same question across its own three channels.

How the sessions were run

Nothing clever, on purpose: this is the retrieval step of an ordinary assistant session, not a crawler tuned to win.

• Five sites, drawn from the twenty in our UK practice price survey: three dental practices, two physiotherapy clinics, one city each, chosen because their fee pages could be fetched at all.
• Public pages only. Plain HTTPS fetches with a normal desktop browser user agent, no JavaScript executed, no logins, nothing submitted anywhere.
• At most three pages per site — the landing page and what it linked to. An assistant that reads a whole website is not what a patient's question actually triggers.
• One task per session, acting as the patient's assistant: "How much is a check-up at this practice, and can you book me in?"
• Every session recorded as run, including what it got right, where it became uncertain, and what it would have had to tell the patient. Partial successes and clean reads are in the record because the article has to honour them.
• Sites are identified by city and vertical only, the same way the survey rows are. Sessions ran 2 August 2026; websites change, so every claim here is scoped to that date.

The two that worked

Worth reading first, because both are cheap to copy and neither involved any structured data at all.

1. Physiotherapy · Coventry

   One sentence in an FAQ did the whole job

   The clinic's homepage answers the question in its own FAQ, verbatim:

   How much is a session? 30 minute sessions are priced at £45 each.

   A question, an answer, a fixed amount and a duration, in one line. Any text extractor gets that. This site carries no structured data whatsoever — the machine-readable answer exists purely because the human-readable sentence happens to be unambiguous. It was the cleanest price statement in the five, and it cost the clinic one sentence.

2. Dental · Leeds

   A long fee table, read correctly — with one qualifier the header carries

   The fees page is a plain-text price list running to 103 pound amounts. The rows the question needed, with their headers:

   EXAMINATIONS | FEE FROM | MEMBERSHIP PLAN DISCOUNTED FEE New patient examination | £99 | - Routine dental examination | £59 | Included

   A routine check-up is from £59, a new-patient examination from £99, and both were readable directly. Two things a careless reader loses: the column is headed FEE FROM, so every figure is a floor rather than a total, and the discounted membership fee sits in the very next column, close enough for a naive extractor to pick up as the price. The session still had to decide whether the patient counted as new or routine before answering — the practice publishes two prices for "a check-up", which is correct, and which a machine has to be told how to choose between.

The three that did not

1. Dental · Southampton

   The number was there. The pound sign was not.

   The fee table reads, in row order:

   Treatment | Fees From (£) New patient examination | 65 Children examination | 30 Existing patient examination | 60

   The whole page contains six pound signs and every one of them is in a column header. Read the rows alone — which is what a flattened copy of the HTML gives an assistant — and "New patient examination 65" is 65 of nothing. The session only produced £65 because it went looking for the header on purpose. The same header carries the second qualifier: these are From-prices, so £65 is a floor. Nothing about the page is wrong for a human. It just stops being a price the moment the table structure is lost.

2. Physiotherapy · Plymouth

   The price lived one click inside the booking system

   The clinic page — the page an assistant lands on from a search — contains no pound amount at all. Following the "Book an appointment" button into the booking application turned up a cost breakdown listing an initial appointment at £59.00, or £47.20 with the provider's own membership discount. The session found the number, but only because it followed the booking link and that application happened to serve its breakdown in the initial HTML. Two "Total cost" lines appear in the same breakdown, the member and non-member totals side by side; a naive extraction returns either one as "the" price. An assistant that reads the clinic page and stops — the ordinary case — reports that this clinic does not publish a price.

3. Dental · Sheffield

   Three channels, three different prices

   This is the finding worth the whole exercise. One practice answers "how much is a new-patient exam" three times, in three places built for three audiences, and the three answers do not agree.

   Visible pricing page £69 (promotional, was £105) JSON-LD markup £105 (the pre-promotion price) llms.txt price guide £80 – £120

   The human answer today is £69. The machine-facing markup states the superseded £105. The file written specifically for AI assistants publishes a range that does not contain £69 at all. An assistant doing exactly what the standards ask — preferring structured data and the assistant-facing file over scraped page text — quotes the patient £105 for something the practice is currently selling at £69. It is the best-instrumented site of the five and it produces the most expensive error: £36 over, on the strength of its own markup.

   Nothing here was done in bad faith. The promotion went onto the page, where promotions go. The other two channels were written once and have not moved since. That is the failure mode this whole subject is really about: not sites that publish nothing, but sites whose machine-facing copies quietly go stale while the visible page stays right. Booking, for the record, was phone and email only.

What "cannot be booked" precisely means

On these five sites the booking paths were: a third-party scheduling application, a public scheduling link, a set of human web forms with policies to agree to, an NHS waiting-list registration, and a phone number. Every one of them is a real, working way for a person to get an appointment. None of them is a place an assistant can send a structured request and get an answer back.

Be precise about the limit of this test: these sessions did not drive a browser, so a more capable agent clicking through a scheduling app might get further than they did. What that agent still would not find is an address to send a request to — and that part is measured across the whole sample, not just these five. Across the twenty surveyed sites, the number with any endpoint an assistant could submit a booking or quote request to was zero.

Five sites is an anecdote. Here is the sample it came from.

These sessions were run against sites from a twenty-site survey of UK dental and physiotherapy practices, measured 31 July 2026 — one city per site, no city reused, and searched on vertical and city only so the sample was not biased toward practices that publish prices.

Sixteen of the twenty emit JSON-LD and not one puts a usable price in it. The full method, all twenty rows and the six ways a visible price defeats an extractor are published at the UK practice price survey. The five sessions on this page are consistent with it: the prices are there, they are published in good faith, and they are written for eyes.

What a practice can do about it

In order of effort. The first one is two minutes and needs nobody's permission.

1. Check your own three channels against each other. Open your fees page and note today's price for your headline service. Then view the page source and search it for application/ld+json — if there is a price in there, is it the same number? Then try yoursite.co.uk/llms.txt — if it exists, does it say the same thing? The Sheffield practice above would have caught a £36 discrepancy in two minutes with exactly this check.
2. Make the visible price survive being flattened. The Coventry clinic's one FAQ sentence beat every piece of structured data in these five sessions, and there was none on its own site. Put the pound sign next to the number rather than only in a column header, keep the service name in the same row or sentence as its price, and if a figure is a From-price, say "from" beside it — a floor repeated as a total is a worse outcome than no price at all. If a price only exists inside your booking system, put it on the page as well.
3. Know what an llms.txt does and does not buy you. It is a summary file for assistants, hand-written or generated by a plugin, and it is cheap and worth having. It did not make a single fee machine-readable on any of the twenty sites surveyed. Four of the twenty served a real one; another answered /llms.txt with a 200 and an ordinary HTML page, so even counting them means reading them. And on the one site in these sessions whose llms.txt did carry a price guide, the range it published was wrong. An unmaintained file is a third way to be out of date.
4. The asking half, nobody currently provides. All of the above makes a practice readable. Being askable — having somewhere an assistant can send "this patient wants Tuesday at four, here are their details" and get a real answer back — is not a formatting fix, and none of the twenty sites had it. A booking widget is not it: it is a web application built for a human to operate, which is why every one of these sessions ended with a link instead of an appointment. The survey has since grown to forty sites in four verticals, and two of those forty do now expose an endpoint an agent can call — both put there by the website platform rather than the owner, and neither offering a tool that submits anything. That is written up at Two of forty sites ship an agent endpoint.

Ajar sells that missing half — a page serving your prices in a shape a machine parses exactly, plus an endpoint where an assistant's request waits for your approval — which is why we ran these sessions, and you should read them knowing that; see for dentists and for physios.

Why every claim here carries a date

The Sheffield practice's structured data changed underneath us. On 31 July, when the survey measured it, its Offer markup carried a full catalogue of services with every price field empty. By 2 August, when the session ran, three prices had appeared in it — and they were the superseded ones. Two days.

So the survey's "0 of 20 publish a machine-readable price" is scoped to 31 July, and the three-channel disagreement described above is scoped to 2 August. Neither statement is a permanent fact about anybody's website, and we are not going to write it as one. The general finding survives the drift, and is in some ways strengthened by it: a site whose machine-facing markup can gain wrong prices in two days without anyone noticing is exactly the site that needs the check in step one.