Yury Chernik

Sales-process prototype

The demo that admitted its AI was a rulebook

A treatment-acceptance flow where the assistant suggests answers to a patient's objections. The suggestions came from rules, not a model — and saying so made the demo stronger, not weaker.

Consultation, objection, agreement, payment, follow-up, admin
6 stagesConsultation, objection, agreement, payment, follow-up, admin
The intelligence labelled as heuristics in the demo and the notes
Rules, not a modelThe intelligence labelled as heuristics in the demo and the notes
The rulebook exposed in the admin area, not hidden in code
Editable by the practiceThe rulebook exposed in the admin area, not hidden in code

The client

An orthodontics practice where treatment acceptance depends on a single conversation at the chair: the plan, the price, the patient's hesitation, and whether it ends in a signed agreement or a follow-up that never happens.

The engagement

A tablet-first clickable prototype covering the whole acceptance conversation end to end, including the administrative side where the rules themselves are edited.

A working demo of this build exists.

It is not public yet — ask for access, and where the NDA allows I will send a link or walk you through it on a call.

Request demo access

The problem

In a clinical sales conversation the failure point is not the plan, it is the objection — and the temptation is to answer that with a language model on stage. That creates two problems at once: an expensive dependency for a practice with no technical staff, and a demo whose most impressive moment is the one least likely to survive contact with regulation, cost and the practice's own tone of voice.

What I did

I used rules and said so. The objection responses and the finance logic are heuristics, labelled as such in the demo, in the documentation and out loud — because in this setting the rulebook is genuinely the better answer: it is auditable, it costs nothing per conversation, its tone can be set by the practice, and it does not invent a clinical claim. Making the rules editable in the administrative area turned that from an apology into the pitch, since the owner can see the thing they will actually control. The rest of the flow was built through to the end that matters commercially — an agreement generated as a real document, signed on the device, with payment and a follow-up queue behind it — because a demo that stops at the treatment plan stops one step before the money. The whole thing is tablet-first because that is the device that sits between a clinician and a patient.

What was built

A tablet-first flow covering consultation and treatment plan, objection handling with suggested responses, a finance engine applying pricing rules, an agreement generated as a document and signed on the device, a payment step, a follow-up queue, and an administrative area where the response and finance rules are edited and the outcomes analysed — with the intelligence explicitly implemented as heuristics rather than a language model.

On the table at the end

  • Tablet-first prototype covering six stages of the acceptance flow
  • Rule-based objection handling with an editable rulebook
  • Rules-driven finance engine
  • Generated agreement document with on-device signature
  • Administrative area with rules editor and outcome analytics

What it changed

Demonstrated the entire acceptance journey — consultation, objection, agreement, signature, payment, follow-up — and showed the practice owner the rules editor, so the value was visibly something they would control rather than a black box they would rent.

How it ran

  1. 01

    Choose rules deliberately

    Heuristics rather than a model for objection handling and finance, chosen for auditability, cost and tone control.

  2. 02

    Label the intelligence honestly

    Stated in the demo and the documentation that this is a rulebook — the credibility gained outweighs the wow lost.

  3. 03

    Make the rulebook the product

    Rules edited in the administrative area, so the practice owns the behaviour rather than renting it.

  4. 04

    Finish at the signature

    Generated agreement, on-device signature, payment and follow-up — the demo ends where the revenue does.

  5. 05

    Design for the device in the room

    Tablet-first layout, because that is what sits between a clinician and a patient.

Other work

All case studies →

Something similar on your plate?

Thirty minutes, no deck. I will tell you whether it is worth doing at all.