The address in an enquiry may be different from the place where its sender is browsing. An office manager can arrange maintenance for another branch. A property owner can request work while travelling. That is why the service area on a ChatGPT ad destination needs its own explanation even when the campaign uses location targeting.
OpenAI describes geographic targeting as part of determining which users are eligible to receive a campaign’s ads. That does not establish where the customer wants the work performed. The destination therefore needs its own service-coverage check. This guide concerns the job location; the wider connection between the advertised offer and its destination is covered in the ChatGPT ad landing-page guide.
The question is where the work happens
For a fictional equipment-repair company, the useful first question is “Where is the equipment that needs the visit?” Asking “Where are you?” can produce a home address, a headquarters address or the user’s present location. That ambiguity can survive until someone calls the customer.
Decide what information determines eligibility. If the business works within a clear set of postal areas, a postal code may be enough for an initial check. If coverage depends on the precise property or travel access, say that the initial answer is provisional. Do not ask for a complete address merely because the form component already contains those fields.
Place the check before lengthy questions about the repair. A customer outside the service area should not have to describe a fault, upload photographs and provide contact details to discover that a visit is unavailable. At the same time, do not block all useful information behind the checker. State the broad coverage in readable text.
Establish which service the coverage list describes. Installation, routine maintenance and emergency visits may have different boundaries within one business. If the ChatGPT ad offers maintenance, use the maintenance coverage rules and retain that service choice when the customer continues. A general statement that the company operates in the region is too broad if the advertised service cannot be supplied at the requested location.
Design three results, not two
A simple yes-or-no checker often has no honest answer for boundary cases. Use separate outcomes for supported, unsupported and needs-review locations. The wording should reflect what the system actually knows.
Supported: “We accept visit enquiries for this area. Describe the equipment and the issue so we can review the job.” This confirms coverage without promising an appointment, a response time or the suitability of the repair.
Unsupported: “We do not currently offer visits at this location.” If there is a genuine remote alternative, explain what it can do. If there is no alternative, say so without sending the customer through a form that cannot lead to the advertised service.
Needs review: “This address needs a coverage check before we can offer a visit.” Explain the small amount of information needed and which contact route handles the check. Do not label a location unsupported simply because the lookup did not recognise its formatting.
These are example messages. The real wording depends on the business’s process and supported coverage. A useful checker distinguishes commercial coverage from technical lookup failure.
A recognised address at an operational boundary needs a coverage review. An address the lookup cannot recognise first needs a correction or another way to enter the location. If the lookup service itself does not respond, say that the check could not be completed. Preserve the entered location and offer a working contact route if one exists. None of these technical outcomes establishes that the business does not serve the area.
Three coverage outcomes and an incomplete lookup
- Covered
Describe the job. An appointment is not yet confirmed.
- Not covered
Explain that visits are unavailable there.
- Boundary case
The location is found, but coverage needs review.
- Lookup fails
Correct or retry. Coverage has not been established.
Keep the boundary explanation near the result
Service areas are not always circles on a map. A company may serve some postcodes but exclude a location with access constraints. It may provide remote work nationally and visits only locally. A decorative map can conceal those distinctions.
Use a short list or clear text for the main rule, with a map as supporting information if it adds value. Name genuine exceptions without making the visitor infer them from a faint shaded edge. Explain separately whether travel costs vary; coverage and price are related but different questions.
If the result is provisional, repeat that qualification before the customer submits the enquiry. The initial green result should not become a promise of a confirmed booking merely because the next screen has a calendar. The guide to booking without available slots addresses the separate availability problem.
Follow the ChatGPT ad journey through the check
Suppose the ad offers on-site equipment repair, but the destination detects an unsupported postcode and promotes remote troubleshooting instead. That alternative might help, but it must be labelled as a different service. Quietly keeping the same headline while changing the fulfilment model confuses the offer.
Review every advertised region against the destination’s current coverage rules. The check is a final customer-facing safeguard, not a reason to leave an obviously mismatched offer unchanged. If the company expands or contracts its coverage, update the page and review the ads using it together.
Test locations just inside and outside the boundary, a recognised location with unusual formatting, and an address that the checker cannot resolve. Let visitors correct their input. See address entry for the field interaction itself; the concern here is what the coverage decision means.
Also try entering a supported location and then changing it. The earlier result needs to be checked again before the enquiry is sent. The summary should show the location actually evaluated, rather than the customer’s first entry. Otherwise, a valid coverage result can arrive with a different job address and mislead the team planning the visit.
A small operating record prevents stale answers
Keep the coverage definition somewhere the service team can maintain. Record the owner, the date of the last change and any temporary exceptions that affect new enquiries. Avoid copying slightly different lists into multiple page builders without an owner for reconciliation.
Ask the team handling enquiries to flag cases where a “supported” result could not actually be fulfilled. Review the cause rather than assuming every problem is a targeting issue. The error may be an outdated coverage list, an ambiguous location question or an availability restriction that the page never explained. A good coverage check saves the customer from an unnecessary form while preserving a clear route for genuinely uncertain cases.
Sources and scope
Checking the location where the advertised service will be performed before requesting a detailed enquiry.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.