Practice operations, computed from the record you already keep.
Lynqpod turns Dentally into practitioner pay, filled diaries, online booking and marketing you can measure to the appointment. One engine, ten modules, and a figure you can trace to the treatment that produced it.
For single practices and multi-site groups. Onboarding measured in days, not quarters.
Connects to
The problem
Your practice management system was never meant to run your business.
Dentally is excellent at the clinical record. It was not built to work out what seventeen associates are owed, whether Tuesday afternoon is genuinely free, or which advert produced the implant case. So those questions get answered in spreadsheets, by one person, from memory.
Month-end is a person, not a process
Commission lives in a workbook only one member of staff fully understands. When they are on leave, payroll waits. When they leave, the method leaves with them.
Empty chairs nobody can see
Gaps exist across every clinician every week, but finding them means opening the diary and scrolling. Most go unfilled because nobody had time to look.
Marketing judged on the wrong thing
Ad platforms optimise for form fills. Practices are paid for treatment. Without joining the two, spend is defended with impressions instead of income.
The platform
Ten modules on one engine.
Licensed individually or as a package, and switched on per practice. They read the same data, so a treatment completed this morning reaches the payslip, the rota, the booking page and the marketing report without anybody exporting anything.
Module 01 · Finance
Commission & payroll
A rules engine for practitioner pay, built for arrangements that are never as simple as a single percentage.
- Commission rates, retention and plan-fee schedules dated by month, so last March recalculates as last March
- Uplift and downlift on named treatments, per clinician, with transfers between practitioners for mentoring
- Lab charges matched by pattern, non-commissionable items excluded before the multiplication
- Manual adjustments built by picking the payments they relate to, rather than typing a total
- Refunds and credit notes carried through to net payable
- Branded PDF payslips, published in-app or emailed, superseded rather than overwritten on a re-release
- Supplier bills uploaded once and split across the practitioners whose patients they cover
- Debtors grouped by patient, and refunds swept in day by day for a person to assign
Module 02 · Appointments
Online booking & open space
Every gap across every clinician on one screen, and a booking page patients finish on their phone in a couple of minutes.
- One question at a time: what they need, who they would like to see, then only the days that have free times
- Your own treatment menu, with prices and lengths read from Dentally's fees and a "More info" note on each
- Each clinician's next free time on their card; "first available" across everyone who offers the treatment
- Deposits by card through Stripe, as a fixed sum or a share of the treatment's fee
- Patient email verified by one-time code, with identical replies for known and unknown addresses
- Diary changes reflected in seconds through live notification, with a scheduled sweep behind it
Module 03 · Rota
Cover, rooms and leave
Who is in, where, and with whom, drawn from the same diary the bookings come from.
- The week at a glance by clinician, room and nurse
- Approved and requested leave folded in, so an empty day is never mistaken for a free one
- Nurse assignment and room allocation held against the working day
- The same source as availability, so the rota and the booking page cannot disagree
Module 04 · Marketing
Cost per appointment, not per click
Judge advertising on appointments that happened and treatments that were paid for, not on forms that were filled in.
- Connect Google Ads and Meta in one click each; campaign spend arrives by itself every day
- Every patient from an ad followed through: clicked, asked, booked, turned up, and what they paid
- Cost per appointment and per patient who actually came, by platform and by campaign
- Booked and attended appointments sent back to Google and Meta automatically, so their bidding learns from real patients
- The booking funnel, step by step, to show where people give up
- Patient segments by rules, and campaigns sent to them
And six more
The rest of running the practice.
Module 05 · Patients
Patient portal & pre-visit forms
Patients sign in with a one-time code to see their appointments and ask to move or cancel one, fill in pre-visit forms prefilled from Dentally, and order sundries to collect at the desk. In the practice's own colours.
Module 06 · Chat
Assistant & team inbox
A chat on the website and booking page that answers from what the practice has written, shows real free times, and hands over to a person. The team works it from one inbox, with notes patients never see.
Module 07 · Automations
Rules that make the to-dos
A morning summary, booking requests nobody has answered, refills to have ready, stock to reorder, patients who missed an appointment. Each becomes a task in the team's inbox, from a template or the practice's own rule.
Module 08 · Inventory
Stock, stocktakes & sales
What is on the shelf, what it cost, and what needs ordering. A stocktake typed box by box, items taken off when a patient collects their order, and every movement kept.
Module 09 · Research
Who buys what
Which patients, after which treatments, buy which products, against everyone the practice saw. One clear chart per question, so the next campaign has a reason.
Module 10 · Recordings
See where visitors struggle
Replays of visits to the website and booking page, only from visitors who agree and never with anything they type. Filter by where they gave up, straight from the booking funnel.
Capabilities
What is actually in the product.
Not a roadmap. Each of these is built and available today.
| Capability | What it does | Module |
|---|---|---|
| Dated rate schedules | Commission, retention and plan-fee rates keyed by month. A rate changed in September never reshapes March. | Finance |
| Uplift & downlift rules | A percentage on named treatments for a named clinician, with an effective-from and effective-to month. Ending a rule preserves the months it applied to. | Finance |
| Payment-allocation basis | Bonus calculated on money the practice actually received, matched to the treatment that produced it. | Finance |
| Traceable totals | Every figure opens into the rows behind it: the treatments, the payments, the lab charges, the refunds. | Finance |
| Payslip publishing | Release a month to a practitioner, with or without email. Re-releasing supersedes rather than overwrites, so history survives. | Finance |
| Secure share links | One payslip, one month, openable without an account. Scoped, expiring, revocable, and every total recomputed server-side. | Finance |
| Practice-wide open space | Every gap across every clinician for a date range and appointment length, in one call. | Appointments |
| Online booking | One question at a time on the practice's own address: the treatment, the clinician, then only the days with free times. | Appointments |
| Treatment menu | Lists and treatments with prices and lengths read from Dentally's fees, a "More info" note, who can be booked, and an on/off switch each. | Appointments |
| Deposits | A fixed sum or a share of the fee, paid by card through Stripe, with refunds from the request. | Appointments |
| Verified patient identity | One-time code to the patient's email before a slot is held. Registered and unregistered addresses receive identical responses. | Appointments |
| Live diary notification | Changes made at reception reach the platform in seconds, with a scheduled sweep as the safety net. | Appointments |
| Leave-aware scheduling | Approved and requested absence removes a clinician from availability, so nothing is offered on a day they are away. | Rota |
| One-click ad connections | Google Ads and Meta connected by signing in. Spend per campaign arrives by itself; nobody exports or uploads a file. | Marketing |
| Cost per appointment | Spend against requests, booked appointments and patients who came, by platform and campaign, including campaigns that spent and brought nobody. | Marketing |
| Ad patients | Every patient from an ad followed from click to chair: asked, booked, turned up, paid. Only people who asked are named. | Marketing |
| Results back to the platforms | Booked and attended appointments, with their value, sent to Google Ads and Meta automatically, each once. | Marketing |
| Booking funnel | How far each visit to the booking page got, and from which source, with no click identifiers stored. | Marketing |
| Segments & campaigns | Patient groups described by rules, always today's list, and messages sent to them with a record of who received each. | Marketing |
| Patient portal | Appointments, requests to move or cancel, pre-visit forms and orders, behind a one-time code rather than a password. | Patients |
| Chat assistant & inbox | Answers only from what the practice wrote or real free times, with the questions it could not answer listed for the team. | Chat |
| Automations | Rules that turn events into tasks for the right people, from templates or written by the practice. | Automations |
| Stock & stocktake | Levels, costs, reorder points and movements, linked to what patients order through the portal. | Inventory |
| Who buys what | Which patients buy which products, after which treatments, against everyone seen in the same period. | Research |
| Visitor recordings | Session replays with the visitor's agreement, typed text never recorded, linked to the booking funnel. | Recordings |
| Multi-practice console | Accounts, packages and add-on modules, subscription and invoicing across every practice on the platform. | Platform |
| One address per practice | Team sign-in, booking pages and the patient portal on the practice's own address, such as practice.lynqpod.com. | Platform |
| Versioned configuration | Every change to a rate, charge or arrangement stored as a new version with an author and a reason. Nothing is overwritten. | Platform |
| Role-scoped access | Practitioner, data admin, practice admin and platform admin. A practitioner's own pay is resolved from their session, never from the request. | Platform |
| Audit trail | Sign-ins, publishing and configuration changes recorded with the person and the time, readable in the product. | Platform |
Architecture
Your practice management system stays the system of record.
Lynqpod reads from it and computes on top of it. Clinical data does not move, your team does not learn a second diary, and nothing is entered twice. The integration is read-only unless you choose otherwise: bookings and deposits go into Dentally only if you give Lynqpod a key that allows it.
Why finance teams trust it
Built by people who had to make the numbers agree.
Most of what makes payroll painful is not arithmetic. It is that two people computed the same figure from two different places and neither can say which is right. Every design decision here follows from that.
Reconciled to the source
Private-paid figures are derived from payment allocations, the same movements your monthly accounts are built on, inbound and outbound. Not an estimate that happens to look close.
History does not change
Rates and arrangements are dated. Regenerating a payslip from eight months ago produces the figure that was actually paid, not today's rules applied to last year's work.
Nothing invented when it can be asked
Availability, opening hours and money received come from the source system. Where an answer genuinely is not available, the platform says so rather than offering a confident guess.
Every total opens
A commission figure opens into the treatments behind it. A private-paid figure opens into the payments. When a practitioner queries a number there is an answer, not an argument.
Change is attributable
Who changed a rate, when, and why, kept as versions rather than edits. The configuration history is the audit trail for what people were paid.
Safe to re-run
Publishing supersedes rather than overwrites. A corrected month sits alongside the original instead of quietly replacing it.
For groups & DSOs
One console. Every practice.
Built multi-tenant from the ground rather than retro-fitted. Each practice holds its own database and its own upstream credentials, so separation is structural rather than a condition in a query.
Account management
Every practice on the platform in one place, with status, usage and a route into each.
Packages & add-ons
Sell a package of modules and add single modules on top. Enforced on the server, not hidden in the interface.
Subscription & invoicing
Raise and send subscription invoices to each practice from the platform itself.
Isolation by design
A query that forgets its filter finds nothing, rather than finding another practice's payroll.
One address each
Every practice has its own address for its team, its booking pages and its patient portal.
Guided onboarding
A new practice is set up from the console, and a getting-started list ticks itself off from the practice's own data.
Implementation
Live on your own numbers, quickly.
There is no data migration, because there is no second copy of your clinical record. Most of onboarding is agreeing what your arrangements actually are.
Connect
A read-only key to your practice management system, and the practices you want on the platform.
day 1
Configure
Commission rates, retention, plan fees, lab charges and any uplift arrangements, dated from the month they began.
days 2–4
Reconcile
We recalculate a month you have already paid and sit with you until every practitioner agrees to the penny.
days 4–7
Run
Publish payslips, open the booking pages, and switch on the modules you want, practice by practice.
from week 2
Security & governance
Payroll data, treated like payroll data.
Practitioner pay and patient records sit in the same product. The boundaries between them, and between one practice and the next, are structural rather than conventional.
Tenant isolation
A separate database per practice, with its own upstream credentials. Separation does not depend on remembering a filter.
Least privilege upstream
The integration is read-only. Lynqpod computes on your data; it cannot alter your clinical record.
Role-scoped access
A practitioner sees their own pay and nobody else's, resolved from their session rather than from what the page asked for.
Credentials handled properly
Passwords hashed with bcrypt. Keys and advertising access tokens encrypted at rest, never shown in the interface, and removed when a connection is ended.
Patient privacy by default
Booking replies are identical for registered and unregistered addresses, so the page cannot be used to discover who is a patient.
Transport & hardening
HTTPS with HSTS across every host, strict referrer policy so links carrying a token are never leaked onward, and the application reachable only through the proxy.
Time-boxed sharing
Payslip links are scoped to one practitioner and one month, expire on a date you choose, and can be revoked instantly.
Full audit trail
Sign-ins, publishing and configuration changes recorded with the person and the time, and readable inside the product.
Consent before recording
Visitor recordings start only after the visitor agrees, and nothing typed into a form is ever captured.
Questions
The things practices ask first.
Do we have to move off Dentally?
No, and you should not. Dentally remains the system of record for everything clinical. Lynqpod reads from it through a read-only integration and computes on top. Your team keeps one diary and one patient record.
How do we know the pay figures are right?
Onboarding includes recalculating a month you have already paid, and comparing it line by line with what you issued. Every total in the product opens into the rows behind it, so a disagreement can be traced to a treatment or a payment rather than argued about.
Our commission arrangements are unusual. Will they fit?
Most do. The engine handles per-clinician rates, retention, plan fees, lab charges by pattern, non-commissionable items, uplifts and downlifts on named treatments, transfers between practitioners, and manual adjustments, all dated by month. If yours genuinely does not fit, we would rather tell you at the demo.
What happens to payslips we have already issued?
They stay exactly as they were. Rates and arrangements carry the month they took effect, so changing a rule today does not reshape a month that was already paid. Re-releasing a month supersedes the previous version rather than overwriting it.
Can patients book without creating an account?
Yes. The booking page asks whether they are an existing patient, verifies their email address with a one-time code, and holds the slot for reception to confirm. Registered and unregistered addresses get identical replies, so the page cannot be used to find out who is a patient.
Can we see what our adverts cost per patient?
Yes. Connect Google Ads and Meta by signing in, and campaign spend arrives by itself every day. Lynqpod sets it against the requests, booked appointments and patients who actually came, by platform and by campaign, and can send the results back to Google and Meta so their bidding learns from real patients.
Can patients pay a deposit when they book?
Yes, by card through Stripe on the booking page: a fixed sum, or a share of the treatment's fee read from Dentally. It is shown before they commit, and refunds are made from the request.
How is a multi-site group handled?
Each practice has its own database and its own upstream credentials. A platform console manages accounts, decides which modules each practice has, and raises subscription invoices. Nothing is shared between practices by default.
What does it take to get started?
A read-only key to your practice management system and a conversation about your commission arrangements. There is no data migration, because there is no second copy of your record.
See it against your own last month.
The most useful demonstration is not a tour. Bring a payslip you already trust and a month you have already paid, and we will reconcile to it in front of you.
scott@lynqpod.com