Frontdesk

A single-script-tag AI chat widget for local business websites - answers common patient/customer questions (hours, services, booking, location), captures leads it can't answer, hands off anything urgent to a phone call. Sold direct as a monthly subscription - no marketplace cut.

First target: West London Dental Centres (dentistw4.co.uk), Chiswick.

Future idea: a premium tier that takes payment in-chat (not built yet)

Instead of just capturing a lead for the business to follow up on, Sia closes the transaction herself - customer books and pays right in the widget. Noted here so it doesn't get lost, deliberately not scoped for now - it's a materially bigger build than anything else in this project:

• Needs real availability/calendar data, not just FAQ config - can't sell a slot without knowing what's actually free.
• Needs Stripe Connect, not a simple Payment Link - money has to land in each business's own account, so every client onboards their own connected Stripe account (KYC, payouts) and the backend routes to the right one per transaction.
• Raises the error budget a lot - a bug here means misplaced money or a double-booked slot, not just a missed FAQ answer, so it needs more careful building/testing than anything shipped so far.

Right sequencing: after client #1 is real and paying, not before. Also a legitimate premium-tier price justification once it exists - "closes sales while you sleep" is worth noticeably more than £45/mo.

Future idea: give Claude read-only Stripe access (not built yet)

Once there are real paying clients, it'd be useful for Claude to answer things like "how many are actually paying right now," "did anyone's payment fail this month," "what's MRR" - direct reporting instead of digging through the Stripe dashboard by hand.

How, when we get there: a Stripe Restricted API key, scoped to read-only on Payment Links / Subscriptions / Charges specifically. No refund, payout, transfer, or account-settings permissions on that key - ever. Stored the same way as the other secrets (env var, never pasted loosely in chat).

Hard line, not just a preference: anything write/mutating - issuing a refund, cancelling a client's subscription, changing payout details, creating new pricing products - stays prepare-but-don't-execute even with that key in hand. Claude drafts the action, a person clicks confirm. This isn't extra caution for its own sake - it's the same boundary Claude already operates under around moving money, and it matches Stripe's own least-privilege guidance for exactly this kind of access.

Timing: not urgent - nothing to report on with zero paying clients. Worth doing once there's real subscription activity to actually watch.

Future idea: further AI cost-reduction levers (not built yet)

api/chat.js's system prompt is cache_control-marked and confirmed working (see "What's built" below), but testing found Haiku's minimum cacheable prompt size sits above what a typical business's config actually reaches even with the new 1000-char training text - so this is correctly wired for the businesses with the largest configs, not a general win yet. Real levers still on the table, logged here for later once there's volume to justify the complexity:

• A business with an unusually large config is exactly who caching already helps today - worth knowing which real clients are on the bigger end of FAQ/training-text usage, since they're the ones actually seeing the discount right now without any further work.
• Model routing - a lot of questions are simple lookups ("what are your hours") that don't need a full Haiku call at all; a cheap keyword pre-check that only calls the AI for genuinely open-ended questions would cut volume further. Real complexity/accuracy trade-off - only worth it once token cost is actually a line item that matters.
• Per-business usage visibility - right now there's no per-client view of how many messages/tokens a business is generating. Useful both for cost tracking and for catching one client accidentally driving disproportionate usage (or abuse) before it shows up as a surprise bill.
• Batch processing (Anthropic offers ~50% off for non-real-time batched requests) - not applicable to live chat itself, but could apply to something like a nightly "summarize missed questions" digest if that ever gets built.
• Longer/tiered caching - if Anthropic offers longer cache TTLs than the default ephemeral window, worth revisiting once a business's traffic pattern is well understood (bursty during business hours vs. spread evenly changes what a longer cache window is actually worth).

Bug fixes from real usage feedback

