Both founders work inside your operation, 6am to 11pm, answering in under 1 hour

We work from inside. During the rollout both founders sit in the same WhatsApp group as your schedulers, we answer in under 1 hour between 6am and 11pm, and we do by hand the work the agent will later do.

We write it out in detail because it is the part of the proposal you cannot verify before signing, and the part that weighs most after signing.

What do the first 3 weeks look like from your side?

The calendar is short and fixed in advance: setup on day 1, production in one week, measured results from there. That pace does not depend on your IT department opening a project, because we start from the data source your institution already controls.

If your clinical system allows a direct read from day one, we do it from day one. Otherwise an exported file your team controls is enough to start, and the real integration lands later without redoing anything already written: you can start without an API. The day-by-day calendar is in what happens in 3 weeks.

Who do you talk to, and how fast do they answer?

The two of us. Pablo Díaz and Víctor Perl, in a WhatsApp group with your scheduling lead and the schedulers who will use the dashboard. There is nobody in between the person who reports a problem and the person who writes the code. Who we are and which regulators this team already operates under is in about us.

The two weekly meetings have a fixed agenda: what got booked, what fell through, which rule changed. We bring the numbers even when they are bad, because the point of those meetings is to correct fast while the volume is still small.

What do we do that a vendor our size is not supposed to do?

During onboarding we do the schedulers' job. Literally: we read the order, find the slot, offer the patient a time, and leave the outcome dispositioned in your system.

It buys three concrete things. We learn your rules from the inside instead of asking for them on a form. Your team sees the queue drop in week 1 instead of week 3. And the mistakes are ours, made by hand at small volume, before the agent makes them at scale.

It is also uncomfortable, and the discomfort is the useful part. Scheduling healthcare has rules written in no manual: which exam cannot share a day with another, which one requires fasting, which one needs 3 days of preparation, which patient cannot travel to another district. The first time you get one of those wrong, somebody on your team tells you to your face. That conversation teaches more than a month of requirements gathering.

How do your protocols get written down, and who decides when they change?

The protocols are yours and stay yours. We write them down as executable rules, your team approves them, and no rule reaches production until somebody at your institution has confirmed it.

The full loop, every time:

1. Your team states the rule in its own words, in the meeting or in the WhatsApp group.
2. We write it the same day and show you the concrete case where it would have applied yesterday.
3. You confirm or correct the wording. Only then does it reach production.
4. The rule is stored with a date, an author and the case that produced it, so that in 6 months anyone can see why it exists.

Contact rules run through the same loop: how many times the agent writes, at what hours, when it stops for good, and what it never says. That is the limit that keeps follow-up from turning into patient harassment, and it is described in full in how the agent decides.

What happens if something breaks on a Tuesday at 9pm?

You write to the group and one of the two of us answers. That is the entire escalation path.

What happens next, in order:

1. We cut the affected flow. The agent stops writing about that case within minutes, with no deployment and no maintenance window.
2. We contact the patient with wording you approve, or we hand it to you if you prefer the voice to be your scheduler's.
3. The next day you get the explanation of what happened, the new rule that prevents it, and the case stored so it does not repeat.

The hour matters for a technical reason. On WhatsApp, the window in which a business can reply freely opens when the patient writes and lasts 24 hours; once it closes, only pre-approved templates can be sent. A problem answered at 9pm gets solved inside the conversation the patient already opened. One that waits until Monday gets solved with a template, which is a worse conversation.

What do we need from your team?

Little, and it is worth stating in numbers, because every vendor promises it will not create work.

• A data source. An exported file your institution controls is enough to start: it works without an API.
• One operations person to answer scheduling questions. Between 2 and 3 hours in week 1, considerably less afterwards.
• A WhatsApp number in your institution's name, and approval of the display name the patient will see: the brand on screen is yours.
• Half an hour to agree the denominator before anyone looks at the first result, and to define the control group: this is how we measure.

None of that forces your IT department to open a project. When it does open one, we integrate properly against the medical record and the file stops existing.

Why do we work this way, and when does it stop scaling?

We compete against companies with 7 years in the Chilean healthcare market. On tenure they win. What we offer instead is focus and speed: this problem is the only thing we build, and the person who decides what gets built is in your WhatsApp group reading the same message you are.

The limit of this way of working is arithmetic, and we would rather say it before you ask. Two people cannot sit in the operator's chair of 20 institutions at once.

When that point arrives, the response commitment and the direct access to whoever decides stay in place, because they are written into the contract. The manual work moves to a team trained on the same rules we wrote with you, and we tell you by name and date before it happens.

In the meantime, the cheap way to evaluate all of this is a small 3-week pilot, with an agreed denominator and results we review on the same dashboard you do: how we measure it.