How it works

See the handoff, the work, and the evidence.

Grasshopper has two operating paths: build a practice from the ground up, or take over defined work in a practice that is already running. Both use the same rule—scope, ownership, timing, and evidence should be visible before the work feels “handled.”

20 minutes · honest disqualification included

Operating routeLaunch or established practice
  1. 01
    Confirm fitChoose the right scope
  2. 02
    Define the handoffInputs, access, decisions
  3. 03
    OperateDo the contracted work
  4. 04
    Show statusLogs, checklists, reports
  5. 05
    Exit cleanlyOwnership stays with the client
PathsLaunch + established practice
Ledger9 activity commitments
EvidenceNamed in every row
OwnershipPractice stays yours

The journey changes with the practice stage. The proof standard does not.

Practice Launch begins with incomplete infrastructure. Complete or Essentials begins with live systems and work already in motion. The stages below show what each path needs to make visible.

Confirm fit

Is this the right operating path?

Starting a practice

Confirm the target go-live window, payer priorities, input readiness, and whether the full Practice Launch scope is needed.

Running or switching a practice

Confirm current systems, completed-session volume, open work, and whether Complete or Essentials matches the handoff.

Visible as

Fit decision, disqualifiers, and selected service

Define the handoff

What moves, what stays, and who decides?

Starting a practice

Identify required launch inputs, adviser decisions, selected payer panels, system choices, and the go-live target.

Running or switching a practice

Inventory systems, administrator access, current vendors, claims and denials in flight, patient balances, and owner-only decisions.

Visible as

Input checklist, responsibility map, or transition inventory

Start the work

What does Grasshopper actually operate?

Starting a practice

Submit complete payer applications, build the practice systems in parallel, prepare go-live, and track first claims.

Running or switching a practice

Take over the contracted front-office and revenue-cycle queues after agreed access, cutoff, and overlap conditions are clear.

Visible as

Work queue, submission record, checklist, and assigned owner

See status

How is activity evidenced?

Starting a practice

Use logged payer contacts, weekly status notes, the go-live checklist, and first-claim records instead of a vague project update.

Running or switching a practice

Use queue status, denial and AR work logs, Friday snapshots, and monthly revenue reporting tied to published timing.

Visible as

The evidence mechanism named in each Commitment Ledger row

Leave cleanly

What happens when the engagement ends?

Starting a practice

Keep the practice, payer contracts, client relationships, data, and launch systems whether or not ongoing service continues.

Running or switching a practice

Use the signed terms to assign open work, records, credentials, access removal, and the final service date without transferring ownership of the practice.

Visible as

Written offboarding plan governed by the signed agreement

The work should leave a status trail.

These are blank illustrative structures—not client records, performance evidence, or promises that every engagement uses an identical format. They show the kind of fields that make an activity inspectable.

Illustrative blank templateNo PHI · no client data · no results

Practice Launch + Credentialing

Payer-status update

A blank structure for showing the latest contact, current status, next action, and the item waiting on the payer or practice.

Selected payer
[payer name]
Last contact
[date + channel]
Current status
[plain-language status]
Next action
[owner + action + date]
Illustrative blank templateNo PHI · no client data · no results

Practice Launch

Go-live checklist

A blank readiness view for the systems gate before the first session and the first-claim tracking that follows.

Required inputs
[complete / open]
Systems checks
[checklist status]
First session
[planned date]
First claim per payer
[tracking status]
Illustrative blank templateNo PHI · no client data · no results

Essentials + Complete

Weekly operations snapshot

A blank Friday view for queue status, aging items, owner decisions, and the next operating priorities.

Scheduling queue
[status]
Inbox aging
[status]
Owner decisions
[items, if any]
Next-week priorities
[short list]

Illustrative only. No protected health information, real payer record, claim identifier, client result, or implied outcome appears in these previews.

A commitment is not complete until the trigger and evidence are named.

Every row below comes from the central claims source. It describes Grasshopper-controlled activity—not revenue, payer approval, reimbursement, rankings, or any other outcome controlled by someone else.

Action

What Grasshopper does

Timing

When the action is due

Trigger

What starts the commitment

Evidence

Where status is visible

Commitment Ledger9 activity commitments

Action · timing · trigger · owner · evidence · service

Claims

Claims submitted within 2 business days of session completion

Timing
Within 2 business days
Trigger
Every completed session
Owner
Grasshopper
Visible in
Submission status in the operating record

Denials

Denials worked within 5 business days

Timing
Within 5 business days
Trigger
Every denial
Owner
Grasshopper
Visible in
Denial work log

Reporting

Monthly revenue report with charges, collections, denial rate, AR aging, and payer mix

Timing
By the 7th (or next business day)
Trigger
Every month
Owner
Grasshopper
Visible in
Monthly revenue report

Receivables

Accounts receivable over 60 days flagged with an action plan

Timing
Monthly
Trigger
Any balance older than 60 days
Owner
Grasshopper
Visible in
AR action plan

Launch filings

All selected panel applications submitted within 14 days of complete inputs

Timing
Within 14 days of complete inputs
Trigger
Per launch
Owner
Grasshopper
Visible in
Submission record

Every payer follow-up logged, with a status note to the client

Timing
Weekly
Trigger
Each open payer application
Owner
Grasshopper
Visible in
Payer contact log and weekly status note

Systems pass the go-live checklist; first claim per payer tracked to payment

Timing
At go-live
Trigger
Each launch
Owner
Grasshopper
Visible in
Go-live checklist and first-claim record

Front office

Same-business-day response to patient scheduling messages; zero unworked inbox items older than 24 hours

Timing
Every business day
Trigger
Scheduling and inbox messages
Owner
Grasshopper
Visible in
Inbox and scheduling work queue

Weekly operations snapshot

Timing
Every Friday
Trigger
Weekly
Owner
Grasshopper
Visible in
Weekly operations snapshot
IncludedPublished activity, timing, owner, and evidence
Not includedAn outcome guarantee or a promise about payer-controlled timing
Read the outcome boundary

The exit belongs in the operating design.

The practice, payer contracts, client relationships, and practice data belong to the client. Offboarding is intended to be clean, per the signed terms.

Client-ownedThe practice
Client-ownedPayer contracts
Client-ownedClient relationships
Client-ownedPractice data
Written exit planAgreement-specific

The signed terms should answer four practical questions.

  1. 01

    What is the final service date and required notice?

  2. 02

    Who owns every claim, denial, balance, payer item, or inbox item still open?

  3. 03

    Which records, credentials, exports, and reports must be returned or retained?

  4. 04

    When is Grasshopper access removed?

Exact notice, transfer, and cutoff terms are not invented on this page; they belong in the signed agreement and offboarding plan.

Use the fit call to confirm the handoff—not to discover whether the work is visible.

Bring the practice stage, payer priorities, current systems, and the work you want to stop owning. Grasshopper will confirm fit and say plainly when another path is better.

20 minutes. Please do not include health or client information in this form.