> **Going live is the pilot.** Go live with the twenty clients rather than going live and
> choosing them afterwards: the first night's run bills and chases every client on file, so
> whoever is loaded on day one is who gets invoiced and reminded on day one.

# Running the pilot

CareBill writes to your clients on its own. That is the point of it, and it is also the
risk. A wrong number in a reminder to a hospital you have served for fifteen years costs
more than a late invoice does. So the first fortnight is deliberately small.

Before anything else, open **Setup → Readiness**. It checks thirty-odd things about this
particular install — HTTPS, the cron key, whether the nightly job has ever run, clients with
no email address, invoices already sixty days overdue that would get an escalation letter on
the first night. Clear everything marked *fix first*.

## Choose twenty clients

Not the biggest twenty, and not the worst payers. You want:

- **Clients who pay.** If a reminder goes out wrong, a good payer rings you; a bad payer uses
  it as an excuse.
- **One brand, one service type.** AMC only, or cloud only. Mixing them on day one means two
  things can be wrong at once and you will not know which.
- **A range of ageing**, including two or three genuinely overdue, so the ladder is exercised.
- **Nobody in a live dispute.** Ananta stays out of the pilot.
- **Nobody you are mid-negotiation with** on a renewal.

Write the twenty down before you start. The temptation to add "just one more" is what turns a
pilot into a rollout nobody decided on.

## The week before

1. Load those twenty clients, their services and their open invoices. Check each one by hand
   against the sheet. Twenty is few enough to do properly.
2. Check every one has an email address that a person actually reads. Not `info@`.
3. Set a collector on each, or call tasks land nowhere.
4. Run **Reports → Ageing** and compare it against your own follow-up sheet. If they disagree,
   the data is wrong, not the report. Fix it before a single reminder goes out.
5. Set the mail driver to **log** and run the nightly job by hand:
   `php cron/daily.php`. Nothing sends. Read what it *would* have sent, in Reminders → Outbox.
   This is the single most useful hour in the whole exercise.
6. Only when that reads correctly, switch the driver to live.

## The first fortnight

Every morning, in this order, ten minutes:

- **Worklist** — what the system thinks needs doing today.
- **Reminders → Outbox** — what went out yesterday. Read two or three in full.
- **Bank matching** — import the statement, confirm the matches.
- **From clients** — payment advices and queries raised in the portal.

What you are watching for:

| Sign | What it means |
|---|---|
| A client replies confused | The invoice, period or amount is wrong. Stop that client's automation and fix the data. |
| Reminders going to the wrong person | The contact flags are wrong. Fix before it annoys someone senior. |
| A payment not matching | The alias is missing. Map it once and it matches for good. |
| The same query from several clients | The templates need rewording, not the clients. |
| Nothing at all happening | The cron is not running. Check Readiness. |

Keep the escalation stage off for the pilot if you would rather: set the rules at stage 6 and
above to inactive under **Reminder rules**. You can turn them on in month two once you trust
the first five stages.

## Deciding whether it worked

After a fortnight, four questions:

1. Did every invoice that should have been raised get raised, on time, without anyone
   remembering? Check **Reports → Revenue leakage**; it should be empty for the twenty.
2. Did the reminders read like something you would have sent?
3. Did payments match themselves? Look at how many bank credits needed manual mapping in week
   two versus week one — that number should fall, because the aliases learn.
4. Did anyone complain?

If the answers are yes, yes, yes, no — widen to a hundred, one brand at a time. If not, the
gap is almost always data rather than software.

## What not to do

- **Do not import the whole book and switch cron on the same day.** Six hundred invoices and
  an escalation ladder is not a pilot, it is an incident.
- **Do not run it alongside the spreadsheets for months.** Two systems means two truths and
  the team will trust neither. A fortnight of overlap, then pick one.
- **Do not let the first person to use it be the newest member of the team.** Whoever knows
  the book best should be the one who spots that something is wrong.
- **Do not switch on e-invoicing, the portal and online payments in the same fortnight.** Each
  is its own pilot. Billing and collections first, because the rest depends on them being right.

## The order after that

1. Widen billing and collections to the full book, one brand at a time.
2. Client portal, to the same twenty first.
3. Online payment links.
4. E-invoicing, once the invoice numbering is shortened to sixteen characters.
5. Export invoicing, when the next overseas deal is billed.