ChatGPT Get Quote: Home-Services Readiness Guide

An 80-location garage-door brand can appear to have one quote form while operating 80 different service realities. One market handles commercial doors. Another stops at a county line. A third routes calls to an acquired brand. If ChatGPT sends a high-intent request into the wrong branch, the new interface has only made the old routing problem faster.

OpenAI now documents a Get Quote conversion flow for local services in ChatGPT. The flow can place a Get Quote button on an eligible local-business card or sidebar, then open an approved provider's quote-request experience inside ChatGPT. It is a meaningful new conversion surface for home services, but it is not generally available: OpenAI says the program is in beta and being tested with approved partners.

If your locations do not yet share one reliable record for services, coverage, reviews, and customer routing, use the demo action below. A conversion integration is only as trustworthy as the local facts behind it, and the AI Visibility Grader will tell you in a few minutes whether ChatGPT names the right branch at all.

What ChatGPT Get Quote for home services actually does

OpenAI's local services Get Quote conversion specification opens with the mechanism:

ChatGPT can directly invoke partner plugins for high-intent local services use cases, such as requesting a quote.

Last verified: September 2, 2026.

When ChatGPT finds an eligible local business, its business card or sidebar can show a Get Quote button. Selecting that button opens the provider's quote-request widget in a modal.

Before anyone builds against it, size the surface. In the Cheers market baseline for the 28 days ending September 2, 2026, ChatGPT sent 48.8% of its 70,723 home-services citations to a contractor's own website and 44.7% to directories and review platforms. The quote widget sits at the end of that path, so a business that is not in the answer never sees the button. The cuts are in AI visibility statistics and the sampling rules in the methodology.

Three qualifiers matter.

First, the feature is in beta and tested with approved partners only. OpenAI directs interested builders to a merchant application form rather than presenting Get Quote as a self-serve setting. Second, the current contract covers quote requests; other service actions such as appointment booking are not part of it.

Second, the button is conditional. OpenAI says ChatGPT builds the launcher only when the local-business record has a nonempty ID, the matching service-provider record has a provider business ID and valid action URL, and that provider has a configured partner plugin.

Third, this is a quote-request contract. The specification says appointment booking is outside the required flow. A company should not announce "book directly in ChatGPT" when its approved integration only opens an estimate or intake experience.

That boundary is useful. It lets a regional operator evaluate the work as a narrow conversion project: can the right customer open the right quote experience for the right local business?

Build the location crosswalk before the plugin

The feed starts with a local-business record. OpenAI requires a stable business ID, name, address, latitude and longitude, phone number, website URL, and canonical platform URL. A quote-enabled record adds a service-providers array with the provider name, provider business ID, request_a_quote action type, and provider action URL.

Those are compact fields with large operating consequences. A brand-level phone number may reach a call center that cannot honor a market's service promise. A website URL may land on a national homepage instead of the relevant branch. A coordinate may identify an office even though the dispatch team serves a different market. A provider business ID may point to a CRM account rather than the location that owns the lead.

Before an engineering team builds the feed, the operator should approve one crosswalk:

• OpenAI business record: stable ID, public name, address, coordinates, phone, website, and canonical listing URL
• Provider record: provider name, provider business ID, action type, and quote-action URL
• Operating record: internal branch ID, brand, market, service area, service lines, hours, dispatch owner, and escalation owner
• Public proof: location page, business profile, citations, and customer-facing phone or form path
• Eligibility decision: whether this location currently accepts this kind of quote request
• Readback owner: the person who verifies where the request landed and what the customer saw

The multi-location entity fragmentation guide explains how to reconcile conflicting branch records. The location-page checklist covers the customer-visible source that should agree with the feed. Google's guidelines for representing your business set the same expectation on the profile side, including the warning that more than one profile per business causes display problems on Maps and Search.

A pest-control branch that handles general household pests but not wildlife exclusion should not receive every request under one generic provider record. The customer-facing scope, feed eligibility, and dispatch rules should reach the same conclusion before the location is added.

Keep the business ID and provider business ID separate

OpenAI's specification uses two identifiers for different jobs. The containing local-business record has its own ID. The service-provider record has a provider_business_id, which ChatGPT passes into the request_service tool as business_id when the customer selects Get Quote.

That distinction is easy to lose in a rollup. The public business may be known by one store code, the CRM by another account ID, the scheduler by a territory key, and the acquired brand by a legacy branch number. Do not assume those values are interchangeable.

Use a stable provider-side identifier that resolves to one accountable service operation. Store the mapping outside the model. Reject missing, retired, duplicated, or ambiguous identifiers at the feed boundary. When a branch closes or a franchise territory changes hands, disable quote eligibility before repointing the action.

OpenAI's tool-design guidance says tools should use explicit inputs rather than ask the model to guess identifiers or account scope. It also recommends separating reads from writes and documenting authorization, side effects, and failure behavior. For a quote request, the provider business ID is not a decorative field. It is the routing key that must survive the handoff.

Use a plugin only where server-backed action is necessary

OpenAI now packages extensions as plugins that can contain skills, an MCP server, or both. Its plugin architecture says an MCP server is appropriate when a workflow needs live data, controlled tools, authentication, or behavior on infrastructure the provider operates. Custom UI is optional in general, but this local-services contract calls for a request_service MCP tool tied to the provider's quote widget.

