What Should Be Included in Clinic Software, and What Is Normally an Add-On?

A useful foundation should cover appointment and walk-in handling, patient registration, the consultation record, prescriptions, payments and a daily view of the queue. If those pieces are separated by plan or vendor, ask how the handoff works.

Can the next role see the context created by the previous role? A receptionist should not retype a patient. A pharmacist should not need a second copy of the prescription. An owner should not assemble revenue from three exports.

AI Scribe, report extraction, two-way WhatsApp, follow-up campaigns, retail pharmacy and advanced reports are often optional. That is not automatically a problem. Optional modules can keep an entry plan small. The problem appears when an add-on is required to complete a basic clinic day.

• Core clinic operations
• Clinical documentation and prescription output
• Pharmacy and stock movement
• Messaging and follow-up
• Reporting and exports
• Hosting, backup and support

CliniKite Core includes appointments, queue, clinical records, prescriptions, billing and essential patient communication. Intelligence adds Ambient Scribe, Dictate, report processing, AI WhatsApp and Care Loops. Retail pharmacy is included in Intelligence and On-Premise, while clinical pharmacy remains part of the foundation.

A clinic can start with the foundation, add AI when ready, or choose On-Premise when local infrastructure is the main requirement.

Ask the vendor to show a complete patient journey using the plan you are considering. Book the visit, check the patient in, complete the consultation, issue the prescription, dispense the medicine, collect payment and plan the follow-up. Then ask what changes if you move down one plan.

The minimum useful system is not the shortest feature list. It is the smallest set of connected actions that lets a patient move through the clinic without retyping. Registration should create a record that the queue can find. The consultation should create a note and prescription that the next role can read. Billing should use the visit context, and the owner should be able to see what was collected.

Mark each part as included, optional or external. If an optional module is needed to perform a safe, ordinary clinic task, the vendor should say that plainly. A scribe can be optional. A complete consultation record should not depend on buying a separate module. A campaign tool can be optional. The clinic should still be able to record a follow-up date and responsibility.

Some features have real variable cost. AI inference, large document processing, WhatsApp conversation fees and advanced campaigns may be priced separately because usage is different from a basic record. An add-on is reasonable when it is clearly described, can be turned off without breaking the core record and has its own data and consent explanation.

The danger is not an add-on itself. The danger is a plan that presents a beautiful workflow while leaving the last step outside the product. Ask the vendor to run the patient journey using the exact plan in the quote. If the demonstrator switches to a higher plan without saying so, record the boundary and ask for the commercial impact.

A pharmacy add-on should be judged by more than a stock screen. Can it receive inward stock, preserve batch and expiry information, suggest a sensible issue order, record a partial dispense, handle a return and reconcile the closing quantity? A WhatsApp add-on should be judged by consent, template approval, delivery status, opt-out and the connection between a message and a patient task.

The same rule applies to reports. Ask whether the report reads from the same source as the consultation and invoice, whether a correction is attributable and whether the owner can export the underlying records. A dashboard that cannot be reconciled is a presentation layer, not operational control.

Ask for a one-page scope table with four columns: capability, included plan, extra charge and clinic responsibility. Add a fifth column for evidence. A live demo, a contract clause, a help article and a product promise do not carry the same weight. Store the date of the evidence because plan names and limits change.

CliniKite keeps its plan boundary visible. Core covers the daily clinic foundation, Intelligence adds the optional AI and communication layer, and On-Premise is scoped around local deployment requirements. That does not remove the need for a clinic-specific discussion. It gives the clinic a clearer starting point for that discussion.

Take this article into the buying room as a working sheet. Ask the vendor to show the exact plan, the exact role and the exact patient journey you expect to use. Stop at every handoff and ask who owns the next action. If the answer is a spreadsheet, a second login or a future promise, write that down instead of filling the gap with optimism.

End by asking what happens when the clinic changes its mind. Request a usable export, the time involved, the support owner and the commercial terms for leaving. A vendor that can explain the beginning, middle and exit of the relationship gives the clinic a better basis for trust than a vendor that only rehearses the happiest five minutes of a demo.

Before the next vendor call, write five things in plain language: the clinic's current constraint, the people who touch the record, the exception that causes the most rework, the data the clinic cannot afford to lose and the commercial limit it wants to respect. This brief keeps a polished demo from changing the question halfway through.

Bring one person who runs the front desk and one person who owns the clinical or pharmacy decision. Ask each of them to describe the same patient journey. Differences in their answers are not a problem to hide. They are evidence about where the workflow needs a clearer owner or a better handoff.

After the call, record the answer, the evidence and the unresolved question. A short list that remains honest is more valuable than a long list of features that nobody has tested.