This guide is meant to show you the general steps required to setup an Inbound IVR (Interactive Voice Response) Autopay by Phone system for your organization. Your actual steps may vary depending on your particular Practice Management system and it's capabilities.
What is an Inbound IVR System?
- Allows your patients to call in 24 / 7 to check their balances owed and pay their balances either with a credit card or e-Check without ever talking to your staff members.
- Connect it directly to an option on your main phone number "Press 1 to use our Secure Automated Account System where you can check your balance or pay your balance."
- Frees up your staff from spending valuable time giving out a patient balance owed, manually keying in a credit card payment (or e-Check payment) by phone.
- Allows money to flow directly into your bank account from each payment (just like any other CC or e-Check payment).
- Posting files flow directly from the Payment Processor (just as with any other front or back-office payment).
- Enhanced details of each patient payment are available because of your IVR Validation Data Feed file (see below)
Questions about this or would like more information? Please call us at 1-800-939-1853 or email us at firstname.lastname@example.org.
Specific steps may vary based on your requirements.
Certain steps can and should be done in parallel.
STEP 1: Back-End Payment Processing Setup
1-1. Sign up with one of our approved payment processing firms. Please call us at 1-800-939-1853 or email us at email@example.com to ask us for our list of approved payment processing firms.
1-2. Request that your payment processor setup an IVR Payment Channel for your organization, or for each of your clients (if you are a medical billing firm). This step is optional, but can be helpful as it would keep all your IVR phone payments separate from your other payment channels so you can easily separate payments by payment channel.
You'll need to supply to 1-800 Notify the following for each IVR Payment Channel setup:
- Merchant ID
- Store ID
- Terminal ID
1-3. Request credentials from your Payment Processor so our IVR Phone system can access the API of the payment process to complete the payment transactions (Credit Card or ACH/E-Check) for you or your clients.
Together with the Merchant, Store and Terminal ID, these credentials are required to perform the real-time payments when the patient is on the phone.
STEP 2: IVR Validation Data Feed Setup
NOTE: With some practice management systems, we are able to access your system in real-time. Such real-time access would eliminate the need to send us the daily data feed.
For most systems, in order to validate which patient account is going to be paid, the amount that is owed, we need your organization to setup an IVR Validation Data Feed file that is automatically sent to 1-800 Notify's servers.
Suggested Minimum Fields to Use for Validation and Payment:
- Patient or Guarantor Name
- Account number (must be unique)
- Billing Zip Code
- Total amount owed
- Provider or Organization code for this account (only if you are a billing company with multiple clients)
Optional fields, can further adjust call flow:
- Primary phone number (used for initial identification)
- Date of Birth for Patient or Guarantor (whichever is supplied)
- Is account delinquent (If yes, then may not allow partial payment in call flow)
- Age of debt (if you want to use to adjust partial payment logic in call flow)
- Is account on a payment plan (If yes, then adjust amount due to minimum payment plan amt.)
- Payment plan minimum amount due (Used to adjust amount due if on Payment Plan)
- Any other fields
If you are a Billing firm, then we also need (for initial setup and whenever this changes):
- Client Provider/Organization Code for all organizations for which you provide services.
- Client Provider/Organization Name (as to be said in the system to patients)
- Does this Provider or Organization Accept Credit Cards?
- Does this Provider or Organization Accept ACH e-Checks?
- Merchant, Store and Terminal ID to be used for each client to process Credit Card payments
- (if different from credit card info) Merchant, Store and Terminal ID for ACH e-Check processing
2-1. File format: We can accept a number of different file formats including:
- We need to agree on the call flow you'd like to have and how you would like to validate your callers in your IVR system.
- Many times, the file you currently send for patient statement processing (assuming it has all required data fields for validation - billing zip code, account number, amount owed)
- Other fields we can use for optional identification and validation are: phone number (so we can identify by caller id/phone number entered, 4 digit birth year, and other fields we discuss).
- Other formats, mutually agreed upon.
2-2. File Transmission method and frequency – SFTP Batch file, usually nightly. We can explore other file transport methods and frequencies, such as direct pulling of data using your software vendors API, upon request.
2-3. First Transmission - Complete File: The first time you send data to us, the data transfer file should contain a complete set of all patients who have outstanding balances due.
2-4. Subsequent Transmissions - Only Updates: Subsequent data transfer should include only updated information since the previous data transfer. (E.g. new patients with new balances, existing patients with reduced/increased balances, patient demographic changes, etc.).
2-5. Daily Alerts of Data File Successful Processing. (optional) You supply a list of email addresses to receive the daily update alerts that this file was processed successfully.
The email alert shows the daily totals processed during the IVR Validation Data file processing.
Example: Total records in the validation database before processing, Additions processed, Edits processed, Total records after processing.
STEP 3: Real Time Call Results Viewing
The payments and posting files happen automatically through the Payment Processor. The actual logging of inbound calls and the final outcome of each call are tracked on 1-800 Notify's secure web portal.
The results can be helpful if your staff would like to follow up with patients who attempted but were not able to successfully complete a payment.
Sample results of calls are typically:
- Person answered = Caller called in but did not attempt to identify or authenticate themselves.
- Person identified = Caller performed basic identification using their phone number / Caller ID / account number, but was not authenticate.
- Person authenticated = Caller was identified and then authenticated as a valid patient (usually by entering their 4-digit birth year), heard their balance due and hung up.
- Autopay attempted = Caller was authenticated and tried to make a payment, but the payment was not completed (maybe did not enter a valid credit card, expiration date or e-Check).
- Autopay general failure = The person verified themselves, heard the amount owed, entered all their CC info, but the payment failed for some reason like expired card, insufficient credit, etc.
- Autopay success = Caller successfully was authenticated and made a payment. The amount of the payment completed is logged in the system.
Other data in the Call Results File:
- The patient name, phone number, account number, date, time and duration of the call and other information are also logged in the system.
3-1. Determine if the call results file is something that your staff would like to see only on the secure web portal, inside your own financial system, or not at all.
3-2. If your staff will be using the secure web portal, identify and train your personnel.
3-3. If you need the data to be re-imported into your financial system then determine the following:
3-3-1. File format you require for import.
3-3-2. Transmission method (usually SFTP file-drop).
3-3-3. Design and develop your Call Results import program.
STEP 4: IVR Call Flow Setup
This is the heart of the system: determining how you would like your callers to flow through the autopay by phone system.
4-1. Work to determine your organization's answers to these key decisions:
- Language - English only vs. English and Spanish
- Allow patient to pay less than the full balance owed? Yes / No
- Have a minimum payment amount? Yes - How much $____ / No.
- Do you have a business rule that only allows payment in full in certain situations? (Example: a patient is delinquent on their account).
- Do you have a payment plan in place with a patient? If yes, then should that payment plan amount become the minimum payment?
- Will you accept e-Checks in addition to Credit Cards?
- Do you want to allow an option for the caller to transfer to your call center staff? If yes, are there certain rules that govern this option (e.g. Only during working hours, only for certain minimum balances, etc.)
4-2. 1-800 Notify will develop the call flow document based on the above answers.
4-3. Your staff will review, edit and approve the call flow document.
4-4. 1-800 Notify staff will develop and test the initial IVR Call flow based on the approved document.
4-5. Your staff will have access to review and test the call flow.
4-6. Revisions to the IVR Call Flow based on your staff input and testing.
STEP 5: Acquire and Setup Your Dedicated IVR Toll Free Number
5-1. 1-800 Notify will purchase a dedicated toll-free number solely for your organization's use. This number will typically be an 888, 877, 866 or similar toll-free number.
5-2. We will then connect this phone number to your IVR Autopay by Phone system. This phone number will be accessible directly by any patient or could be transferred to by your staff or your organization's main call menu.
5-3. (optional) If you determine that you would like to publish your new toll free number on your statements, web site or elsewhere, then complete these separate projects. The other option is not to publicize this number, but instead transfer callers from your existing phone call menu to this number or have your staff transfer patients to it.
STEP 6: Incorporation into your Existing Call Menu System as a Transfer
This step is optional, but can be instrumental in helping to siphon off any patient who calls your main call center phone number looking to either check their balance or pay their balance using the automated system.
6-1. New Menu Item to Transfer. Your staff sets up a new option on your main phone menu system with language similar to this: "Press 1 to use our Secure Automated Account System where you can check your balance or pay your balance."
This new option will allow patients to self-transfer to your new Inbound Autopay by Phone IVR system.
6-2. Live Transfer By Your Call Center Staff. If your staff receives a call from a patient who wants to pay their bill, then the staff should work to push the patient to use the autopay by phone system. The method must be developed and setup by which your Call Center staff can initiate and complete the transfer of the patient to the Autopay by phone system.
STEP 7: Testing and Final Go-Live
7-1. Once all other steps are complete, then run some test transactions to validate all areas of the system are working as expected.
Sample testing scenarios might include:
- Add a new charge in your practice management system to a patient account.
- Verify that the new charge added is reflected the next day (or real time) in the IVR system.
- Make a test payment in the IVR system on a patient account.
- Verify that the test payment shows up correctly after posting in your system after posting is completed - ususally the next business day (unless you have real-time posting).
- Test to ensure that caller idenifification and authentication methods are working with your live data.
- Test Balance said in the system, are they accurate?
- Pay a full balance owed.
- Pay a partial balance owed.
- Try paying less than the minimum balance - are you prevented?
- Test transfer to your call center (if part of your system).
- Test everything in Spanish (if part of your system).
7-2. Once all testing is complete, then schedule and enable your new Inbound IVR Autopay By Phone system in your environment.
Remember, the above is simply a guide and your actual implementation might be quite different depending on your specific requirements and goals.