Begin with the result you expected
Start with one sentence that names the job you were trying to finish.
For example:
- I was trying to send an invoice after marking an appointment complete.
- I expected a submitted intake form to appear in the review queue.
- I was adding availability for one practitioner at one location.
- I was trying to reschedule an appointment from the calendar.
Then say what happened instead.
I selected Send, the button returned to its normal state, and no confirmation appeared. The invoice still shows as unsent.
That is more useful than "invoices are broken." It gives support a specific action, a visible result, and a place to begin. It also keeps the first message focused on the workflow instead of the person connected to it.
If you saw an error, copy the exact error wording or reference ID. Do not translate it into what you think it means. The original wording may point to a very different cause than your guess.
Record the safe context around the problem
A support request needs context, but context is not the same as a client history.
Include details such as:
- the page or section you were using;
- the approximate time and your time zone;
- whether you were on a phone, tablet, or computer;
- the browser you were using;
- the role you were signed in with, such as owner, scheduler, or practitioner;
- the steps you took immediately before the problem; and
- whether the problem happens every time or happened once.
These details help someone trace the path without knowing a diagnosis, treatment plan, full date of birth, home address, or the substance of a private message.
If the timing matters, give a narrow window: "around 2:15 p.m. Pacific" is usually more helpful than "this afternoon." If more than one team member saw it, say which role each person had rather than forwarding a long internal conversation.
Try the same action with neutral information
Before you attach a real client record, see whether you can reproduce the problem with a test client, a draft item, or a neutral example.
You might create a test client called "Sample Client," use an unused future time, or open a draft that contains no clinical information. Repeat only the safe steps that led to the problem. Do not alter a real appointment, payment, claim, or clinical record just to make a cleaner screenshot.
If the same problem appears with neutral information, you have learned something useful. The issue is probably tied to the workflow rather than the contents of one client's record. You can send the safe example and describe the original item only as "a client appointment" or "a submitted form."
If the problem appears only on one real record, do not paste the whole record into the first message. Say that the issue seems record-specific and ask what approved, secure route support wants you to use for the minimum necessary detail.
Make the screenshot safe before you capture it
A screenshot can reveal more than the part you meant to show.
Before taking one, look at the whole frame. Check the page header, browser tabs, notifications, sidebar, search field, recent-client list, calendar labels, and any other window visible behind the product. A careful crop after capture does not help if the original image has already been copied into a shared clipboard, team chat, or downloads folder.
When possible, navigate to the smallest useful view first. Close unrelated tabs and panels. Use a test record. Capture the button, error, or empty state that matters, with just enough surrounding layout to show where it appeared.
Do not cover names by drawing a loose line over them. Markup can miss part of the text, and some file formats preserve layers or editing history. A fresh screenshot of a neutral example is simpler and safer.
If a screen cannot be made safe, describe it in words. A screenshot is helpful evidence, not a requirement.
Keep passwords and one-time codes out of every message
Support does not need your password, magic sign-in link, recovery code, or one-time authentication code to understand a product problem.
Do not send those details by email, chat, form, or screenshot. Do not approve a sign-in request you did not start. If someone claiming to be support asks for a secret that would let them sign in as you, stop and use the official support route published inside the product or on the company's real website.
There is an important difference between describing your access and handing it over. "I am signed in as an owner and the Billing page is blank" is useful. A password is not.
If the issue involves an unexpected sign-in, changed permissions, missing records, or a payment you do not recognize, say that at the top of the message. Security and money problems need to be triaged differently from a button that will not save a colour choice.
Give support a short path they can repeat
A good report lets another person walk the same route.
Write the steps in order:
- Open Calendar.
- Select a future appointment.
- Choose Reschedule.
- Pick an available time and save.
- The panel closes, but the original time remains.
Keep the list to the actions that matter. You do not need to describe signing in, opening your laptop, or every page you visited earlier that day unless one of those steps changes the result.
Then add one sentence about scope:
This happened twice for an owner account in Chrome on a laptop. A scheduler account could complete the same action.
That final comparison can reveal a role, browser, or device difference without adding client information.
Separate the urgent workaround from the permanent fix
Sometimes you need help with two different things: finishing today's work and preventing the problem from returning.
Name both.
I need a safe way to send this invoice today. I would also like to know why Send is failing so we can avoid the same problem tomorrow.
Support may be able to offer a temporary path while the underlying issue is investigated. If the workaround touches payments, appointments, claims, clinical records, or client communication, confirm exactly what it changes before you use it. Avoid repeating a failed action quickly when it could create a duplicate charge, message, or booking.
Once the immediate task is complete, keep the original report open until the permanent answer is clear. Record any corrected setting or team step in the place where your practice keeps operational instructions, without copying client details into that note.
Use a small template for the next problem
You can make support requests easier by keeping a short internal template:
Trying to: [the job you needed to finish]
Expected: [the result you expected]
Instead: [what happened, including exact error wording]
When and where: [time, time zone, page, device, browser, role]
Steps: [the shortest safe path that reproduces it]
Scope: [once or repeatable, one role or several]
Urgency: [what must happen today, if anything]
Use neutral information whenever you can. If record-specific detail is truly needed, wait for the approved route and send only the part required to investigate.
The aim is not to make support guess. It is to give them the clearest useful evidence without turning a product question into another place where client information lives.
Stillpoint's in-app Help area gives you product articles and an official way to contact the support team. Stillpoint also uses role-based access and audit trails for client records. If you are reviewing how your practice keeps sensitive information in the right place, you can see Stillpoint's privacy and security tools.
