This is general operational guidance, not legal, clinical or regulatory advice.
Pointing the domain at the new site is the moment everyone watches. The real test starts about ten minutes later. Patients arrive through pathways you didn't expect, forms meet live data, payments behave differently outside test mode, and the first exceptions turn up.
Launch day is an operational handover. You need a clear go/no-go decision before the switch, and a small control room for the 24 hours after it. Here's how we run both with telehealth clinics on HubSpot.
Draw the boundary before you launch
Administrative automation and clinical decision-making are different things, and the regulator treats them differently. The TGA's guidance on clinical decision support software explains that some software supporting clinical decisions is regulated as a medical device. What your software does, and how you describe it, matters.
For launch day, a practical boundary looks like this:
- Agents may organise: collect admin details, check a required document is present, route a case, notify the right person and prepare a summary.
- Agents may not decide: interpret pathology, diagnose, recommend treatment, prescribe or approve a clinical outcome.
- People approve: named clinicians make clinical decisions, and accountable staff approve sensitive operational actions.
That boundary needs to live in the workflow design, permissions, notifications and audit trail. A policy document alone won't stop a workflow at 2am.
The go/no-go gates
Websites, portals, CRM records and clinical systems are often tested by different people. Each part can look ready while the journey between them isn't. One checklist with one owner and named approvers fixes that. Clear these seven gates before you switch on.
1. Public journey
- Every service page, price, eligibility statement and call to action is confirmed.
- The mobile journey works from first visit to the next committed step.
- Dynamic components never show empty, stale or impossible values.
- Someone has signed off clinical and compliance wording, and you've recorded who.
2. Identity, access and consent
- New registration, returning login and password recovery all work.
- The right person sees the right record, and nothing else.
- Consent and privacy explanations appear where they matter.
- Staff use their own roles. No shared accounts.
3. One record and data ownership
- You know which system owns bookings, payments, pathology requests, documents and clinical notes.
- You've defined what HubSpot stores, references or deliberately leaves out.
- Duplicate controls are in place before launch.
4. Integrations and failure behaviour
- Each connection has been tested with real-world edge cases.
- You know what happens when a payment, booking, form or API call fails.
- There's a documented manual fallback.
5. Communications
- Every email and SMS has been triggered with controlled test contacts.
- Timing, time zones, suppression and duplicate prevention are checked.
- No message implies a clinical decision that hasn't been made.
- Patients can easily get help when an automated message is wrong.
6. Bounded agents
- Each agent has defined tools, approved knowledge, stop conditions and an escalation path.
- A named person approves anything with clinical, financial or significant personal consequences.
7. Rollback and ownership
- There's a tested rollback path for the site and critical integrations, and you know how long the old experience stays available.
- One person is launch lead, and each system has an owner.
- Non-essential changes are frozen.
If a gate fails, decide on the spot: fix it, cover it with a written manual process, or move the date. Write the decision down.
Create one launch-day record
During launch, the team should answer one question without opening five systems: where is this person in the journey, and what happens next?
That doesn't mean copying clinical detail into HubSpot. It means modelling the operational facts the team needs:
- identity and verified contact details
- consent and communication preferences
- journey stage
- whether required admin documents are present
- the owner of the next action and when it's due
- an exception status and reason
- links to the clinical system where sensitive information belongs
If the record is hard to read on a normal day, it will be harder on launch day. Your CRM reflects how your operation really works, so fix the record before you rely on it.
Put every exception in one queue
Launch problems get dangerous when they're scattered across personal inboxes, chat threads and spreadsheets. Build a single exception queue before go-live, using a ticket pipeline or a dedicated exception record. Typical exception types:
- assessment started but not submitted
- submission failed
- duplicate patient or duplicate journey
- required document missing
- payment or subscription mismatch
- external sync pending
- result available but release authority not confirmed
- next step unowned or overdue
Each exception needs an owner, a severity, a due time, a resolution rule and a human escalation path. An agent can classify the exception and gather context. It should never quietly resolve a clinical or ambiguous case.
Run the first 24 hours like a control room
Before go-live
- Name the go/no-go owner.
- Confirm production domains, sending identities, permissions and licensed assets.
- Decide who makes the first real booking or transaction.
- Open the exception queue and test every alert recipient.
At go-live
- Run one controlled end-to-end journey on a real phone.
- Check the HubSpot record, journey stage, document and next action.
- Check the patient confirmation and the staff notification. The staff alert should contain only what staff need.
- Agree the rollback decision point before you increase traffic.
Two to six hours in
- Review duplicate, failed and abandoned journeys.
- Compare payments, bookings and submissions across source systems.
- Assign every open exception.
- Separate real defects from training or content questions.
- Record decisions and temporary workarounds.
By the next business day
- Confirm there are no unowned high-severity exceptions.
- Review where journeys dropped off and why.
- Turn temporary fixes into backlog items with owners.
- Remove test contacts, payments and subscriptions safely.
- Share a short internal launch summary and the plan for the next seven days.
Watch the signals that prove the journey works
Page views and form counts tell you people arrived. They don't tell you the journey worked. Build the launch dashboard around these instead:
- one person creates one operational record
- journey stage moves once, in the right direction
- documents attach to the right record
- every failure creates a task or ticket
- alerts go to a role or team, never a developer's personal address
- health answers stay out of routine notifications
- open exceptions, and how old they are
If you've read our take on dashboards, you'll know why: flow, exceptions and ageing tell you what to do next. Vanity numbers don't.
Keep an eye on privacy obligations
Know where personal information flows on launch day and who can see it. Then check the calendar. The Privacy and Other Legislation Amendment Act 2024 brings in automated-decision transparency obligations from 10 December 2026. If a computer program makes, or does something substantially and directly related to making, decisions that could significantly affect people's rights or interests, your privacy policy will need to say so. Launch is a good time to list which of your automations do that.
The Australian Commission on Safety and Quality in Health Care is also developing national safety and quality standards for virtual care. A launch with named owners, a clear boundary and an audit trail is well placed for whatever those standards ask.
After the first 24 hours
Book a review before the team drifts back to normal work. Capture what broke, what held and what staff found confusing. People stop using systems that make them work harder, so keep the staff view simple. The checklist, exception design and approval model you built for this launch become the starting point for the next one.
Planning a telehealth launch and want a go/no-go plan and control room ready before you switch on? Talk to us about telehealth.