Before commissioning an AI project, ask the team to show you one task they repeat. Follow it from the moment it arrives to the place where its completion is recorded.
You may find a setting nobody enabled, a handover nobody owns or a useful detail buried in a message. These are different problems. Recognising which one you have is the first step towards choosing a worthwhile improvement.
Give each part a clear job
Your practice management system may hold the diary, patient details and clinical records, while other tools handle enquiries, payments or laboratory work. Agree which system is authoritative for each fact. A single source for every kind of information is less important than knowing where to check and where an approved change belongs.
Ordinary automation works well with a clear event and a defined action: a form is submitted, a task is created, a completion field stops a reminder. AI adds another way to work with information expressed in language: extracting a request, summarising an exchange or preparing a reply.
For example, OpenAI's structured-output documentation shows text converted into specified fields and warns that the contents can still be mistaken. Use that distinction when assessing a demonstration: a correctly shaped result still needs to be checked against the request.
Choose the simplest useful approach
- Can the PMS already do it?Configure the existing feature first.
- Is it a clear event and rule?Use conventional automation.
- Does useful detail sit in language?Consider AI preparation with source links and review.
- Does it require clinical judgement?Keep that decision with the clinical team.
Look closely at one rescheduling request
This example is illustrative; access to records and booking actions would need to be confirmed for the clinic's systems.
Sarah writes: “Can I move Thursday to next week? Mornings only. Do I need to stop my supplements before the blood test?”
A useful design separates the work in that message. AI prepares the scheduling request and preserves the original wording. A verified booking record and confirmed identity establish which appointment is involved. The supplements question remains visible for the clinical team, with the coordinator responsible for the handover.
The coordinator reviews the proposed options before replying. When Sarah chooses one, the change is made through the authorised booking process. The system checks the saved result before sending confirmation. If the change fails or the slot has gone, the work stays open for a person to resolve.
The value is specific: less time assembling the request and checking across tools. It depends on dependable access to the right facts as well as a useful language model.
Check the connection before promising the experience
Cliniko documents a REST API; Semble documents a GraphQL API. Those are ways for software to interact with a system. Their existence does not establish that a particular clinic account permits every action your proposed workflow needs.
Ask which records can be read, which changes can be made, how permissions work and how failed requests are reported. Check whether a test environment exists and who will maintain the connection when something changes. A demonstration using sample data cannot answer those account-specific questions.
Then draw the information path: what leaves each system, where it is processed and what is retained. Where health information is involved, the ICO's special-category guidance is relevant. Access, purpose and processing arrangements belong in the design.
Know when to leave the toolset alone
If an existing booking feature solves Sarah's scheduling problem, start there. If the missing piece is a named owner for clinical questions, assign that owner. If a reliable status field can stop duplicate reminders, use it.
Custom work becomes more compelling when the same gap persists across useful tools, the volume justifies the effort and the clinic can describe what a successful outcome would look like. It should remove a burden that matters, including the burden of checking and maintaining the new system.
Approve a small, testable first build
Write down the trigger, the sources, the proposed action, its owner and the evidence of completion. State what happens when identity is unclear, records disagree or a connection is unavailable. Start with preparation for review when that makes the outcome easier to inspect.
Compare real work before and during the pilot: time spent, corrections, unresolved items and duplicate actions. The decision to expand should follow those observations.
A well-designed improvement can make the tools you already use feel more capable. The right next step is the one that makes an actual piece of clinic work easier to complete.