Practical guide
How to run a useful software evaluation
Define the decision before comparing products
A software evaluation is most useful when the practice agrees on what it is trying to change. Write a short decision statement that names the current problem, the work affected and the evidence you would need to consider an alternative successful. For example, a fictional practice might want its front desk to find submitted intake without searching several disconnected places. That is more testable than wanting a modern system.
Separate the reason for reviewing software from the list of features you encounter during demonstrations. A compelling feature can be useful without resolving your original problem. Keep both visible: the mandatory work the practice must perform and the additional opportunities worth considering. This prevents the selection process from becoming a contest between the longest feature lists.
Name the person responsible for the final decision and the people who will test each workflow. A clinician should assess clinical documentation, while the staff who manage optical orders, scheduling and billing should test those responsibilities. One person may hold several roles in a small practice, but the evaluation should still represent each kind of work.
Create a requirement with a visible finish
A good requirement describes a task, the conditions under which it must work and a result someone can observe. “Supports inventory” is a category. “An authorized employee can identify a specific frame variant at the correct office and explain its recorded quantity” is a requirement that can be demonstrated.
For each requirement, record the starting information, the staff role, the action and the expected evidence. Include a normal example and one realistic exception. An optical checkout test might begin with a fictional patient and selected frame, then include a correction before completion. A scheduling test might include moving an appointment to another available time without losing the staff's understanding of what changed.
Avoid making the requirement so specific to your current software's interface that only the incumbent can pass. Focus on the work and outcome. A different sequence may be acceptable if it is understandable, controlled and practical for the people using it. Conversely, a familiar-looking screen does not prove that the full workflow is supported.
Separate mandatory needs from preferences
Classify requirements before you see the final pricing. Mandatory requirements are those the practice cannot operate without at launch. Important preferences improve the work but may have an acceptable interim process. Optional items are useful only if their value justifies the cost and attention they require.
Write the consequence of an unmet mandatory requirement. If a required lab connection is unavailable, does that prevent opening, require a separate ordering process or affect only a limited service? Be precise. Some requirements can be handled through an approved outside workflow; others cannot. The decision belongs to the practice, and the workaround should have an owner, cost and review date.
Do not hide an unsupported mandatory item inside an average score. A product can receive high marks for design, price and many secondary features while still lacking a workflow the practice needs immediately. Keep mandatory acceptance separate from preference scoring so decision-makers can see the actual constraint.
Use evidence statuses consistently
The downloadable worksheet is intended to preserve what you learned, not merely produce a ranking. Use clear statuses such as demonstrated, requires setup, unanswered and unsupported. Add the date, the person who observed the workflow and the configuration used. A short note about what happened is more valuable than an unexplained checkmark.
“Demonstrated” should mean that the relevant task was shown under conditions close enough to your requirement to be useful. A presentation slide or verbal assurance belongs in a note until the workflow can be observed. “Requires setup” should identify the setup, the responsible party and how you will verify it. “Unanswered” should remain visible until someone supplies evidence.
Record limitations alongside successful demonstrations. A feature might work for one office but require additional configuration for several locations. A connection might be available while your particular external account still needs approval. These distinctions are part of the evaluation rather than reasons to mark every item as failed.
Prepare fictional scenarios that travel between vendors
Create a small set of fictional examples and use them consistently across demonstrations. Include enough detail to make the task realistic without using real patient information. A scenario can identify an appointment type, an office, a frame variant, a payment amount and an unresolved work item without copying a person's medical record.
Give vendors the requirements in advance when preparation is necessary, then ask staff to follow the actual workflow during the session. This makes demonstrations more comparable and gives the presenter a fair opportunity to configure the relevant example. Keep a record of anything that required special preparation so you understand the difference between ordinary use and a tailored presentation.
Use several linked scenarios rather than one enormous script. A clinical review, an optical correction and a billing follow-up have different owners and acceptance criteria. Linking them through the same fictional patient can reveal handoffs, while separate tasks make it easier to identify exactly where a question remains unanswered.
Test the clinical record as a working record
Ask the clinician to review how an encounter starts, how relevant history is found, how the intended template is selected and how information is reviewed before finalization. Include a question about correcting a record after the relevant stage of completion. The goal is to understand the documentation workflow, not to ask a demonstration to determine care for a real patient.
Check the distinction between structured information, free text and imported material. Ask what can be searched or reused and what remains an attachment. If the practice relies on particular instruments, prescribing services or external documents, list the exact requirement and request a separate demonstration or written confirmation of scope.
A configurable template can organize documentation, but it does not establish that a clinical service was performed or that a record meets every payer requirement. Keep clinical responsibility with the clinician. Use the EHR guide and template editor as starting points for the Jelo portion of the evaluation.
Follow the front-desk handoff
Have the staff member who schedules appointments test booking, finding and changing a fictional visit. Include the correct office and provider context. Ask how the team distinguishes a request, a scheduled appointment and a completed visit, and which staff actions move work from one stage to another.
For intake, test the patient-facing form and the staff-facing review. Check required questions, understandable labels, mobile use and the handling of missing or changed answers. If consent documents are part of the workflow, identify the exact document and how staff confirm the relevant acknowledgment or consent was recorded.
Include an exception such as a patient who cannot complete the form before arrival or an inquiry sent to the wrong office. The practice needs an operating procedure for these situations even when software supports the normal path. A useful demonstration shows where staff find the information and what they do next, not just how an attractive form looks.
Evaluate optical work from selection to correction
An optical demonstration should connect the selected item, the correct variant, the order, the payment and the downstream lab work. Ask staff to explain which record is authoritative for each part. A paid retail order and an accepted lab order are different facts, and a successful payment does not confirm that every order specification is correct.
Use an example with a frame and lens configuration your team understands, then introduce a correction before submission. Ask how staff review the prescription, measurements and configuration and how they know which details require confirmation. Keep actual clinical choices with the appropriate professional rather than turning the evaluation into a clinical exercise.
For inventory, test office scope, quantities and a realistic discrepancy. If you operate several locations, include an authorized transfer and a check of the receiving office's view. Review optical checkout, inventory and VisionWeb integration separately so one successful screen does not stand in for the entire process.
Make billing responsibilities visible
Ask the billing owner to map the work from documented encounter to review, submission, payer response and unresolved follow-up. Identify who performs each step and where the source response is retained. Include an item that needs additional information instead of showing only a completed claim.
Distinguish the software subscription from an outside billing service and from payment processing. For Jelo, insurance and payer work is handled through Taiga, and the confirmed charge is 10% of reimbursement. That service fee is separate from the platform subscription. The AI biller is available in beta, with no usage cap during beta; future usage limits are planned.
Request confirmation of the payer and account requirements that apply to your practice. Do not infer universal coverage, automatic successful appeals or guaranteed reimbursement from an AI label. Evaluate whether your team understands the handoff, the unresolved work and the financial basis of the service. Use the billing guide to prepare specific questions.
Inspect access, office scope and accountability
List the roles that need to use the platform and the work each role should perform. Include ordinary staff, managers, clinicians and any temporary or external participants where relevant. Ask to see how access is configured for the actual tasks in your test, including the office context for a multiple-location practice.
Test with the appropriate role rather than assuming that an administrator's demonstration represents every user's experience. Confirm where staff can review information and where they can make changes. In Jelo, an all-location view is useful for review and reporting; staff should switch to the working office for operational edits. Validate the exact account configuration during onboarding.
Security review should include the commitments the vendor can substantiate and the questions your organization still needs answered. Jelo confirms HIPAA compliance, BAAs, provider BAAs, an encrypted database and automatic daily backups. Specific technical details beyond those statements should be requested rather than inferred from a generic security label.
Compare complete commercial scope
Ask each vendor to quote the same number of locations, providers and staff, the same required modules and the same contract period. List implementation, migration, training, hardware, integrations, outside services and processing separately. If a charge is unknown, leave it as an explicit question instead of treating it as zero.
Jelo's confirmed platform price is $300 per month per location or $3,000 per year per location paid upfront, with unlimited doctors and staff at each paid location. Its payment processing rate through Stripe is 3.5% plus $1.30 per transaction. The Taiga-related reimbursement fee is a different charge with a different basis. Review current pricing and contractual terms for your proposed arrangement.
A lower subscription does not automatically mean a lower total operating cost, and a higher subscription does not prove a better fit. Use realistic volumes only when the practice can explain them. Keep one-time costs, recurring fixed charges and volume-dependent fees separate so the comparison remains understandable when assumptions change.
Review migration before choosing a date
Inventory the information the practice needs to bring forward: patient records, attachments, appointments, inventory and any other data in scope. Ask what the current system can export and what the destination can receive. A general statement that migration is available does not establish that every field or historical record can move in the form you expect.
Request a sample review and an acceptance process before committing to a final cutover. Identify who compares records, how discrepancies are recorded and what evidence is required to sign off. Include a plan for information that remains in an archive or separate system. Staff must know where to find it after launch.
Jelo describes a typical go-live window of five to seven days after migration planning is complete, subject to export, data, payer and training readiness. Do not start that clock before the prerequisites are resolved. Review the migration checklist with the people responsible for both the old and new workflows.
Ask about leaving while you are still choosing
Data access and cancellation deserve attention before purchase. Ask what exports are available, who can request them, what information they contain and how the practice will validate that the export meets its needs. If you require a particular format, attachment structure or delivery schedule, obtain confirmation of that specific requirement.
Jelo confirms data exports for your own analytics, free cancellation and help moving to another system if needed. Those statements do not specify every export format, delivery time, refund treatment or transition service. Keep the remaining details in the commercial review instead of inventing an interpretation that may not match the agreement.
Consider the practical work of an exit as well as the contractual language. Who keeps access to historical information? How are open orders and unresolved billing items handled? Which external accounts belong to the practice? These are planning questions for any vendor, and answering them early can reduce confusion if the practice's needs change later.
Turn the demonstration into a decision record
After each session, review the worksheet with the people who attended. Separate observed facts from impressions. A staff member saying a workflow felt easy is useful feedback; it becomes stronger evidence when paired with the task they completed, the help they needed and any unresolved exception.
Summarize mandatory requirements first, then commercial scope, migration readiness and preferences. Assign each unanswered item to a person with a concrete next step. Avoid letting a question disappear because the decision meeting has arrived. If the practice accepts a limitation, record the approved workaround and when it will be reconsidered.
Keep the final decision brief enough to use later. It should explain why the selected platform fits the required work, what setup remains and what success will look like after launch. This document gives the implementation team a clear starting point and prevents the practice from having to reconstruct promises from memory.
Use a realistic acceptance meeting
Schedule a final review around the requirements that matter most at opening or cutover. Have the responsible staff show the workflow, identify any remaining dependencies and confirm the next owner. An acceptance meeting should not be a repeat of the sales presentation; it should establish whether the practice is ready for the work it plans to do.
For a fictional two-location practice, that might mean confirming the correct office context for scheduling and inventory, checking the payment account setup and demonstrating how an unresolved billing item is assigned. For a small new practice, the priorities may be intake, encounter documentation and the first optical order. The worksheet supports both, but the required evidence differs.
Book a Jelo demo with Joel or Loreli using your completed requirements. Bring the items marked unanswered as well as the ones that appear to fit. The purpose is a clear, reviewable decision grounded in your team's actual work, with no requirement silently converted into a promise.
Work through a sample requirement from start to finish
Consider a fictional practice evaluating an optical order correction. The requirement is that an authorized employee can find the intended order, identify the item being corrected, review the financial consequence and understand the next lab-related action. The test begins before any real charge or external order is sent. Staff use fictional details and ask the presenter to identify the point at which an action would affect a live account.
During the demonstration, the evaluator records which parts were shown and which were only discussed. If the order can be edited but the refund process was not demonstrated, the requirement is partly answered. If the lab connection depends on an account the practice has not yet configured, that dependency remains open. The worksheet should preserve both facts instead of collapsing them into a single positive score.
The follow-up is specific: demonstrate the applicable financial correction, confirm the lab account requirements and identify the staff role that can perform each action. Once those items are resolved, the practice can decide whether the workflow meets its requirement. This approach takes more care than checking a feature box, but it produces an implementation task that someone can actually complete.
Revisit the evaluation after launch
Keep the original worksheet for the first operational review. Compare the work staff are doing with the workflow accepted during selection. If a task is taking an unexpected path, determine whether the cause is missing configuration, training, a changed requirement or a product limitation. Each cause calls for a different response.
Use a small sample of actual work reviewed within your approved environment. Do not place patient information into a public evaluation sheet. Record the process issue, its owner and the next action. If the practice has changed its operating model, update the requirement rather than judging the platform against an obsolete assumption.
This review also helps improve future purchasing decisions. A requirement that looked minor during a demo may become important in daily use, while a heavily promoted feature may be rarely used. Document those lessons so a later expansion, new location or renewal discussion starts with the practice's experience rather than a blank scorecard.