
By Rovaryn Digital · 14 min read
Why Most RTW Software Evaluations Go Wrong
Picture this: your third open lost-time claim of the quarter arrives on Monday morning. Your spreadsheet has two tabs for active cases, a third tab you stopped updating in February, and a sticky note on your monitor reminding you to submit the Washington Stay-at-Work reimbursement application — for a worker who returned in April. The one-year filing window closes in six weeks.
You decide it's time to look at software. You search, book three demos, and within a day you're being walked through enterprise risk-management platforms built for a Fortune 500 risk department with a dedicated RMIS administrator. The pricing is custom, the implementation timeline is measured in quarters, and return-to-work is one tab buried inside a claims module you don't control because the carrier owns the claim.
You close the browser and go back to the spreadsheet.
This guide is for the coordinator, HR manager, or safety officer at a 50–1,000-employee operation running five or more workers' comp claims per year. It names the categories of software you will encounter, explains what each one actually does, and gives you a structured set of criteria to evaluate any tool against the real operational job: documenting a transitional duty assignment, tracking the restriction window, generating compliant paperwork, and recovering state program reimbursements before the filing deadline expires.
By the end, you will have a decision framework you can use to evaluate any return-to-work software in a single demo session.
The Four Categories of RTW Software (and What Each One Actually Is)
Understanding the market means understanding that most tools you will encounter were not built for your use case. Here is an honest account of each category.
Enterprise RMIS Platforms
Enterprise risk management information systems — Riskonnect, Origami Risk, Guidewire ClaimCenter, Cority, and their peers — are full absence, claims, and EHS platforms built for self-insured Fortune 1000 operations. RTW case management is typically one embedded module within a much larger system. Implementation runs multi-quarter. Pricing is custom and substantial, negotiated at the enterprise contract level.
If your organization has a dedicated risk-management department, a TPA managing thousands of claims per year, and is self-insured, an enterprise RMIS may be appropriate. If you have a commercial workers' comp policy and one coordinator managing RTW as part of a broader HR or safety role, you are paying for a significant amount of infrastructure you will not use — and you may find RTW workflow subordinated to the carrier's or TPA's claim-management priorities rather than your own program continuity. See the enterprise RMIS vs. SMB RTW tool comparison for a fuller breakdown.
Carrier-Bundled RTW Tools
Several carriers — Pinnacol Assurance, Texas Mutual, Kinetic Rapid RTW among them — offer RTW tools bundled with a commercial policy at no separate charge. These tools typically generate forms and provide basic job-matching suggestions, which is genuinely useful as far as it goes.
The structural limit is portability. The tool, the data, and the program live inside the carrier's ecosystem. When you renew with a different carrier — or when the carrier non-renews you — the program history does not transfer. The tool is also aligned to the carrier's claim-closure interest, which may or may not align with your interest in building a durable modified-duty library or capturing state reimbursements the carrier isn't tracking for you. The carrier-bundled vs. independent RTW tool comparison examines this tradeoff in detail.
State Agency Toolkits and Spreadsheets
State agencies — Washington L&I, New York WCB, and others — publish free toolkits: current forms, guides, and sample policies. This is the correct starting point for understanding what each program requires. It is not a case-management system.
A spreadsheet built on top of state forms works adequately when you have one or two concurrent cases and a coordinator with deep program knowledge. It breaks under three or more simultaneous cases, produces no audit trail, has no restriction-tracking logic, and cannot flag the Washington Stay-at-Work one-year filing deadline before it lapses. If your operation is at that spreadsheet inflection point, the spreadsheet vs. RTW software comparison lays out the transition case.
Purpose-Built RTW Workflow Tools
The fourth category is the one this guide is structured to help you evaluate. Purpose-built return-to-work software focuses on the employer-side workflow: case intake, restriction documentation, duty matching against a library of transitional positions, time-and-day tracking against state program parameters, document generation, and reimbursement application assembly.
These tools are not claims-adjudication platforms. They do not determine eligibility or benefits. They document and track the employer's side of the RTW process — which is exactly what a coordinator managing five to fifty active cases per year actually needs.
Seven Criteria That Separate Useful from Expensive
Use these criteria to structure any demo or RFP. They map directly to the operational failure modes that mid-sized employers actually hit.
1. Case State and Restriction-Window Tracking
A return-to-work case has a beginning, a middle, and a defined end. The middle is bounded by the treating physician's restrictions: specific physical limitations (no lifting over ten pounds, no overhead reach, maximum four hours standing) that change as the worker recovers. A tool that generates a single document but holds no case state cannot tell you on a Tuesday morning which workers are currently on transitional duty, which restriction windows expire this week, or whether a worker has been on modified duty long enough to trigger a state program filing deadline.
Ask in the demo: Show me what a case looks like on day 14. Show me how I see all open cases at once. Show me how the system handles a restriction update from the physician mid-assignment.
2. Duty Matching — Ranked, Explainable, and Human-Acted
Duty matching is the process of identifying which of your existing job positions a worker with a given restriction profile can safely perform. Effective software maintains a library of your transitional positions — each with documented physical demands — and surfaces a ranked list of candidate positions when you enter a restriction profile.
Two important operational points. First, the match is a recommendation acted on by a person, not an automatic assignment. No software can auto-assign a worker to a position, auto-schedule shifts, or auto-terminate modified-duty status. The coordinator, the supervisor, and ultimately the treating physician's written approval govern placement. Second, the match should be explainable: you should be able to see why a position was suggested so you can defend that decision in a claim dispute or audit.
Ask in the demo: Show me what happens when I add a 10-lb lift restriction. How does the system rank candidate positions? What does the explanation look like?
3. Document Generation Tied to Case State
Every state program that reimburses light-duty wages requires documentation: a written job description submitted to the attending provider, a written approval from that provider, daily or weekly time logs, and a reimbursement application assembled with specific supporting materials. Generating these documents manually from templates — pulling data from a spreadsheet into a Word file — is the single largest source of filing errors and missed reimbursements.
The software should generate these documents from the case record, not from manual data re-entry. A job description produced from the case's restriction profile and transitional position data is less likely to have a discrepancy than one typed separately.
Ask in the demo: Show me how a job description is generated. What fields pull from the case record? What does the provider-approval workflow look like?
4. State Program Rule Awareness
Washington's Stay-at-Work program reimburses 50% of base wages for up to 120 days worked, up to a maximum of $25,000 per claim for injuries on or after January 1, 2025 — roughly double the prior cap, as established by House Bill 2127. (AGC of Washington, 2025.) The reimbursement application must be submitted within one year after the light-duty work is completed. (WA L&I, 2025.) A partial day counts as one reimbursable day, but a day worked outside the approved job description or approved hours is ineligible — so if the provider approved four hours and the worker clocked six, that day does not qualify. (WA L&I Complete Stay at Work Guide, 2024; ERNwest, 2025.)
Oregon's EAIP repays 50% of early return-to-work gross wages for up to 66 work days within a consecutive 24-month period, subject to a $5,000 combined cap on worksite modifications and equipment, plus a one-time administrative fee. (OR WCD, 2025.) Texas requires a written Bona Fide Offer of Employment meeting every element of 28 TAC §129.6 to give the carrier standing to reduce or suspend benefits after a refusal; a mailed offer is deemed received five days after mailing, and the carrier may reduce indemnity benefits on the earlier of the worker's rejection or the seventh day after that deemed receipt. (TDI-DWC RTW Guide, 2023; 28 TAC §129.6(g), 2024.)
Software that is not aware of these parameters — the day caps, the wage caps, the ineligibility rules, the filing windows — cannot flag a problem before it becomes a missed filing or a disqualified day.
Ask in the demo: Which state programs does the system track? Show me how it handles the Washington 120-day cap and the one-year application window. What happens if a day is worked outside approved hours?
5. ADA-Compliant Confidentiality Architecture
Federal law requires that medical information be kept on separate forms, in a separate medical file, accessible only to personnel with a legitimate business need — this applies to electronic records, not just paper files. (29 CFR 1630.14(c)(1), JAN, 2025; EEOC Informal Discussion Letter, 2011.) Supervisors and managers are entitled to know the worker's restrictions and accommodations; they are not entitled to know the diagnosis. (EEOC via Gordon Feinblatt, 2024.)
A return-to-work software system that stores the restriction profile and the medical record in the same accessible record, or that sends a document to a supervisor containing diagnostic information, creates an ADA confidentiality exposure. The software architecture should enforce this separation by design, not by user discipline.
Ask in the demo: What does a supervisor receive? What fields are visible in a supervisor-facing document vs. an HR file? Where does the medical record live relative to the case record?
6. Audit Trail and Defensibility
A claim dispute, a carrier audit, or an OSHA inspection will ask you to show what happened, when, and who acted. A paper or spreadsheet process can be reconstructed, but the reconstruction is itself evidence of a weak control environment. Software should log every case action — restriction entry, document generation, provider approval receipt, day logged, application submitted — with a timestamp and a user record.
Ask in the demo: Show me the case history log. If I need to produce documentation showing exactly when a job description was sent to the provider, can I do that?
7. Carrier Independence and Program Portability
Your RTW program should survive a carrier change. If you switch carriers at renewal — or if your carrier non-renews you after a loss year — your modified-duty job library, your case history, your reimbursement records, and your transitional position documentation should remain yours. A tool that lives inside a carrier's platform does not guarantee that portability.
Ask in the demo: If we change carriers, what happens to our data? Can we export the full case history and job library? In what format?
A Side-by-Side Summary
| Criterion | Enterprise RMIS | Carrier-Bundled Tool | Spreadsheet + State Forms | Purpose-Built RTW Tool |
|---|---|---|---|---|
| Case state tracking | Yes (claims-centered) | Partial | None | Yes (RTW-centered) |
| Restriction-window logic | Embedded in claims module | Limited | None | Purpose-built |
| Duty matching | Varies by platform | Basic suggestions | Manual | Ranked, explainable |
| State program rule awareness | Rarely explicit | Varies by carrier | None | Core feature |
| ADA confidentiality architecture | Varies | Varies | User-dependent | By design |
| Audit trail | Yes | Partial | None | Yes |
| Carrier-independent portability | Yes (you own the data) | No | Yes (it's your spreadsheet) | Yes |
| Implementation timeline | Multi-quarter | Immediate (bundled) | Immediate | Days to weeks |
| Pricing structure | Custom enterprise contract | Free with policy | Free | Transparent subscription |
Competitor pricing is qualitative. Enterprise RMIS contracts are negotiated; carrier-bundled tools cost nothing separately; purpose-built RTW tool pricing is published — see our pricing page.
The Questions That Reveal the Most in a Demo
A structured demo session will tell you more than a feature matrix. Before you close any demo, walk through these scenarios:
- Open a new case with a real restriction profile from a recent claim. Count the clicks between injury date and a completed draft job description.
- Log a day worked outside approved hours. Does the system flag it as ineligible for state reimbursement, or does it just add it to the count?
- Change a restriction mid-case (the physician updates the lifting cap at the week-three visit). How does the system handle the case history? Does the old restriction record remain?
- Produce a supervisor notification. What does it contain? Does it include diagnostic language, or only restrictions and accommodations?
- Simulate a filing deadline. If today is 11 months and 15 days after the last light-duty day worked, does the system alert you that the Washington reimbursement window closes in 16 days?
- Export your job library and case history. In what format? How long does it take?
If a vendor cannot walk through all six scenarios in a single demo session with their own instance, that is diagnostic information.
What Return-to-Work Software Is Not
A clear-eyed evaluation requires understanding what no RTW software — including ours — does or should do:
- It does not adjudicate the claim or determine benefit eligibility. Those decisions belong to the carrier, the TPA, and the state agency.
- It does not replace the treating physician's judgment. The physician approves the transitional job description in writing; the software facilitates generating and routing that document, not approving it.
- It does not auto-assign workers to positions. Every placement decision is made by a person — the coordinator, in consultation with the supervisor and within the bounds of the physician's approval.
- It does not give physicians or injured workers a system login. Their participation happens through generated documents — job descriptions sent for approval, return-to-work status forms — not through a portal or application account.
- It does not provide legal, medical, or claims advice. Compliance questions about specific state programs, ADA obligations, or claim handling should be verified with the relevant authority: WA L&I, TX DWC, OR WCD, OH BWC, EEOC, or qualified legal counsel.
Understanding these limits is part of evaluating any tool honestly. A vendor who implies the software handles any of these functions is overpromising.
Before You Buy: Two Resources Worth Running First
If you are still building the internal case for RTW software — justifying the spend to a CFO or operations lead who wants to see numbers — two things will help.
First, the RTW case management guide gives you the process framework this software is designed to support. If your organization does not yet have a defined RTW process, software will automate a gap, not fill it.
Second, the RTW Program ROI & Budget Case Workbook at our store is a structured spreadsheet for quantifying the claim-cost, EMR, and reimbursement impact of a functioning RTW program using your own numbers. It does not require software to use; it exists to build the budget case before you buy anything.
If you are ready to evaluate Transitional Duty Manager directly, start with a trial — no multi-quarter implementation, no custom contract negotiation.
Making the Decision
Return-to-work software is not a binary buy-or-don't-buy decision. The real decision is which category of tool fits the scale and structure of your operation.
If you are self-insured with a dedicated risk department and hundreds of claims per year, an enterprise RMIS may be appropriate — though RTW workflow will remain one module among many.
If you are on a commercial policy with a carrier whose bundled tool meets your needs and you have no plans to change carriers, the bundled tool may be sufficient — with the understanding that your program history does not travel with you at renewal.
If you are managing five or more lost-time claims per year with a coordinator who also carries HR or safety responsibilities, you are in the use case purpose-built RTW software was designed for: enough volume that a spreadsheet breaks, not enough to justify enterprise infrastructure, and enough at stake in state program reimbursements and EMR exposure that a documented, auditable process has material financial consequences.
The criteria above will hold regardless of which vendor you evaluate. Run the demo scenarios. Ask about portability. Look at the supervisor-facing documents. Check whether state program filing windows are tracked automatically or manually. The answers will make the decision clear.
Get the next RTW guide in your inbox
Practical guides and WA Stay-at-Work updates — no spam.
Automate the full RTW workflow
Transitional Duty Manager replaces manual RTW documentation with O*NET duty matching, WA SAW reimbursement packet export, and an immutable audit trail.
See how it works

