Stop repeating the action
When something appears stuck, do not keep pressing the same button.
Repeated attempts can create duplicate messages, payments, appointments, or records if the first request reached the system but the response did not reach you. They can also make the sequence harder to understand when you later ask for help.
Pause and record three simple facts:
- what you were trying to do;
- what happened on the screen; and
- the approximate time it happened.
If there is an error message or reference number, copy the exact wording. Do not include client health information in an ordinary note, screenshot, or support email. You need enough detail to identify the failed step, not a copy of the client record behind it.
Separate one device from the whole service
Start with the smallest explanation and work outward.
Open a familiar, unrelated website in a new tab. If that also fails, your connection may be the problem. If possible, check from a second device on a different connection, such as a phone using cellular data instead of the practice Wi-Fi.
Then ask what is actually affected:
- Is one page failing, or can you not sign in at all?
- Can another team member reach the same area?
- Can a client open the booking page even though your dashboard is slow?
- Does the problem happen in another supported browser?
- Did the issue begin after the device changed networks, woke from sleep, or installed an update?
This is not a long troubleshooting exercise. Two or three checks are enough to tell you whether the problem follows one device, one network, one account, or a wider part of the service.
Check the official status page
An official status page should tell you whether the provider is seeing a wider incident, which services are affected, when the latest check ran, and whether the situation is still being investigated.
Read the individual service rows, not only the headline. Online booking may be working while the practice dashboard is having trouble. Video visits may be available while notifications are delayed. The status that matters is the one connected to the task in front of you.
Also look at the time of the latest check. A current result is more useful than a green label that has not refreshed. If the page reports an active incident, follow the updates there rather than repeatedly testing the same client workflow.
A status page is evidence, not a guarantee about your individual session. If it says everything is operating normally and your problem continues, keep the facts you recorded and move to support. Your issue may be real even when it is not widespread.
Protect the next client, not the whole week
Once you know the likely scope, make the smallest safe decision for the next appointment.
For an in-person visit, you may need only a temporary way to confirm the time and record that payment or documentation will be completed in the approved system when access returns. For a video visit, use the backup process your practice has already approved. For online booking trouble, you may need to hold one requested time rather than opening a second calendar that your team cannot reconcile later.
Avoid exporting client details into a personal note app, sending clinical information through an unapproved channel, or building a shadow spreadsheet because the usual screen is unavailable. A short interruption does not make an unsafe tool appropriate.
If the problem affects a client, tell them only what they need to know. For example:
We are having trouble with the appointment link right now. Your appointment is still held for 2:00 p.m. I will send the next step by 1:30 p.m.
That message confirms the appointment, names the practical problem, and gives a time for the next update. It does not ask the client to diagnose your software or keep trying the same broken link.
Use a small fallback plan
A useful fallback plan fits on one page and covers the workflows that cannot simply wait.
For each essential area, decide:
- who makes the call;
- how long you wait before using the fallback;
- which approved tool or process you use;
- what information must stay out of that process; and
- how the work returns to the main system afterward.
Keep the list short. Appointments, client contact, urgent billing questions, and the ability to reach the day's records may deserve a plan. Website edits and monthly reports can usually wait.
Name one person who watches the status page and shares updates with the team. Ten people refreshing the same screen do not create more certainty. One owner, one update channel, and one time for the next decision keep the practice from improvising in several directions at once.
Report the problem without sending private details
If the status page shows no incident, contact support with a compact report:
- the page or feature you were using;
- the action you took;
- the exact error or visible result;
- the time and time zone;
- the browser and device;
- whether another connection or device behaved differently; and
- whether the problem is still happening.
Use a fictional or test record for screenshots when possible. Crop out unrelated tabs, client names, messages, form answers, and appointment details. Never send a password, one-time code, magic link, recovery code, or full payment information.
A precise report gives support something they can trace. A message that says only "the system is down" leaves them trying to discover the same boundaries you could identify in the first five minutes.
Reconcile before you resume
When access returns, do not immediately repeat every action you attempted during the interruption.
First check whether the original save, message, booking, charge, or form submission completed. Then bring any approved fallback work back into the main record, remove temporary copies according to your practice policy, and tell the team the normal workflow has resumed.
If client-facing information changed, confirm the final version once. One clear appointment time is better than a stream of corrections sent while the system was recovering.
Finally, note what your practice learned. You may need to bookmark the status page, update a video-visit backup step, keep a support template, or clarify who makes schedule decisions during an incident. Fix the smallest missing part while the experience is still fresh.
Stillpoint's public status page checks its core services every minute from outside Stillpoint's own servers and shows 90 days of history by service. Bookmark it before you need it. If the page says services are operating normally but your problem remains, send the short, privacy-safe report to support instead of rebuilding the day around an assumption.
