The Website Built for the On-Call Rotation

We were replacing a WordPress site and its WooCommerce store for Phoneware, a cloud business phone provider. Between that first version and the production cutover, we rebuilt the store from the product catalog, moved the support library, and connected search and an AI concierge. Calling that work polish would understate what was still missing.

The constraint was what happened after the rebuild. Phoneware’s team needed to maintain the site without depending on us for each edit. Customers needed a route from a question on a page to someone who could act on it. A finished set of pages answered neither requirement by itself.

Give the answer a destination

We built the concierge on Claude, with reference material compiled from the site’s content during the build. Product descriptions and help articles were exported from the same text used to publish them. We chose to search that collection in memory rather than operate a separate search database for the assistant.

That removes a separate content-copying job, but it also gives a mistake more than one place to appear. An outdated support page can become an outdated answer. The build keeps the sources together; someone still has to keep them correct.

A correction has to travel further than the page. The assistant needs to load the updated material, retrieve the relevant passage, and use it accurately. Suppose a setup instruction changes: checking the published guide establishes what the page says. Asking the concierge about that step checks what it tells a customer. If those disagree, the investigation moves to the material the assistant retrieved and how it used it. Editing an already-correct guide would miss the fault.

Grounding gives the model material to consult, not immunity from error. It can misread a passage or produce an answer the passage doesn’t support. Anthropic’s own guidance says hallucination-reduction techniques don’t eliminate the problem. A useful answer therefore has to leave room for a person to take over.

We connected the concierge to Microsoft Teams, with conversation mirroring and staff takeover in the same thread. Business-hours routing and a handoff of customer identity from portal sign-in supported that path. The emergency flow was designed to ask whether the visitor was an existing customer, then collect a name and callback number before the paging step. That confirmation supplies contact details; it doesn’t establish that a technician has received the request.

The website had acquired a support job. A conversation appearing in Teams still needs a staffer to pick it up, and a configured paging route needs a receipt at the other end. The evidence to look for is a staff reply reaching the visitor or an alert received by the person covering the rotation. We have no post-launch response-time comparison or documented customer resolution to report, so the effect on support remains an open question.

If visitors mainly need to reach support, a clear route into an already-staffed service can meet that need without a generated answer. The concierge adds a chance to resolve a question before the handoff, along with answers that need checking and another service to keep running. Those costs belong in the comparison even when the chatbot gives an impressive demonstration.

Keep the pages simpler than the conversation

For the pages, we chose Astro’s static build: it generates the page before a visitor requests it. A static page works like a printed page: the assembly happened before you asked. Serving the finished file avoids rebuilding a marketing page on every visit, while chat and account functions still rely on live services.

There is a maintenance tradeoff. Changing a static page requires another build and deployment, which makes the publishing workflow part of the editor’s experience. Moving work out of the visitor’s request only helps the owner if publishing the next correction remains manageable.

Static delivery also leaves plenty of ways to make a slow page: large images, heavy scripts, or a poor connection. Lighthouse performance scores vary with test conditions, so a good run would describe that run rather than every customer’s experience. Google also warns that good results in performance reports don’t guarantee a top search result.

The migration included mapping old WordPress addresses to their corresponding new pages and producing a new sitemap. A bookmarked setup guide still needs to lead to setup instructions after a redesign. Redirects preserve that route; any claim that the rebuild improved search traffic would need a separate traffic comparison.

The edit that proves the handoff

We built the editing workflow around Claude Code Desktop. The intended use is for a staff member to describe a change in ordinary language, have Claude prepare it, and inspect a preview. A pull request provides a reviewable record of the proposed edit and triggers a build with its own preview URL. Merging the change triggers deployment.

The preview gives someone who knows the product a place to check the result without reading code. A clean build can establish that the site can be generated. It cannot establish that a plan description is accurate or that Claude understood the requested change. We put editing instructions into a reusable skill for Claude, but the person reviewing the page still supplies the product knowledge those checks lack.

An existing content editor can meet the same need if staff can use it to make and check changes themselves. If they can already preview, publish, and correct routine edits without a developer, keeping that editor avoids an additional learning task. A coding agent adds generated changes for them to supervise. The case for our workflow rests on how well Phoneware can use it, rather than on replacing WordPress or adding AI as ends in themselves.

We don’t have an observed unaided staff edit to report here. The workflow was built for that purpose; independent content maintenance remains an outcome to demonstrate. When the next phone goes into the catalog, can the person responsible for it prepare the page, check the preview, publish it, and correct a mistake without asking us to finish the job?