The exam is bulk billed and roughly break even at best. The glasses are the business. Every optometry account we see reports on the first of those two things and none of the second.
In most clinic types a booking is a reasonable proxy for value, because attending produces revenue. In optometry it does not. The consultation is bulk billed, the Medicare benefit is $67.85, and Optometry Australia's own costing puts sustainable delivery at more than $50 above the schedule fee. A booking, by itself, is close to worthless.
What varies enormously is what happens after the exam: no purchase, a single vision pair, a progressive pair, a myopia management programme, or a contact lens fitting. That variance is the entire commercial signal, and it lives in the practice management system rather than in the booking.
Optomate Touch has no dedicated field for this, and its patient record carries a SOURCE field of up to 200 characters plus a referrer field. That is ample, and it is where the identifier goes at booking time.
There are no webhooks anywhere in the specification. The integration has to ask, on a schedule, what changed. That is more moving parts and it is entirely workable.
This is the trap. The sales summary report aggregates by stock type with no patient identifier attached, so it cannot be used for attribution. Patient invoices expose the patient, the sale date, the total and a line item collection with quantity and unit price, which is what you actually need.
The conversion becomes the sale with its real value, segmented by frames, lenses and contact lenses if you want the bidding to learn the difference between a $200 patient and a $900 one.
The Optomate Touch API runs on the practice's local network with basic authentication, so a cloud integration needs a tunnel or an on-site agent. Where that is not practical, matching conversions on hashed email and phone works from any system that can export a patient list.
| System | Hosting | API | What it means for tracking |
|---|---|---|---|
| Optomate Touch | On premise, local network | Full public REST specification with OData | Complete chain available: patient fields, appointments, per line invoice revenue. No webhooks |
| Optomate.Net | Cloud | No public API documentation found | Integrated web booking and two way SMS. Tracking position undocumented |
| Sunix | On premise | No API or developer documentation found | Integrates Medicare and HICAPS. Online booking not documented on the vendor site |
| MyHealth1st and HotDoc | Booking layers | Not public | Booking widgets typically run on the vendor domain, which breaks the click identifier |
One operational trap documented by the vendor: assigning API access permissions to the patient recalls resource disables the Recalls Wizard inside Optomate Touch. Recalls become either the software or the API, not both.
A senior team that lives inside your account. Conversion infrastructure wired in before any ad goes live. Reporting that ties spend to booked appointments, not impressions.
A senior specialist who runs clinic accounts day to day.
Every keyword, headline and account structure built inside real Australian clinic accounts.
Winner, Best Google Ads Campaign, Australia 2025. Google Partner. AFR Fast 100.