Thrizer Support & Operational Rules
Last Updated: 2026-04-06 Status: CanonicalPurpose: Defines how to handle scenarios where Thrizer’s automated system cannot complete, resolve, or guarantee an outcome and human intervention, user action, or workaround workflows are required. Use this file when a query involves:
- a failure, limitation, or absence of system automation
- a manual process, workaround, or exception flow
- a question about who is responsible (client, clinician, or Thrizer support)
- a need to determine what happens next when a workflow breaks or stalls
- support involvement, escalation, or required documentation
- real-world handling of claims, payments, or insurance when system rules are insufficient
- deterministic system behavior (pricing, eligibility, reimbursement logic)
- definitions of insurance or product capabilities
- expected “happy path” workflows that the system handles automatically
Explicitly Defines
- When support action is required
- What information must be collected
- Who is responsible for resolution (client, clinician, Thrizer)
- What the system does NOT handle automatically
- Expected timelines (when known)
- Resolution pathways when workflows fail
Explicitly Does NOT Define
- Pricing logic → see Pricing Rules
- Reimbursement calculations → see Reimbursement Reasoning Rules
- Payment eligibility → see Payment Eligibility Rules
- Product capabilities → see Product System Map
- System constraints → see Product Constraints & Limitations
- Insurance definitions → see Insurance Definitions
Authority Position
- Non-authoritative relative to system rules
- Cannot override:
- Payment Model
- Pricing Rules
- Product Constraints
- Complements canonical documents with operational handling
Core Principle
If a scenario cannot be resolved through:- system automation
- deterministic rules
Operational Scenarios
Variable Practitioner Investigation
Actor: Support Trigger Condition:A practitioner type falls under variable or uncertain support categories (e.g., OT, PT, SLP, RD, medical specialists) System Behavior:
The system does not determine reimbursement or compatibility based on practitioner type alone Required User Action:
Provide additional service details, which may include:
- CPT code(s) used
- Service type or description
- Review provided CPT codes and service details
- Evaluate prior workflow compatibility or escalate internally if needed
- CPT codes do not guarantee reimbursement
- Reimbursement and claim acceptance are determined by the insurer
- Support provides guidance based on available information
- Or escalates for further investigation
Manual Insurance Verification
Actor: Client or Clinician Trigger Condition:Insurance plan cannot be found or linked in system System Behavior:
Automated benefit check fails or cannot proceed Required User Action:
Provide:
- front of insurance card
- back of insurance card
- date of birth
- manually verify out-of-network benefits
- link insurance plan to account
- dependent on insurer systems
- may require follow-up
Insurance plan becomes linked and usable Source Confidence: High
Benefit Calculator Usage Guidance
Actor: Clinician / Client Purpose:Provide a way to check and understand out-of-network benefits before initiating care or billing. Guidance:
- Use the benefit calculator for clients where the clinician is out-of-network with the client’s insurance
- The calculator can be used:
- by clinicians within the portal
- by clients via the embedded widget or external link
- The calculator is intended for use prior to intake, consultation, or session billing
- The benefit calculator returns estimated out-of-network benefit information
- Results are subject to insurer verification and are not guaranteed
- Use of the calculator is not required to create a charge or submit a claim
- Results do not guarantee coverage or reimbursement
Benefit Checker Failure Pattern
Actor: System Trigger Condition:Repeated benefit check failures for insurer or plan System Behavior:
Automated check does not return results Required User Action:
Provide insurance details Support Action:
Manual benefit verification Limitations:
Dependent on insurer system accessibility Resolution Outcome:
- benefits confirmed manually
- or inability to verify confirmed
Claim Status Inquiry
Actor: Client or Clinician Trigger Condition:User requests claim status System Behavior:
Claims remain in processing state Required User Action:
Wait standard processing window Support Action:
Review claim if contacted Limitations:
Typical processing time:
- 4–6 weeks
- claim processes normally
- or escalates if delayed
Failed or Stalled Claims
Actor: System / Support Trigger Condition:Claim fails or stops progressing System Behavior:
User notified of issue Required User Action:
Provide requested information Support Action:
- investigate with insurer
- request missing data
- resubmit or correct claim
Final outcome determined by insurer Resolution Outcome:
- claim corrected and processed
- or denied
Manual Claim Submission (Superbill Upload)
Actor: Client Trigger Condition:Client uploads superbill instead of using automated billing System Behavior:
Claim generated from uploaded document Required User Action:
Upload valid superbill including:
- provider name
- NPI
- TIN
- service dates
- billed amount
- diagnosis code
- CPT codes
Assist if parsing or submission fails Limitations:
- subject to insurer timely filing limits
- reimbursement not guaranteed
Claim submitted for insurer processing Source Confidence: High
Credit Card Failure Handling
Actor: Clinician Trigger Condition:Payment method is declined System Behavior:
Failure displayed in real time Required User Action:
Clinician must follow up with client Support Action:
None by default Limitations:
Thrizer does not collect payment on behalf of clinician Resolution Outcome:
Payment must be retried or updated Source Confidence: High
Payment Method Requirement and Responsibility
Actor: Client / Clinician Trigger Condition:A charge is created or attempted for a client System Behavior:
A valid payment method must be on file for a charge to succeed. Responsibility:
- Either the client or clinician may add a payment method
- The clinician is responsible for ensuring a valid payment method is present before initiating a charge
- If no valid payment method is on file:
- The charge fails
- No payment is collected
- No claim is submitted
- Add or update a valid payment method before retrying the charge
- None by default
- Thrizer does not collect payment on behalf of the clinician
- Payment success is required for claim submission
- Charge succeeds once a valid payment method is added
- Claim submission proceeds only after successful payment
Refund Responsibility
Actor: Clinician Trigger Condition:Client requests refund System Behavior:
Thrizer does not initiate refunds Required User Action:
Client contacts clinician Support Action:
None Limitations:
Thrizer functions as payment processor only Resolution Outcome:
Refund issued by clinician Source Confidence: High
Payment Method Update Limitation
Actor: Client Trigger Condition:Client attempts to change payment method after charge System Behavior:
Retroactive changes not supported Required User Action:
Use updated method for future payments Support Action:
None Limitations:
Past transactions cannot be modified Resolution Outcome:
New method applies to future charges only Source Confidence: High
Split Payment Workaround (Manual)
Actor: Client / Support Trigger Condition:Client requests split payment across methods System Behavior:
System does not support split payment Required User Action:
Process separate self-pay charges Support Action:
Manually submit combined claim if requested Limitations:
- may cause claim issues
- not system-supported workflow
Claim may be submitted manually Source Confidence: Medium
Multiple Services in One Session
Actor: Clinician Trigger Condition:Session includes multiple CPT services System Behavior:
System requires separate charges Required User Action:
Submit each CPT as separate charge Support Action:
None Limitations:
Single CPT per claim enforced Resolution Outcome:
Multiple claims submitted Source Confidence: High
No-Show / Cancellation Fees
Actor: Clinician Trigger Condition:Missed or cancelled session System Behavior:
No claim submission Required User Action:
Charge client directly Support Action:
None Limitations:
Insurance not involved Resolution Outcome:
Self-pay transaction only Source Confidence: High
Backdated Claim Submission
Actor: Client Trigger Condition: Client submits claims for past services (service date in the past) System Behavior: Thrizer allows submission of claims for any service date. Required User Action: Upload valid superbills or enter claim details. Support Action: Assist if submission or processing fails. Limitations:- Claim acceptance is determined by insurer timely filing limits
- Thrizer does not enforce a submission time cutoff
- Reimbursement is not guaranteed
- Claim is processed if accepted by insurer
- Claim is denied if outside insurer filing limits
Diagnosis Code Missing
Actor: Clinician Trigger Condition:No diagnosis available at time of session System Behavior:
Charge can be delayed Required User Action:
Wait until diagnosis is assigned Support Action:
None Limitations:
Claims require diagnosis Resolution Outcome:
Charge submitted after diagnosis added Source Confidence: High
Account Email Change Limitation
Actor: Client or Clinician Trigger Condition:User attempts to change email System Behavior:
Email cannot be modified Required User Action:
- create new account
- or add new email as team member
May delete account upon request Limitations:
Accounts are email-bound Resolution Outcome:
New account required for new email Source Confidence: High
Account Deletion Request
Actor: Support Trigger Condition:User requests account deletion System Behavior:
No self-service deletion Required User Action:
Email support Support Action:
Delete account Limitations:
Historical access may be lost Resolution Outcome:
Account removed Source Confidence: High
Reimbursement Withdrawal
Actor: Client Trigger Condition:Client has balance in Thrizer System Behavior:
Funds held until bank linked Required User Action:
Add bank account Support Action:
Trigger transfer Limitations:
Transfer timing: Balance is paid every Tuesday and Thursday morning. Resolution Outcome:
Funds deposited Source Confidence: High
Claim Documentation Access
Actor: Client or Clinician Trigger Condition:User requests transaction or claim history System Behavior:
Export available Required User Action:
Download CSV Support Action:
None Limitations:
Export reflects system data only Resolution Outcome:
User obtains report Source Confidence: High
Support Channel Limitation
Actor: Client or Clinician Trigger Condition:User requests phone support System Behavior:
Phone support unavailable Required User Action:
Use email Support Action:
Respond via email Limitations:
No phone support Resolution Outcome:
Issue handled asynchronously Source Confidence: High
Support Response Time
Actor: Client / Clinician Trigger Condition:User submits a human support request via email System Behavior:
Support responses are provided via email. Response Expectation:
- Initial response is provided within 2 business days
- Applies to first response only
- Resolution time may vary depending on issue complexity
- Response times are not guaranteed
- Timing may vary based on support volume and external dependencies
- User receives an initial response within the expected timeframe
- Follow-up may be required for full resolution
Marketing and Logo Usage
- Clinicians may share referral links and mention Thrizer
- For use of logos or branded assets, users should contact support for guidance
Claim Resubmission After Insurance Change
Actor: Support Trigger Condition:Client updates insurance after claim System Behavior:
No automatic resubmission Required User Action:
Provide updated information Support Action:
Manual handling of resubmission Limitations:
Dependent on claim state Resolution Outcome:
Claim may be reprocessed Source Confidence: Medium
Charge Success and Claim Submission Dependency
Charge Success Rule
- A Charge succeeds only if the client’s payment method is successfully charged
- If the client’s card cannot be charged:
- The Charge fails
Claim Submission Dependency
- Claim submission depends on a successful Charge
-
If Charge succeeds:
- Client payment is captured
- Claim is submitted automatically
-
If Charge fails:
- No payment is captured
- Claim is not submitted
Constraint
- The system must not submit a claim if the Charge fails
- Payment success is a prerequisite for claim submission
Charge Failure Handling
Immediate Failure Behavior
- If the client’s payment method cannot be successfully charged:
- The Charge fails immediately
- No payment is captured
- The claim is not submitted
System Behavior
- The system does not queue or retry claim submission if the Charge fails
- There is no partial workflow:
- claim submission requires successful payment
Clinician Action Required
-
The clinician must:
- resolve the payment issue with the client
- update or retry the Charge
-
A new Charge attempt is required to:
- successfully collect payment
- trigger claim submission
Constraint
- The system must not:
- submit claims without successful payment
- retry failed Charges automatically
FSA / HSA Documentation for Thrizer Payments
Actor: Client Trigger Condition:Client requests a receipt, superbill, or documentation to submit for FSA or HSA reimbursement for sessions processed through Thrizer System Behavior:
- Thrizer records all payment transactions in the Client Portal
- Clients can export a complete record of payments
- Navigate to: Client Portal → Payments → Export
- Download the payment record
- Direct the client to the Payments export feature
- Clarify that this export is the standard payment record available in Thrizer
- Thrizer does not generate a separate document specifically for FSA/HSA submission
- Superbills are used in manual claim workflows, where the client submits a claim independently rather than using Thrizer’s automatic claim submission
- Client obtains a downloadable payment record for use in reimbursement submission (e.g., FSA/HSA)
Support Channel Limitation
Communication Channels
- Human-based Thrizer support is provided via aynchronous channels such as email.
- Phone support is not offered.
- Email-based support
- In-product support requests (Help → Request Help)
- All support interactions must be routed through supported channels.
- Do not direct users to unsupported communication methods.
Variable Practitioner CPT Validation Workflow
Actor: Support Trigger Condition:A practitioner type falls under variable or conditional support categories (e.g., OT, PT, SLP, RD, medical specialists), and compatibility is unclear. System Behavior:
Thrizer does not automatically determine compatibility for variable practitioner types based on practitioner classification alone. Required User Action:
Provide:
- CPT code(s) used
- Service description (if needed)
- Check whether the provided CPT code(s) have been previously observed in Thrizer workflows.
- If CPT code(s) are present in prior workflows:
- Treat as supported for submission workflows
- If CPT code(s) are not found:
- Conduct internal review and compatibility assessment
- Determine whether Thrizer can support claim submission for those services
-
If supported:
- CPT code(s) may be used in Thrizer workflows
- Thrizer is considered capable of submitting claims for these services
-
If not supported:
- Thrizer workflows should not be used for those services
- If a CPT code is:
- previously observed, OR
- approved through internal review
- reimbursement may be considered likely in typical scenarios
- Reimbursement is not guaranteed
- Final claim outcomes are determined by the insurer
- CPT validation confirms Thrizer workflow compatibility, not coverage or payment
- Presence in historical workflows does not guarantee reimbursement
- Absence from historical workflows does not imply unsupported status without review
Clinician Address Usage Guidance
Actor: Clinician Trigger Condition:Clinician asks whether to use their own address or Thrizer’s address for documentation or tax purposes System Behavior:
Thrizer collects and stores the clinician’s business address for compliance and tax reporting purposes Guidance:
-
Clinicians should use their own business address for:
- tax documentation
- superbills
- insurance-related documentation
- If a clinician explicitly requests Thrizer’s address for a specific use case, the following address may be provided: 548 MARKET ST, PMB 82051, SAN FRANCISCO, CA, 94104
- This address is not the default or recommended address for clinician documentation
- Use of this address may not be accepted by insurers or other entities
- Clinician uses their own address in standard cases
- Thrizer address is used only when explicitly requested