For a home-service brand, the plugin should expose the smallest useful action. The launcher receives the mapped provider business ID. The widget collects only the information required to request the quote. The provider validates the location, service type, contact fields, consent, and routing rules on its own server. The model should not invent coverage, availability, pricing, or the destination branch.

If the experience exposes customer-specific records or performs account-bound actions, OpenAI's authentication guidance says the MCP server should authenticate users and describes OAuth 2.1 for protected servers. A simple public quote request may not need a customer login, but it still needs server-side validation and a clear consent boundary.

OpenAI's security and privacy guide sets the scope rule in seven words:

Only request the scopes, storage access, and network permissions you need.

It also asks for server-side input checks, restrained data collection, PII-redacted logs, and "requiring human confirmation for irreversible operations". A local quote form should not collect a gate code, a medical detail, an insurance narrative, or a full job history merely because the interface makes it easy.

Separate discovery, launcher eligibility, and revenue

Get Quote does not replace the work that helps a location become understandable and recommendable. OpenAI's specification explains the conversion launcher, not how ChatGPT chooses which local businesses to show. It does not document the partner plugin as a recommendation boost.

Maintain four separate stages in reporting: the location appeared in the tested answer or local result; the business record qualified for the Get Quote launcher; the customer opened and completed the provider experience; the location accepted the request and produced a qualified opportunity or booked job.

That separation prevents two common mistakes. A team should not credit the plugin for organic visibility it did not create. It should also not report every widget open as a lead when the request was outside the service area, duplicated, abandoned, or routed to the wrong branch.

The existing AI agent booking guide covers the broader customer path when an agent uses a company's website. The AI search traffic measurement guide explains why visibility, citations, referral traffic, and booked demand need different records.

For restoration, a request for visible water damage may need a rapid local assessment while a reconstruction estimate follows a different path. One completed modal does not prove that the right service team received enough information to act.

Run a four-week readiness pilot

The following plan is a Cheers operating recommendation, not an OpenAI program requirement:

• Week 1, scope: choose one service line and one market, confirm partner eligibility, inventory likely customer requests, and list the requests the first version will explicitly refuse
• Week 2, identity: map the local-business ID, provider business ID, branch, service area, phone, website, action URL, and accountable owner; reconcile every mismatch before exporting the feed
• Week 3, controlled test: exercise the request_service launcher, validate required fields and consent, submit successful and failing quote requests, and verify the exact destination in the provider system
• Week 4, readback: compare launcher eligibility, widget completion, qualified requests, wrong-market requests, duplicates, branch response, and downstream job status; expand only if each exception has an owner

Include negative tests. Try a ZIP code just outside coverage, a service the location does not perform, a closed branch, a duplicated provider business ID, an expired action URL, a missing phone number, and an abandoned request. OpenAI's submission process itself asks publishers for positive and negative test cases, accurate tool annotations, public support and privacy materials, and a verified business identity.

Stop the rollout if the team cannot answer three questions for any submitted request: which public business the customer selected, which provider business ID the launcher passed, and which local operation accepted or rejected the lead.

What operators should prepare now

Most service brands cannot activate this beta today. They can still prepare the assets that determine whether an eventual integration is safe: a clean location registry, stable provider IDs, accurate coordinates and phone routes, branch-specific service eligibility, direct action URLs, consent language, exception handling, and location-level outcome reporting.

That work is not speculative. It improves the owned booking path, partner feeds, marketplace integrations, and customer routing even if the brand never joins this beta.

The near-term decision is therefore not "should we build a ChatGPT plugin?" It is "do we have one market where a quote request can move from public business record to accountable local outcome without a human repairing the route?" If the answer is no, fix that chain first.

Sources

Every link below was opened and checked on September 2, 2026.

• Local services Get Quote conversion spec. OpenAI Plugins documentation. Beta status, approved-partner access, launcher behavior, required business-feed fields, provider mapping, and the limit to quote requests.
• Plugin architecture. OpenAI Plugins documentation. Skills, MCP servers, controlled tools, and optional UI.
• Brainstorm use cases. OpenAI Plugins documentation. User expectations, required context, and safety boundaries.
• Define tools. OpenAI Plugins documentation. Explicit inputs, stable identifiers, authorization, side effects, and separating reads from writes.
• Authentication. OpenAI Plugins documentation. Authentication boundaries and OAuth 2.1 for protected MCP servers.
• Security and privacy. OpenAI Plugins documentation. Least privilege, consent, server-side validation, logging, PII, and human confirmation for irreversible operations.
• Submit plugins. OpenAI Plugins documentation. Publisher verification, tool annotations, and test cases.
• MCP server review requirements. OpenAI Plugins documentation. Hosted server, organization verification, and public versus private deployment.
• Cheers market baseline, 28 days ending September 2, 2026. 32 home-services prompts, 100 metro areas, 70,723 ChatGPT citations classified by domain. Aggregate only. Methodology.

Amadeus Peterson is the CTO and Co-Founder of Cheers, the local search platform for multi-location service businesses.