Designed correctly, E-Bills are a great use for the web, allowing insurance companies to communicate critical financial and census data to their customers in a controlled fashion while increasing efficiency and accuracy for the customer and themselves.
Unfortunately, it has been my experience that there’s a lot of misleading information about E-Billing “products” and “systems” on the Internet. In my upcoming posts, I’m going to wade through this morass of information and detail the approach that works – both from the company and customer standpoint.
The bill I’m speaking of is for group insurance. In the paper world, it’s that complicated, multi-page, already incorrect when it’s mailed, document that details what the insurance company believes the customer owes them. In the group insurance world (especially worksite marketing), where products may be voluntary and usually involve payroll deductions, I contend the bill is always wrong when received by customer due to the nature of the beast. By the time the bill arrives, the customer has employees who have joined the company, left the company, added dependents, etc. The poor customer then moves to try to reconcile said manual bill at a “point in time” that has nothing to do with the insurance company’s computer system used to generate the bill. The customer remits the reconciled (from their standpoint) bill, and it starts all over at the company end. There, it’s a reverse reconciliation as the company tries to figure out the entries the customer made on their end. It’s not unusual to see bills arrive at an insurance company with lines marked out, additions written in the margins, incorrect calculations, etc. How can it be right? The customer doesn’t know the insurance company’s business rules.
A statement about E-Billing products – based on the complexity of insurance billing systems (especially legacy systems), the inherent dynamic nature of the customer’s census and the integration needed to design posting for a true E-Billing System (Presentment, Reconciliation and Payment) back to the billing system after a bill is finalized, products haven’t met the mark. I have yet to see a product that meets the needs of an insurance company requiring true branding, specific process flow, true self-service automation, and SOA compliant integration.
Contributing to this state of confusion, I’ve seen three completely different levels of E-Billing as requested by clients. All are referred to as E-Billing and in many cases, in previous engagements, the client visualized more and received a lot less.
Stay tuned for a discussion of (1) E-Bill Presentment, (2) E-Bill Presentment and Payment and (3) E-Bill Presentment, Reconciliation and Payment (true E-Billing).
Image appears courtesy of graphicalwonder.com