What we need from you, what your patient sees, and how the result is measured

These are the questions that come up in the first meeting, almost always in this order. We answer them here with the same detail we use sitting across from an operations director, and each answer links to the piece that treats it properly.

If you would rather start with the vocabulary, the glossary defines the 30 terms used below with their operational consequence attached.

What does Surface do, and who is it for?

Surface stands on one stretch of ground: between the order a doctor writes and the appointment that actually happens. The rest of your operation stays as it is.

Does it replace our scheduling team?

No. Your team keeps scheduling, keeps resolving odd cases and keeps serving the patient who calls in. Surface takes the work nobody currently gets to: walking every order that was never scheduled, writing to each patient, following up within the rules your protocol allows, and leaving the appointment booked. A scheduler serves the person who calls her well, and the volume that hurts is the patients who never called. Adding headcount does not drain a queue: the load on your team goes down, because Surface writes, sends and books on its own, and they supervise and approve from the dashboard.

Does it work the same for lab, imaging and dental?

Yes, and what changes between units is the preparation, while the mechanism stays the same. A blood count books with almost no constraints, a colonoscopy carries diet and days of lead time, and an MRI depends on whether the order says with contrast or without. Surface applies each unit's rules exactly as the provider wrote them and follows them without exception. That is why we publish one page per unit describing the shape of the queue in each, plus per-exam guides that go down to the detail of a single order.

What does Surface need from our clinical system?

Almost every provider we talk to believes their system disqualifies them. It almost never does, and this section exists to get that belief out of the way.

Is an API required?

No. If your clinical system exposes an API or a database we can read, we integrate for real from the start, and that is the route we prefer. If it does not, or if your IT team is booked solid for six months, we start with a file you generate, you review and you control, and we move to the real integration once it is ready. Neither route requires migrating data or changing how your people work. What we need from your system and what we do not has the field-by-field list, and the per-system pages cover TrakCare, Masterkey, Epic and Rayen.

What data do you need from us?

The minimum needed to know what was ordered, for whom and when. In practice: patient identifier, phone number, the service as it was written on the medical order, the date, the professional who issued it, and the scheduling status if your system tracks it. We do not need diagnoses, we do not need the free text of the medical record and we do not need history. If a field makes you uncomfortable, it comes out and the system keeps working on the rest.

What does our IT team have to do?

On the file route, one scheduled export and nothing else. On the integration route, opening read-only access to the tables or the endpoint that already exists, plus whatever your security policy demands. We do not ask anyone to install software inside your servers, unless you want the on-premise deployment. During onboarding we do the heavy lifting, including the part that in other projects lands on the client's team: the founders sit in the operator's chair every day.

What does the patient see when the agent writes?

This is the question that decides the purchase. One badly calibrated message to a patient costs more than any appointment gained, which is why the contact policy gets configured before anything else.

Whose brand shows up in the message?

Yours. The message goes out with the provider's name, number and tone, and the patient never sees the word Surface. The relationship with the patient belongs to the provider, so does the trust holding it up, and the product is built on that premise. Your brand, your data, your conversations explains how it is set up, including what happens to the number the messages come from.

How many times does the agent write to a patient?

As many as you authorize. The contact cap, the working hours, the waiting days between attempts and the allowed channels are set per unit before the first message goes out, and the agent follows them exactly. It stops in three cases: the appointment is booked, the patient asks it to stop, or the patient replies with something that needs a human. The default we propose is conservative, because one message too many costs more than one appointment gained. How the agent decides publishes the full policy.

Is this harassment?

No, if the cap exists and is respected. Yes, if it does not. That is why the cap is the first thing configured, and why the policy is public instead of living inside a black box. Patient harassment in clinical operations has a practical definition: contacting someone who already said no, or pushing past what the provider itself considers reasonable. Surface can do neither, because your protocol sets the limit and opt-out applies instantly.

What happens if the patient replies with something clinical?

The agent stops and escalates. If the patient describes a symptom, asks about their diagnosis, requests an order or reports something urgent, the conversation leaves the automated flow and lands in your team's inbox with the full context. The agent books, confirms and reminds; it does not interpret symptoms, does not give medical advice and does not modify an order. The escalation logic is published because it is the part people ask about most and the part this market documents least.

What if the patient does not want to be contacted?

One message and we never write again. Opt-out applies instantly, with nobody having to process it by hand, and it is recorded so no later campaign can run over it. It holds for the channel where the patient asked and for every other channel too. A patient who opts out is information as well: it tells you that that order needs another route, and the dashboard shows it as such.

How do we know whether it is working?

What exactly do you measure, and what is the denominator?

The denominator is the set of orders issued in a period that, by your own rules, should have ended in a booked appointment. On that base we measure how many were scheduled, how many were attended and where the rest fall off, stage by stage, with the revenue attached to each. The comparison runs against a control group agreed before we start, because comparing against last month lets seasonality eat the reading. How we measure publishes the full definitions, including what counts as a booking and what does not.

Can you name a client already using Surface?

Not yet. We work with Chilean providers who have not authorized us to name them, and publishing a case without that permission would be the first sign that we would not guard your data either. Once we have the authorization, the case ships with the name, the methodology and the denominator in plain view. Until then we would rather you judge what you can verify today: who we are and what this same team already runs under health regulation, plus the methodology we will measure your result with.

Who owns the data?

Who sees the patient's data?

Your institution, and nobody outside it. The agents work without the patient's identity, which stays inside the provider's perimeter, and the sensitive data defined by Chile's Law 19.628 never reaches a third party. If your policy requires that nothing cross the boundary of your infrastructure, Surface runs entirely on-premise, inside your own servers. Your brand, your data, your conversations details where each piece of data lives and under which legal arrangement.

What happens to our data if we stop working with you?

It leaves with you. The conversations, the bookings and the contact history are yours during the contract and stay yours afterwards: we export them in an open format and delete our copies within whatever window the contract sets. No patient data ends up locked in a format only we can read, and the number your patients were written from stays yours. Putting this in writing before we start costs less than arguing about it later, so we put it in writing.

How long does it take to start, and what does it cost?

How long does implementation take?

Three weeks to results. Day 1 is setup: we agree on scope, denominator and contact rules, and we receive the first file. One week later you are in production, with real messages going out and real appointments coming in. From there the work is tuning, and the day-by-day calendar is published so you can hold us to every milestone on its date.

What does Surface cost?

We do not publish a price, and we would rather say why than invent a table. The model depends on your order volume, on how many units come in, and on whether your institution bills fee-for-service or receives capitation, because in the first case the value sits in the service that gets booked and in the second in the event that gets avoided. Write to us with those three facts and we come back with a concrete number the same week. If the number does not work for you, say so and we do not push: that is how we work.

Two questions that arrive late and are worth pulling forward: whether booking more appointments makes no-show worse (it can, and there is a way to avoid it) and what Surface actually competes against (the four real alternatives, compared one by one).