• Bot replies invisible on some host pages - a real gap in the isolation promise. .fd-msg.fd-bot never set its own text color, so it silently inherited whatever color the host page uses - color is an inherited CSS property and crosses the Shadow DOM boundary unless explicitly reset, unlike the non-inherited properties Shadow DOM blocks automatically. On a dark host page with light body text (exactly what our own site is), that leaked straight into the widget's white message bubbles, producing near-invisible light-on-white text - confirmed from a real screenshot, then reproduced and fixed: added color: #1a1a1a to .fd-root as an explicit baseline. Verified against the exact reported case (computed color was rgb(26, 26, 26) on white afterward, confirmed visually too).
• Contrast bug, real not hypothetical. White text on the accent color was hardcoded everywhere (header, buttons, user messages). Turns out even the new default coral (#ff7a59) only has a 2.6:1 contrast ratio with white - fails WCAG AA, and any pale custom color (tested with #f5e6a8) made text nearly invisible. Fixed with contrastTextColor()
  • computes perceived brightness of whatever accent color is set and picks white or dark text automatically. Verified against the exact failing pale-yellow case: correctly switched to #1a1a1a.
• No feedback on buttons/pricing cards. The pricing plan cards had literally no click target - clicking them did nothing because there was nothing to click. Added real .plan-cta buttons to both plans, plus hover/active states (lift + brightness on hover, press-down on click) across every button on the site, not just the new ones.
• No pay button - correctly diagnosed, not a bug. There's genuinely no checkout yet; Stripe still isn't connected. Added working "Get started" / "Ask about setup" buttons that open a pre-filled email for now, so clicking does something real instead of nothing - swap the href to the real Stripe Payment Link the moment it exists.

Drawing the eye before it's opened

The closed bubble used to just sit there statically. Now: pops in with a little spring on page load, a soft breathing glow while idle (color-matched to each business's own accent color via color-mix()), an irregular blink on Sia's drawn eyes (only the default face - never animates a business's own uploaded logo), and a one-time, dismissible teaser bubble ("👋 Got a question? I'm Sia.") that appears after ~4.5s and auto-hides after 9s if ignored. All of it stops the instant someone actually opens the panel - the goal is a first glance, not a nagging loop. Verified the full lifecycle live: pop-in and pulse active on load, teaser appears on schedule, and clicking it opens the panel, stops all animation, and removes the teaser cleanly.

Visual identity - "Sia"

The widget was competent but generic - looked like every other blue SaaS chat bubble (Intercom, Drift, Tawk.to). Redesigned around an actual identity instead of a chat icon: every install's assistant is named "Sia" by default (theme.assistantName to override), with a warm illustrated face (inline SVG, not a fake stock-photo human - honestly not-a-real-person, but alive and friendly) rather than a generic speech-bubble outline. The panel now has a rounded speech-bubble tail connecting it back to the bubble it came from, softer corners throughout, and a warm coral default accent (#ff7a59) instead of corporate blue - though a business's own brand color, once set, always wins. Verified backward-compatible: the existing dentist config (no assistantName, no avatarUrl) picked up the new defaults automatically while keeping their own blue accent color untouched.

What's built

• Core receptionist behaviour separated from business-specific knowledge. api/chat.js's buildSystemPrompt() - the single function used for every business, preview and committed alike - was purely reactive: answer if the fact was in the business's own "teach your AI" text, otherwise punt to a human. Restructured into two explicit blocks: a CORE behaviour section (answer first, then keep the conversation moving; ask one relevant follow-up at a time rather than interrogating; build up intent gradually; once there's a real opportunity, naturally offer the business's actual conversion action - booking, a call-out, a viewing, an enquiry - instead of a generic "leave your details"; never ask for contact info prematurely or more than once) that's identical for every business and can't be overridden by their own supplied text, and a BUSINESS-SPECIFIC KNOWLEDGE section (unchanged in spirit) for facts only. Added a type field (the existing onboarding "what do you do?" selection, previously only baked into greeting text and then discarded) through shared/build-config.js and both config sanitizers so the core behaviour knows which conversion action to name per business. Verified live against the demo config with the exact "leaking taps" scenario this was designed around - it answered first, asked one relevant follow-up about urgency, and only asked for a callback number once the visitor confirmed they wanted it fixed that day.
• Weekly digest email (api/weekly-digest.js). A Vercel Cron job (vercel.json's crons, Mondays 9am UTC) emails every active business a summary of leads their receptionist captured that week, so the value stays visible after the sale instead of going quiet - a real churn risk otherwise. Scoped deliberately to lead counts, not raw chat-message volume: leads are rare enough that logging one commit per lead (api/_lib/leadLog.js, reusing the existing GitHub-Contents-API pattern under api/_private-configs/leads/{key}.json - never publicly reachable, same reasoning as notifyEmail) is a reasonable fit, but tracking every chat message is not; that would need a real counter store (Vercel KV / Upstash) rather than a commit per event. api/lead.js now logs alongside (in parallel with, never blocking) the real Resend notification. The cron endpoint itself is protected by CRON_SECRET, which Vercel automatically sends as a Bearer token on scheduled invocations.
• Config privacy fix: business contact emails were publicly readable. configs/{key}.json is served to the public internet as-is (the widget fetches it client-side), so notifyEmail had no business living there - proved it live with a plain curl against a real (test) client's config. First fix attempt (a rewrite to 404 a path) silently didn't work - Vercel serves an existing static file at a matching path before ever consulting rewrites. Fixed properly by moving private data under instead () - anything there is never served as a static file at all, a real guarantee rather than a routing rule a file can shadow. Re-verified live after the correction.

Deliberate scope decisions (read before extending)

• AI backend is built but needs your API key to go live. Until then, the widget runs on local keyword-matched FAQs (same safe fallback it uses if the AI backend is ever down). A public, unauthenticated AI endpoint is a real cost/abuse surface, which is why it's scoped tightly: system prompt locked to this business's own info, medical questions always redirected rather than answered, input/history/rate caps server-side, and a hard spending cap you set directly in the Anthropic console as the real backstop. Full detail in SECURITY.md.
• No medical/triage behavior. Anything that sounds like pain, an emergency, or a symptom is redirected to "please call" rather than answered - both a liability and regulatory boundary, deliberately kept out of scope for a healthcare client.
• Config-driven, not per-client-forked. New prospects = a new JSON config, not a new copy of the widget code. Keep it that way as more demos get built.
• Committed-to-git configs, not a database, for now. Automated signup publishes configs by committing to this repo rather than provisioning a real datastore - zero new paid infrastructure, reuses the exact pipeline that already publishes every hand-written config, at the cost of a ~1-2 minute delay after payment before a business's config is actually live (handled honestly with a wait screen on site/success.html, not a fake instant success). Worth revisiting for a real database once signup volume makes that delay or the "each signup triggers a redeploy" pattern a genuine problem, not before.
• Uploaded avatars live in configs/avatars/ forever, with no cleanup path yet. Every photo ever uploaded through the self-serve tool gets committed and stays, even if that visitor never actually pays - low volume makes this a non-issue today, but worth a cleanup job (delete orphaned uploads with no matching config after some window) once there's real traffic through this tool.

What needs you, next

1. Create an Anthropic API account (console.anthropic.com), add billing, and - importantly - set a hard monthly spending cap there before this goes live. Share the API key with me only as an env var (never in chat) so I can set it in Vercel.
2. Create a Resend account (resend.com, free tier available) for lead notification emails, and verify a sending domain there. Share the API key the same way - env var, never in chat.
3. Fill in the dentist's real notification email - configs/ dentistw4.json currently has a placeholder (TODO-add-real-contact- [email protected]) since I don't have their real one from the public site. Needs a real address before this goes live for them.
4. Deploy to Vercel (same GitHub → Vercel pattern as rush-app and miser-ai) - api/chat.js and api/lead.js both need Vercel specifically (or another Node serverless host), not a plain static host.
5. Set up Stripe for Frontdesk specifically (separate from anything set up for miser-ai). The original static Payment Link was enough to start; automated trial signup (see below) now needs real API access instead.
6. Check for a named contact (practice manager/owner) before sending the outreach email - noted in the draft.
7. Review and send the email yourself - I don't send messages on your behalf without you reviewing them first.
8. Find the Price ID behind the existing £45/mo product - Stripe Dashboard → that product → copy the price_... id (don't create a new product) - into STRIPE_PRICE_ID.
9. Add a Stripe webhook endpoint at https://<your-domain>/api/stripe- webhook, subscribed to checkout.session.completed, customer. subscription.updated, and customer.subscription.deleted - copy its signing secret into STRIPE_WEBHOOK_SECRET. Do this after the first deploy with the new code, since the endpoint needs to exist first.
10. Create a GitHub fine-grained personal access token, scoped to only this repo, Contents: Read & Write and nothing else - into GITHUB_TOKEN (plus GITHUB_OWNER/GITHUB_REPO). Fine-grained tokens expire (max 1 year) - worth a calendar reminder to rotate it.
11. Decide on Stripe's dunning/retry settings (Billing settings) - how many times a failed renewal charge retries before the subscription is marked cancelled controls how fast a client's bot goes dark after a card fails. A business/legal call, not a coding one.