ChatGPT Get Quote for Home Services: A Multi-Location 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, book a Cheers demo. A conversion integration is only as trustworthy as the local facts behind it.

What ChatGPT Get Quote for home services actually does

OpenAI's local services Get Quote conversion specification describes a partner flow for high-intent local-service requests. 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.

Three qualifiers matter.

First, the beta is limited to approved partners. OpenAI directs interested builders to a merchant application form rather than presenting Get Quote as a self-serve setting.

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.

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 also calls for least privilege, explicit consent, server-side input checks, restrained data collection, PII-redacted logs, and human confirmation for irreversible actions. A local quote form should not collect a gate code, medical detail, insurance narrative, or 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

• OpenAI Plugins: local services Get Quote conversion spec. Beta status, approved-partner access, launcher behavior, required business-feed fields, provider mapping, quote eligibility, and the limit to quote requests
• OpenAI Plugins: plugin architecture. The current plugin model, universal directory, skills, MCP servers, controlled tools, and optional UI
• OpenAI Plugins: brainstorm use cases. User expectations, required context, safety boundaries, and first-version support decisions
• OpenAI Plugins: define tools. Explicit inputs, stable identifiers, authorization, side effects, failure behavior, and separate read and write actions
• OpenAI Plugins: authentication. Authentication boundaries and OAuth 2.1 for protected MCP servers
• OpenAI Plugins: security and privacy. Least privilege, consent, server-side validation, logging, PII, and irreversible actions
• OpenAI Plugins: submit plugins. Publisher verification, tool annotations, test cases, privacy materials, and public submission requirements
• OpenAI Plugins: MCP server review requirements. Hosted server, organization verification, review, and public versus private deployment requirements

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