The question comes before the customer does
In 2026, AI assistants began calling local service businesses on behalf of customers. The assistant asks what your service desk hears every day. Do you cover this ZIP code? Can someone take the car tomorrow morning? What is the after-hours rate? A shop usually does not need ZIP coverage, because the customer drives in. When a shop publishes none, the answer to any ZIP is that the customer brings the vehicle to the shop. But an assistant that cannot get that answer fast drops your shop from the shortlist before the customer ever sees it.
None of those answers is a secret. They sit in pieces across your website, your Google Business Profile, and your scheduling software. Today an assistant either calls you to ask, or reads your pages and guesses. Neither is a reliable way onto a shortlist.
What the file says
Open Service Profile is a small file at /.well-known/open-service-profile on your website. It describes your business in a form an AI assistant can read. It says who you are, where you work, what you offer, which ZIP codes or radius you cover, when you are open, and how an assistant may send you a booking request. The standard also defines six tools an assistant can call: five that read facts, and one that sends a booking request.
Every booking is a request. Your site may say a request was received. It may never say an appointment is booked, a time is reserved, or a technician is assigned. You confirm through your own process, by the contact method the customer allowed. The standard is a draft. Our parent company, The Service Marketing Guys, maintains it. It runs on live client sites first.
What this means for a shop
A shop tells the file that the customer brings the vehicle, boat, or item to you. The standard calls this the in_shop model. A marine yard that also sends a technician to the customer's marina says it does both. That one line decides what else the file must carry and how the tools answer.
No coverage required. Coverage is optional when the customer drives in. If you publish one, it describes where your customers usually come from and where a pickup or tow referral applies. If you publish none, a ZIP check answers "covered" for any ZIP, with a note that customers bring the vehicle or vessel to the shop and any ZIP is welcome.
The vehicle or vessel. A shop accepts vehicle details in a booking request: year, make, model, and mileage. A request does not need a service address by default. A business that works at the customer's address ignores vehicle details without an error, so an assistant can send them safely.
Drop-off windows. A window is a block of the day you take requests for. The standard names three, Morning, Afternoon, and Evening, and lets you add your own with a label, such as a drop-off at open. A window is open for requests on a day when your hours and rules allow it. That says nothing about how many jobs you can fit. An assistant must call it a window you take requests for, never "available". Whether you take walk-ins is a separate yes or no on each location.
A yard that does both. A yard that does either, haul-out at the yard or a technician at the customer's marina, tells the file it does both. Coverage is then required, as a ZIP list or a radius in miles from the yard. A service address is required by default. Vessel details are accepted in a request only when your booking rules say so. A radius match is only advisory, so the assistant is told to confirm with the yard.
Your trades in plain words. Where the web's shared vocabulary has a name for your trade, the file uses it exactly, for example AutoRepair. Where it has none, the label is plain lowercase text, such as "boat repair" or "marine engine service". An assistant treats trades as description, not a fixed list, and never rejects a file over a label it does not know.
A request, not a confirmation. The file says every booking is a request. Version 0.1 defines no other kind. The reply to a request says the appointment is not confirmed and is waiting on you, so no assistant can read silence as a yes. You confirm, in your own words, by the contact method the customer allowed.
Three levels
Each level includes the one before it. Your file says which level you claim. An assistant checks the claim instead of trusting it. Level 1 exists so a business with only a website and structured data can meet the standard today.
| Level | Name | What the business publishes |
|---|---|---|
| 1 | Read-only profile | The file, plus a short block of structured data on your pages. That block points one action at your schedule page, and the result is a pending reservation, not a booked one. No invented facts. |
| 2 | Read tools | Everything in Level 1, plus three tools an assistant can ask directly: who you are, what you offer, and whether you cover a ZIP code (get_business_info, list_services, check_coverage). Anyone can call them, calls are rate-limited, and the answers must match the file. A reviews tool (get_reviews) is recommended. |
| 3 | Booking | Everything in Level 2, plus a tool that takes a booking request (request_service_booking) and one that says which windows you take requests for (check_availability). The second must at least work from your published hours and booking rules. Every reply, page, email, or text a request triggers says received, never booked. |
What you publish to start
Level 1 asks for four things. None needs a server beyond the one already hosting your site.
- One file at /.well-known/open-service-profile. It is served as JSON, readable from other sites, and matches the standard's published format. It carries your display name, your trades, where work happens, your phone, your website, and your time zone. It lists each location with its address and hours. It lists each service with the address of its own page. It lists your coverage when work happens at the customer's address. And it holds your booking rules: the windows you offer, how many days ahead a request must be, whether you take weekend dates, whether you take urgent calls after hours, and how you confirm.
- A short block of structured data on your pages, the kind Google already reads. It can use the trade type where one exists (AutoRepair). It carries your name, address, phone, hours, and website, matching the file. It points one action at your schedule page, and says the result is a pending reservation, not a booked one. Listing each service in that block with its own action is recommended, not required.
- The file says every booking is a request. It also says where work happens and which trades you do.
- No invented facts. Every price, certification, hour, and service in the file already appears on your own pages, or comes from a source you control. The file carries no ratings or review counts. A business that is not ready publishes nothing rather than a placeholder.
Two examples
The standard ships example files. Ridgeline Auto Care is its one-location repair shop. Harbor Point Marine Service is its marine yard. Both companies, their addresses, and their phone numbers are fictional.
Ridgeline Auto Care, one location, Level 1
Trimmed from Appendix C.2 of the standard.
{
"specVersion": "0.1",
"conformance": { "level": 1 },
"business": { "displayName": "Ridgeline Auto Care", "trades": ["AutoRepair"], "serviceModel": "in_shop", "timeZone": "America/New_York" },
"locations": [{ "id": "main", "isPrimary": true, "acceptsWalkIns": true, "hours": { "weekly": { "monday": { "open": "08:00", "close": "17:30" }, "saturday": "closed" } } }],
"services": [
{ "slug": "check-engine-diagnostic", "name": "Check engine diagnostic", "pricePresentation": "Diagnostic $120 per hour, one hour minimum" },
{ "slug": "brake-repair", "name": "Brake repair" }
],
"bookingPolicy": {
"windows": [{ "id": "drop-off-open", "label": "Drop off at open (8:00)", "start": "08:00", "end": "08:30" }, { "id": "Morning", "start": "08:30", "end": "12:00" }],
"minimumDaysAhead": 1, "weekendRequests": "not_allowed", "requiresAddress": false,
"confirmationNote": "We call back the same business day to confirm a drop-off time."
},
"bookingSemantics": "request",
"interfaces": { "schedulePageUrl": "https://ridgelineautocare.example/schedule" }
}The full file also lists five services, the full weekly hours, a coverage note on where customers come from and where tow referrals apply, one certification, and an Afternoon window.
How one request plays out
A customer in Swannanoa asks an AI assistant whether Ridgeline can look at a check engine light tomorrow morning. Ridgeline is at Level 1, so there are no tools to call. The assistant reads the file and the structured data on the shop's pages.
It learns that the customer drives in. The diagnostic is $120 per hour, one hour minimum. At Level 1, that price must also appear on the shop's own page. The earliest request is tomorrow. Weekend dates are not accepted. There is a drop-off-at-open window from 8:00. The shop takes walk-ins.
The assistant answers those questions. Then it hands the customer the schedule page named in the file, the same page the structured data points at. The shop calls back the same business day to confirm a drop-off time, in its own words.
Harbor Point Marine Service, yard and mobile, Level 2
Trimmed from Appendix C.3 of the standard.
{
"specVersion": "0.1",
"conformance": { "level": 2 },
"business": { "displayName": "Harbor Point Marine Service", "trades": ["boat repair", "marine engine service"], "serviceModel": "both", "timeZone": "America/New_York" },
"locations": [{ "id": "yard", "name": "Harbor Point yard", "isPrimary": true, "geo": { "latitude": 41.7001, "longitude": -71.3830 } }],
"services": [
{ "slug": "winterization", "name": "Winterization", "pricePresentation": "From $295 for single outboards; quoted by engine" },
{ "slug": "mobile-service", "name": "Mobile service at your marina" }
],
"coverage": { "radius": [{ "locationId": "yard", "miles": 30 }], "note": "Mobile service to marinas within 30 miles of the yard. Haul-out at the yard only." },
"bookingPolicy": {
"windows": [{ "id": "Morning" }, { "id": "Afternoon" }],
"minimumDaysAhead": 2, "weekendRequests": "not_allowed", "requiresAddress": false, "vehicleDetailsAccepted": true,
"confirmationNote": "The service manager emails or calls within one business day with a haul or visit date."
},
"bookingSemantics": "request",
"interfaces": { "schedulePageUrl": "https://harborpointmarine.example/schedule", "mcp": { "url": "https://harborpointmarine.example/api/mcp" } }
}The full file also lists six services including dry storage marked not bookable, Saturday hours April through October, three certifications, a parent company, the area names the radius covers, and a card listing its tools.
How one request plays out
A boat owner at a marina in Bristol asks an AI assistant whether Harbor Point can winterize an outboard where the boat sits. Harbor Point is at Level 2, so the assistant can ask its tools directly.
The assistant checks the marina's ZIP. Harbor Point publishes a radius, not a ZIP list. If the server measures the distance, the answer is covered by radius and marked advisory, so the assistant is told to confirm with the yard. If the server does not measure distance, the answer is "not checked". An assistant must never present that as "not covered". The service list shows winterization from $295 for single outboards, quoted by engine, and a mobile service line.
The yard publishes Morning and Afternoon by name alone, with no clock times. So the assistant matches the owner's stated time by the everyday meaning of morning and afternoon. When nothing fits, it asks instead of guessing. The earliest request is two days out. There is no booking tool at Level 2, so the assistant hands the owner the yard's schedule page. The yard does both yard and mobile work and accepts vessel details, so a Level 3 request could carry the engine's year, make, and model. The service manager emails or calls within one business day with a haul or visit date.
What it does not do
The standard makes no claim about search visibility or ranking. It defines no payment, deposit, or card capture. It does not require a connected calendar. In version 0.1, the windows you take requests for come from your published hours and booking rules, and a live-calendar mode is optional. The standard is a draft, version 0.1. It makes one claim: an assistant that reads the file and the tools gives correct answers where a web page alone leaves it guessing. That claim is being tested, and the results are pending.
If you are a client
Your site already does this. We run client sites on their own domains. Each one publishes the file at /.well-known/open-service-profile at Level 2, but only when its facts are complete. A site missing a required fact publishes nothing rather than a placeholder. Those sites answer the three read tools. Booking requests run through the schedule page. Where a shop publishes coverage, it is the exact ZIP list from the shop's own locations, not a radius.
Read the standard
Our parent company publishes the standard. The text is free to reuse with credit (CC BY 4.0). The schemas and code are open source (MIT). The standard covers how an assistant finds the file, what the file holds, all six tools, the rules for customer consent and record-keeping, and a checklist for each level.