From routing uncertainty to absolute operational control.
The quickest way to see how the workflow fits together.
Resolve before you send
Find the right recipient before a strong packet goes to the wrong place.
Keep the request record intact
Keep the packet, proof, and returned records tied to the same request.
Make the next action obvious
See what is current, what happened next, and what still needs action.
The workflow
How the workflow moves
Resolve the route, run the provider request, and review the production without losing the record.
Step 1
Start from the case
Open or select the case first. ReturnRail is designed around the case as the parent object so related provider requests stay coordinated instead of becoming disconnected tasks.
Why this matters: That makes packet history, shared materials, and returned documents much easier to manage across a case.
Step 2
Let ReturnRail suggest the destination during intake
As the team adds the provider request, ReturnRail can suggest the best-known entity, department, fax, address, portal, or alternate route in the same flow.
Why this matters: Many request problems start because the packet was valid but the destination was wrong. ReturnRail treats routing as first-class work instead of a hidden assumption, but it keeps the simple path inside intake whenever it can.
Step 3
Open the provider request inside the case
Create the provider request with the right legal path, categories, provider details, and destination plan. If categories split across departments, ReturnRail helps the team separate that work inside the same case.
Why this matters: That keeps the request honest. It avoids pretending one destination covers billing, imaging, and treatment records when the provider actually splits them.
Step 4
Prepare and review the operative packet
Use the request record to keep supporting files separate from the reviewed packet. ReturnRail preserves the current reviewed packet clearly and keeps older packet versions visible as history rather than hiding them in file timestamps.
Why this matters: When someone asks what was actually cleared for sending, the request should answer that immediately.
Step 5
Track the live request from the request record
Once the request is in motion, the request detail becomes the operational record. It keeps the current packet, proof, service tasks, notes, follow-up, and returned-records review in one place.
Why this matters: Operators should not have to reconstruct the story from inboxes, spreadsheets, and downloaded files.
Step 6
Use My Work and the tracker to stay oriented
My Work and Active Requests help the team see what changed, what needs attention now, what is waiting on provider, and what is done for the moment.
Why this matters: ReturnRail is meant to reduce re-entry cost. A busy operator should be able to come back after an interruption and understand the next move quickly.
Step 7
Review what comes back and request supplements if needed
Returned documents stay attached to the same request so the team can review completeness, identify missing categories, preserve the packet/proof context, and drive supplement follow-up when the production is incomplete or wrong.
Why this matters: The review process is strongest when the returned files stay connected to what the provider was responding to in the first place.
Where to go in the product
Where each workspace fits
These are the pages that matter first and what each one is for.
Start a Case
Use this when the case is not set up yet and you want it to become the parent container before requests start multiplying.
Open Start a CaseTarget Resolver
Use this when the provider is known but the destination still needs deeper routing work or split-category review.
Open Target ResolverNew Request
Use this once the case exists and the team needs to add one more provider request with the right legal path and categories.
Open New RequestMy Work
Use this as the personal inbox for requests assigned to you, recent changes, and things that need action now.
Open My WorkActive Requests
Use this as the downstream request operations surface once a route is known and the request is in motion.
Open Active RequestsProvider Library
Use this to review saved routing knowledge, stale evidence, split coverage, and corrections that should improve future requests.
Open Provider LibraryWhat makes ReturnRail safer to trust
Why firms can trust the record later
The important facts stay clear later, not just in the moment.
Current packet clarity
Reviewed packet history stays visible so the current operative packet is obvious instead of buried in filenames.
Send readiness
The send gate helps prevent a request from looking ready when the reviewed packet or required confirmations are still missing.
Destination honesty
If a provider splits coverage across departments, the platform surfaces that split instead of collapsing it into a misleading single route.
Operator re-entry
My Work, tracker views, and request summaries make it easier to return after an interruption and know the next move.
Next step
If this clicks, open one request and follow it through.
Use the FAQ for detail. Use the product for the real walkthrough.