Reset Massage relied on its WordPress website and Amelia booking form to turn visitors into appointments. After a site refactor, caching was introduced to improve performance. The website still loaded, but the booking journey no longer worked properly.
This is exactly the kind of quiet failure that makes website monitoring difficult for a small business. The home page can look healthy while the part that earns revenue is broken.
The short version: the website refactor and new caching setup left Reset Massage with a broken booking experience. A customer could reach the site but could not reliably complete the expected booking steps. Pulse would not have rewritten the website automatically, but it would have detected the failed journey, shown where it stopped and confirmed when the repair worked.
Case study at a glance
| Business | Reset Massage |
|---|---|
| Website’s job | Let customers choose and book massage appointments |
| Booking system | Amelia on WordPress |
| What changed | The website was refactored and caching was introduced |
| What failed | An important part of the booking form stopped working correctly |
| Why it was easy to miss | The website and booking page still loaded |
| Business risk | Customers could abandon bookings without reporting the problem |
The situation
Reset Massage is the kind of appointment-led business where the website is part of the front desk. Customers do not only read about treatments; they use the site to choose a service, find an appointment and move through the booking form.
The site refactor was intended to improve and reorganise the website. Caching was added as part of that work so pages could be delivered more quickly. That is a common and often sensible change, but interactive booking systems do not always behave like ordinary pages.
What went wrong
Following the refactor, the caching setup interfered with Amelia. On some customer journeys, an important phone-number field did not appear correctly. The page itself opened and much of the booking interface was visible, yet the customer could not rely on the full process working as intended.
The fault sat in the gap between “the page loaded” and “the customer could book”. A simple website check would see a working web address. Even a person glancing at the page might see the calendar and assume everything was fine.
Why the problem was easy to miss
Caching problems can be inconsistent. A site owner may see a fresh version while a customer receives an older or incomplete one. The result can also vary by device, browser or the route used to reach the form.
That makes occasional manual testing a weak safety net. Unless someone follows the same steps at the right time and under the affected conditions, the fault can remain hidden.
What it meant for the business
For an appointment business, the cost is not a technical error message. It is an empty space in the diary. Customers who cannot book rarely investigate the cause or report it; many simply try another provider.
There was also a reputational risk. A booking form that almost works can feel less trustworthy than a website that is clearly unavailable because the customer has already invested time choosing a service and appointment.
How Pulse would have changed the outcome
Pulse would have been configured around the actual Reset Massage booking journey rather than only the website address. On an agreed schedule, it could open the site, enter the booking route, confirm that the required controls appeared and move through the safe pre-booking steps.
When the phone field disappeared or the journey could not continue, Pulse would have marked the check as failed and retained useful evidence such as the affected step and an available screenshot. That would give the person maintaining the site a direct place to start.
Pulse would not silently change the cache or edit Amelia on its own. The repair would still belong to the website maintainer—for example, reviewing what the cache stored or excluding the booking experience from unsuitable caching. Pulse’s role would be to find the problem early and then confirm that the customer journey worked again after the change.
What Pulse would check
- The booking page opens and Amelia appears.
- The agreed service and appointment controls are available.
- Required customer fields, including the phone field, are visible.
- The journey can progress to the agreed stopping point without creating a real appointment.
- A repaired journey passes again after the website change.
The practical takeaway
A faster website is only an improvement if customers can still use it. Any refactor, performance plugin or caching change should be followed by a test of the complete business journey—not just the home page.
Reset Massage helped shape the central idea behind Pulse: a website can be online and still be failing the business behind it.
Frequently asked questions
Does caching always break Amelia?
No. Caching is widely used and can improve website speed. Problems usually depend on the particular website, cache rules, Amelia setup and other software in use. The lesson is to test the booking journey after a change rather than assume every setup behaves the same way.
Would a normal uptime checker have caught this?
Often not. A basic checker may only confirm that the page responds. In this case, the page loaded; the problem appeared inside the steps a customer needed to use.
Would Pulse make a real booking?
The current Browser service normally stops at an agreed safe point before creating a real appointment. Any future controlled booking and cleanup process would need to be agreed separately.
About this case study
This case study is based on first-hand website work carried out by Jamie for Reset Massage. It explains the failure pattern and how Pulse would have monitored it; it does not claim that Pulse was installed when the incident occurred or that monitoring can prevent every website fault.
What important website journey would you miss?
Pulse checks the pages and customer steps your business depends on. We agree what matters, set up the checks for you and explain failures in plain English.