Practice IQ · 2 September 2026
What we are selling, who pays what, how the money moves, and a mockup of each of the nine surfaces the product needs.
Four things get charged. Three different payers, two different bank accounts.
| What | Who pays | How much | Through | Lands in |
|---|---|---|---|---|
| Module 1a New patients and the rail |
Doctor | $1,000 a month | Stripe | NextRev |
| Module 1b Migrating your book onto the rail |
Doctor | $1,000 once | Stripe | NextRev |
| Module 2 The bot |
Doctor | $750 a month no setup fee |
Stripe | Practice IQ |
| The admin fee Rides each payment plan |
Patient | $6 per payment | TRX only | Practice IQ |
That is taking both modules. Either can be bought on its own. Module 1 comes in two halves that go together: 1a is the new patients and the rail, 1b is the migration that moves an existing book onto it.
Stripe will not sign a healthcare data agreement. So no patient information ever goes into Stripe. The customer there is the practice. Patients never appear in Stripe at all.
The patient agrees once, it rides the payment plan, and nobody has to see that patient again. Three things have to be true for it to work.
The whole point is that we never see the patient again. That only works if the $6 sits inside the same charge as the treatment payment, on the same saved card. A separate subscription would be a second saved card, with its own agreement, its own failures and its own name on the patient's statement.
One charge, one line on the patient's statement, in the practice's name. It also means the $6 cannot fail on its own, so there is nothing separate to chase. If the treatment payment fails, no fee is earned. That is one less system to build.
| Option | What happens | Verdict |
|---|---|---|
| A. TRX splits it | One charge. TRX pays the doctor and pays us, separately. | The target |
| B. We invoice the doctor | Doctor gets everything. We send a monthly statement. | Ships far sooner |
| C. We collect and pass on | We take it all, keep $6, send the rest on. | Never do this |
Holding someone else's money and passing it on is money transmission. It needs a licence in every state. It also destroys the best thing about how we are set up, which is that we hold neither card details nor funds. Nobody should build it, even as a shortcut.
Build B now, designed so A is a switch later. The ledger, the counting and the statement are identical either way. And the wording fixes the optics, because it is simply true: "Collected on your behalf: 214 payments, $63,918." That reads as a summary, not a bill.
Never count from the schedule. The schedule is what we expect to happen. What we bill on has to be what actually settled. Our own tested code proves why: a payment can come back marked approved and only partly go through, and there is a real test case of a $250.00 charge that settled at $49.27.
Each has a real penalty behind it, and two need a lawyer before we take a single patient.
The fix lives in the paperwork the patient signs, not in the software. Both versions of that screen are drawn in section 5.
A fee for paying by card is a surcharge. Visa and Mastercard limit those and some states ban them. The fix has to be true, not just worded well: it is a flat administration fee that applies however the patient pays, so it must also apply to bank transfer plans.
If the $6 is posted into the patient's Ortho2 balance, every patient is credited $6 more than they actually paid, on every payment.
So the write-back posts the settled amount minus the fee, and the fee lives in a separate Practice IQ ledger. There is already a safety check in the bridge that refuses a payment when the amount does not match what it expected. It has to be taught about the fee, or it will refuse every payment that carries one.
The payment provider's own page takes the card. Ours never does. The install page is built as a redirect to their hosted page rather than an embedded card field, which is narrower on purpose: a card field on our own site puts us in a much heavier compliance category and throws away the strongest structural advantage the business has.
Texts about appointments are allowed under the healthcare rules. Texts about balances and billing are not, and need separate written consent from each patient. Penalties run $500 to $1,500 per message, with no harm needed. So the bot refuses to draft anything mentioning a balance and hands it to a person. Keeping collections out of Module 2 is a legal boundary, not a tidiness one.
Module 2 sorts the day into six queues and hands the front desk work that is already written.
| Queue | What it holds | Needs practice software? |
|---|---|---|
| 1. New patient requests | New enquiries, what each person wants, what to do next | No |
| 2. Email and text inbox | Messages tied to a patient, summarised, reply written | No |
| 3. Scheduling and requests | Reschedules, forms, records requests | Yes, for real openings |
| 4. New patient follow-up | Leads who never booked, and for how long | No |
| 5. Current patient tasks | Documents, callbacks, confirmations | Yes, for chart tasks |
| 6. Where patients came from | Which enquiries came from where, and what happened | Yes, for the booking half |
Four of the six queues need nothing from the practice's software, and not one of them needs to write into it. That is why this can ship where the old Module 2 could not.
| Stage | We can say | We cannot say |
|---|---|---|
| 1. Email and text only, one office | Every email, text and form lands in one queue, read, summarised, with a reply written and waiting for a person to send. | Anything about the schedule, the chart, or whether a lead became a booking. |
| 2. Reading the practice software | The console proposes real openings from the actual schedule. | Nothing is written back, at any stage. |
Open Dental first: it has a real documented connection with a free read-only tier, and everything we need is on the reading side. Then Dentrix, through Henry Schein's partner programme, and that application takes months, so it should start now.
Collections and payment chasing (that is Module 3, and legally separate) · AI voice calls (legally a robocall) · sending anything without a person pressing send · writing into the practice software.
Nine surfaces fall out of everything above. Three of them we buy rather than build. These are arrangements, not final art.
| # | Screen | Who uses it | State |
|---|---|---|---|
| 1 | The landing page | Prospective doctors | Mocked below |
| 2 | Modules and module pages | Prospective doctors | Built, clickable |
| 3 | Install and checkout | Buying doctor | Built, clickable |
| 4 | Card capture and billing portal | Office manager | Stripe hosted, configured not built |
| 5 | Onboarding | New doctor, once | Mocked below |
| 6 | The admin console | Front desk, all day | Mocked below |
| 7 | The patient payment plan | Patient, once | Mocked below, both ways |
| 8 | The monthly statement | Doctor and bookkeeper | Mocked below |
| 9 | Reconciliation | Us, monthly | Mocked below |
The console leads the page, because it is the thing being sold. Price is on the page rather than behind a form.
Every email, text and web form lands in one queue, read and summarised, with a reply written and waiting for someone to press send. Nothing sends itself.
Two things this decides. The console is the hero rather than a five-system platform story, and the three numbers under it are the ones the product actually meters, so the homepage promises exactly what the console proves daily.
This is what the install link leads to. It is where a sale is won or quietly lost.
Step 3 of 5 · about six minutes left
Step 5 is deliberately last and optional. Four of the six queues work with no practice software at all, so a doctor is live and getting value before anyone has to involve their software vendor.
The screen the front desk keeps open. This is what the $750 buys.
Practice IQ found 37 administrative items today. 24 can be prepared by AI. 13 need a person.
Counted from the log, not estimated · 3 of the 13 could not be classified and are sitting in Needs a person, never dropped
Asked about Invisalign pricing and wants an appointment after 4pm. her text, 2:14pm
Has not been seen at this practice before. no source — check the chart
Recommended: reply with your two soonest openings after 4pm.
Asked what he still owes on his plan. his email, 8:51am
No draft was prepared. This message is about an account balance, which is billing content under a different consent rule, so the console will not write it.
Needs to move tomorrow's appointment. her text, 7:40am
Recommended: acknowledge and offer to call her back with times.
Four things this arrangement decides. The meter is a sentence at the top, above the work, because it is the daily proof the $750 is working. The badges sum to the header exactly: 8+12+6+5+4+2 = 37, and 24+13 = 37, because adding up the badges is the first thing an office manager does. The two queues needing a live schedule are drawn locked rather than quietly working. And the held card sits on the main screen, so rule 5 is visible rather than promised.
This is the screen rule 1 turns on. Whether the fee is optional or compulsory changes what it has to say, so both are drawn.
Horizon City Orthodontics · Ava Nguyen
Declining costs you nothing and does not affect your treatment.
What it costs: some patients decline, and the model has to survive that. Nobody has set a take-up target yet.
Horizon City Orthodontics · Ava Nguyen
You can pay the full balance at any time to stop future fees.
The document the doctor judges us by. It has to match TRX's own settlement file to the penny, or it will be argued with.
| Date | Patient | TRX ref | Settled | Fee |
|---|---|---|---|---|
| 03 Sep | P-4417 | TRX-88213 | $306.00 | $6.00 |
| 03 Sep | P-4418 | TRX-88214 | $249.00 | $6.00 |
| 04 Sep | P-4419 | TRX-88231 | $49.27 part paid | no fee earned |
| 04 Sep | P-4420 | TRX-88240 | $306.00 | $6.00 |
| 07 Sep | P-4402 | TRX-88255 | refunded | −$6.00 |
| 209 more lines | ||||
| Total administration fees for September213 fees earned at $6.00, less one $6.00 reversal | $1,272.00 | |||
The two highlighted rows are the whole reason this page is hard. A payment can settle for less than it was for, and when it does the treatment gets paid first and we earn nothing. A refund reverses the fee. Showing those rows rather than hiding them is what makes the statement trustworthy, and they are the rows a bookkeeper looks for first.
Which practices, what settled, what is owed to whom, and whether it agrees with TRX. Nobody sells this, and without it we cannot invoice or answer a dispute.
| Practice | Settled | Fees | Modules | Agrees with TRX |
|---|---|---|---|---|
| Riverside Orthodontics | $63,918 | $1,272 | $1,750 | matched |
| Horizon City Orthodontics | $41,205 | $822 | $750 | matched |
| Lakeshore Braces | $28,470 | $558 | $1,750 | 3 lines short |
| Northgate Ortho | $19,044 | $372 | $750 | file not in yet |
| 3 more practices | ||||
| Owed to Practice IQ | $8,916 | $5,250 | ||
| Owed to NextRev | — | $7,000 | ||
The last two rows are why this screen exists. Module 1 money belongs to NextRev and Module 2 money to Practice IQ, and the split has to be a number somebody can read rather than a calculation done by hand each month. The two amber rows are the normal case, not an alarm: a settlement file arriving late is routine, and it has to be visible rather than quietly rolled forward.
These are not mockups. They are built, they pass their checks, and they are on this same link.
| Page | What it does | Open |
|---|---|---|
| Modules | Both modules side by side. First item in the site menu. | modules |
| Module 1 | New patients and the rail, $1,000 a month. | module 1 |
| Module 1b | The migration that moves an existing book onto the rail, $1,000 once. | module 1b |
| Module 2 | The console, $750 a month per office. | module 2 |
| Install | Tick the modules, see the total, continue to a secure payment page. | install |
One-time and monthly are counted on separate lines, so nobody is told they are being charged something today that they are not. Ticking both reads: due today $1,000, then $1,750 per month.
Pages on the main domain build up its standing; a portal on a separate address builds nothing and splits the signal. Each module page is its own entry point with its own title and description, which is what lets them appear in search at all. Being straight about it: ranking comes from content and links, not page count. Four new pages create four new front doors. They do not by themselves move the site up.
Two are settled. The rest are named here rather than assumed, and three of them block building.
Module 1 is $1,000 a month plus $1,000 to set up. Module 2 is $750 a month. The migration is $1,000 once, and it is 1b inside Module 1, so there was never a separate third product.
One question, and it decides the whole design. If the answer is no, we invoice the doctor permanently. Worth asking before anything is built.
Recommendation is B now, A when TRX answers. The ledger and the statement are identical either way, so nothing is wasted.
The $6 may make these plans count as lending. The fix is in the paperwork, not the code, and the creditor is the practice.
The lender is the practice, not us, so this cannot be ours to write alone.
Module 1 at $1,000 a month matches the wholesale per-module price exactly. The older lists also carried a figure before any module, and nothing in this pricing mentions one. Either it was dropped or nobody has written it down.
Its setup fee does. The monthly has not been said either way, so it is assumed the same above.
No patient message goes near a model until it is signed.
Still open, and it blocks every outgoing text at every stage.
Assumed never, so far.
In the order that stops later work being wasted.
| # | Build | Why here |
|---|---|---|
| 1 | The fee ledger | One line per payment that actually settled. Identical under both options, and everything else reads from it. |
| 2 | Refunds and reversals | Added now, not later. Retrofitting means reconciling backwards. |
| 3 | The monthly statement | Matching TRX's own file to the penny. This is what the doctor judges us by. |
| 4 | Stripe checkout for the modules | Nothing to do with TRX, so it can ship first. |
| 5 | Write-back excludes the fee | Must be in place before any fee-bearing payment reaches a real ledger. |
| 6 | The patient fee screen | One screen on a flow that already exists, and every dollar above depends on it. |
| 7 | The console, then onboarding | The product, and then the thing that stops a sale being lost after it. |
| 8 | TRX splitting | Only if the answer to the first open question is yes. Last, because it is the only part we do not control. |