Playbook, healthtech app
The person seen and the person billed are often not the same
Billing on a funded health product runs sideways. An employer or an insurer is invoiced for access, the person who used it never sees an amount, and the receipts that do reach individuals are usually being sent onward to somebody else's claims department. What all of them have in common is that a health document travelling to a third party has to be careful about what it says.
Why this is not the general answer
The handling pattern for billing and invoices holds across every trade. What follows is the part that does not.
- The invoice frequently goes to an organisation that bought access for its people, so the person asking what a line means may have no relationship with the service beyond paying for it.
- A receipt for a consultation is usually wanted so it can be submitted somewhere else, which makes the real question what appears on it, and a document naming a clinical reason has just told a third party something about a person's health.
- Sponsored access is billed per period rather than per consultation in many arrangements, so a finance team reconciling a bill cannot see who used what and should not be able to.
- Nothing here can answer by looking at an account, and on this product it also must not answer by describing what somebody had, which is a second refusal stacked on top of the ordinary one.
How it arrives
- can i get a receipt for my consultation to claim back
- what will the receipt actually say on it
- we sponsor this for our staff who do we send invoice queries to
- why is there a charge on my card i did not expect
- does my employer see what i used the service for
- can you send the invoice to our finance team instead
What has to be indexed for this to work
| What a receipt shows, field by field | The fields that appear and, more usefully, the ones that do not. People submit these to somebody else, so publishing the layout lets a person decide whether it will satisfy whoever is asking before they request it. |
|---|---|
| Who is billed under each arrangement | Direct subscriber, employer sponsored, insurer funded, with a query route against each. A single billing address for all three sends an organisation's finance team into a queue built for individuals. |
| What a sponsoring organisation is and is not shown | Written for both audiences at once: the finance team needs to know what it can reconcile, and the person using the service needs to know what their employer can see. Left unwritten, everybody assumes the worst version. |
| How to get a duplicate, a corrected or a historic invoice | Who to ask and what to quote. Small, constantly asked and rarely findable, which is why it arrives in a chat window instead of on a billing screen. |
The reply
Receipts are available for anything charged directly, and our billing page sets out exactly which fields appear on one, which matters if you are sending it on to somebody else [1]. Where an employer or an insurer funds the access, they are invoiced for that arrangement and there is a separate route for their finance queries [2]. What a sponsoring organisation is shown, and what it is not, is written on the same page. I cannot see a charge, issue a receipt or explain a line on a statement, so leave your name, an email and the date of the charge and the team will look.
It answers the receipt question by pointing at the fields rather than describing them, because the person is deciding whether the document will do a job for them. The sponsor question is answered from the published position instead of with reassurance, since a vague answer about what an employer can see is read as a yes. And it collects a date, which is the one thing needed to find a charge.
Where it stops
The trigger. The visitor disputes an amount, asks for a receipt to be issued or amended, or asks what a particular person used the service for.
I cannot see a charge, produce a document or change what is on one, and I cannot discuss what anybody used the service for. Leave your name, an email and the date the charge was taken, and it goes to the team who handle billing.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never state what appeared on a particular receipt or invoice, or confirm that one was issued.
- Never describe what a named person used the service for, to a payer, an employer or anybody else who asks.
- Never take card details, bank details or a payment in the chat, whatever the visitor offers.
- Never say a charge was an error, since nothing here can see whether it was.
Questions
- Sponsors ask what their staff used. What should it say?
- Whatever your published position says they are shown, and not a word past it. This is not a customer service question with a helpful answer at the end of it, it is the reason people trust a funded service enough to use it at all.
- Can it email somebody a copy of an invoice?
- No. It sends nothing except an enquiry to the address you nominate, carrying the name, email and message somebody left. Producing a document is a person's job or a screen inside the product.
- Is publishing the receipt layout worth the effort?
- It is one of the shortest documents with the highest return in this set. Somebody claiming money back needs to know whether your receipt satisfies whoever is asking for it, and a description of the fields answers that without anybody requesting a specimen.
Keep reading
- Everything for a healthtech appHealth data is a special category and clinical claims carry device rules. What a healthtech assistant answers for patients, and for buyers.
- Handling billing and invoices in generalInvoice copies, tax numbers, purchase order references. Nearly all of it is account specific, so the honest handling is process plus a clean handover.
- The person who wants out did not sign up, and cannot leaveFunded access ends without the user deciding, and the record stays behind. Notice, the last day, and the copy taken before it rather than after.
- A refund request about care is not a refund requestA dropped call, a consultation cut short, and a refund asked for because the answer was unwelcome. Three requests, and two different routes.
- The card failed, and something behind it has a date on itA declined card on a health service is a continuity problem. The retry dates, what stops working on each of them, and the part that cannot wait.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.