If you run a group lactation practice with multiple providers covering different geographic areas, you probably know this problem well: a new client texts you, tells you where they live, and someone on your team has to figure out which provider covers that neighborhood, and whether they have anything available in the next week or two.
This guide describes how to build two versions of a searchable provider lookup tool using AI: one for your admin to use internally, and one to embed on your public website. Neither requires coding experience. Both are built with Claude.
Here’s what the finished tools do, what to ask for, and what information you need to have ready before you start.
What the tools do
The internal tool (for your admin) is a browser-based lookup that lets your admin search by zip code or neighborhood name and instantly see which providers cover that area, with a direct link to each provider’s booking page. It includes a reminder panel with your key scheduling policies (booking windows, referral timelines, priority order) so your admin doesn’t have to hold all of that in their head.
The public tool (for your website) is a client-facing version of the same concept. A prospective client types in their neighborhood or zip code and sees whether you cover their area, with a prominent button to see the soonest available appointment. If you don’t cover their area, it surfaces your office location as an alternative and offers a warm redirect to contact you for a referral.
Both tools run entirely in the browser. No login, no database, no subscription. The data lives inside the HTML file itself.
What you need before you start
Gather this information before your first conversation with Claude. The more specific you are upfront, the less back-and-forth you’ll need.
For each provider:
- Full name and credentials
- The specific neighborhoods or towns they cover for home visits (not general descriptions, actual neighborhood names)
- Zip codes for those areas, if you have them
- Their individual booking page URL (from your scheduling platform (IntakeQ, Jane, Acuity, etc.))
- Any notes that affect booking: languages spoken, case-by-case areas, travel fees, etc.
For your practice:
- Your office address, if you have one
- Your general booking URL (the page that shows all providers)
- Your scheduling policies: new client booking window, how far out before you refer out, priority order (in-network first? Established clients? etc.)
- Your contact method for clients who have questions (phone, text, email)
For the public version:
- Your website’s font names (heading font and body font)
- Your brand colors (hex codes work best, find these in your website builder’s style settings)
- The phone number or text line clients should use if they have questions
How to prompt Claude
You don’t need to give Claude everything at once. The conversation can be iterative, and for a project like this, it should be.
Start with the concept and your constraints:
“I run a group lactation practice with [X] providers doing home visits across [geography]. We use [scheduling platform] for online booking. I want to build a simple browser-based tool my admin can use to look up which provider covers a client’s location and get a direct booking link. Please ask me clarifying questions before building anything.”
Letting Claude ask clarifying questions first saves significant time. It will surface things you haven’t thought about, like how you want to handle border zones, what happens when there’s no coverage, and whether the tool needs to show scheduling policies or just provider names.
Once you’ve answered the questions, give Claude your provider data one provider at a time:
“Here are the neighborhoods for [Provider Name]: [list]. Their booking URL is [URL].”
Repeat for each provider. Claude will update the tool as you go. If your providers have individual pages on your website that list their service areas, you can share those URLs and Claude will read them directly rather than making you type everything out.
For the public version, share your branding:
“I’d like a public-facing version that matches our website branding. Our heading font is [font], body font is [font], and our main brand color is [hex code]. It should always show our office as an option, and have a prominent ‘see soonest availability’ button when we do cover the client’s area.”
To refine the results:
“When someone searches [neighborhood], I want [Provider Name] to come up first.”
“Please add [town name] to [Provider Name]’s coverage area (it’s near [existing town]).”
“Remove the note that says [text] from [Provider Name]’s card.”
Claude keeps both files in sync. Any change you request gets applied to both the internal and public versions unless you specify otherwise.
Key requirements to include in your prompts
These are the things that make the tool genuinely useful rather than just a fancy contact page. Include them explicitly.
Word-boundary search matching. The default AI-generated search logic uses substring matching, which causes false positives: a search for “Garden City” will surface a provider who covers “Kew Gardens” because “garden” appears in both. Ask Claude to use word-boundary matching so searches only match at the start of a word.
“Please make sure the search uses word-boundary matching, not substring matching.”
Priority pinning for specific neighborhoods. If certain neighborhoods are strongly associated with a specific provider (their home base, their specialty area, or the area where they have the most capacity), you can pin that provider to appear first in results for those searches.
“When someone searches Bushwick or Bed Stuy, I want [Provider Name] to appear first.”
Border zone handling. When multiple providers cover the same area, the tool should flag this and show all of them. For the internal version, include language that tells your admin to check cross streets and pick the soonest slot. For the public version, keep the language client-friendly.
The office as a permanent fallback. If you have a physical office that clients can visit regardless of where they live, it should appear at the bottom of every search result, not just when there’s no coverage. This keeps the office visible as an option even when home visits are available.
A warm no-coverage message. When a client searches an area you don’t cover, the tool should acknowledge that clearly but not leave them stranded. Include your contact information and, if relevant, a note that you can provide referrals.
Scheduling policy reminders (internal tool only). Your admin shouldn’t have to remember your booking window, referral timeline, or priority rules from scratch every time. Include these as a persistent reminder panel at the bottom of the internal tool.
Deployment options
For internal use: The simplest option is to host the HTML file as a Google Apps Script web app and embed it in Google Sites. Your admin bookmarks the Google Sites page and it’s available in any browser. When you need to update the tool, you paste the new HTML into Apps Script, deploy a new version, and the link updates automatically.
The four-step Apps Script setup:
- Go to script.google.com and create a new project
- Add an HTML file named
indexand paste the tool’s HTML into it - In
Code.gs, paste:function doGet() { return HtmlService.createHtmlOutputFromFile('index').setTitle('Provider Lookup').setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL); } - Deploy as a web app with access set to “Anyone within [your organization]”
For your website: The public version is structured to paste directly into a WordPress Custom HTML block (no iframe needed, no external hosting required). The fonts and colors are embedded in the file, so it will match your branding as long as you provided accurate values when you built it.
If your website uses a different platform, the file can also be hosted on Netlify Drop (drag and drop, free, takes about a minute) and embedded via iframe.
Keeping it current
The tool is only as accurate as the data inside it. A few things to plan for:
When a provider’s service area changes: Come back to Claude, share the updated neighborhood list, and ask Claude to update both files. Claude will confirm what changed and what was already there.
When a new provider joins: Give Claude their name, credentials, service areas, and booking URL. Claude will add them to both files and flag any border zones with existing providers.
When a provider leaves: Ask Claude to remove them. The tool updates in under a minute.
When booking URLs change: Share the new URL and Claude will update it. If your scheduling platform generates individual provider booking pages, check that the URLs are stable (i.e., not session-based or time-limited) before building the tool around them.
Border towns that come up in practice: When a client asks about a neighborhood that isn’t listed but is near your coverage area, add it. Tell Claude the town name, which provider it’s closest to, and whether it should be a confirmed or “text to confirm” listing. Over time, your tool becomes more accurate than your website because it reflects the real edge cases you’ve encountered.
A note on what this tool doesn’t do
This tool does not check live availability. It tells your admin (or your client) which providers to check (it doesn’t pull real-time calendar data from your scheduling platform. from your scheduling platform). Your admin still needs to open the booking page. The value of the tool is the triage step: going from “client in Sunnyside” to “check Patricia and Saarika” in three seconds instead of thirty.
If your scheduling platform has an API and you want to build live availability into the tool, that’s a more complex project, but it’s a reasonable next step once the geography layer is working well.
Built with Claude at Anthropic. This guide was developed through an iterative build process with City Lactation, a group IBCLC practice based in Long Island City, New York.
