November 18, 2013 •Brian Watson
One month in, it's safe to say that the launch of the government’s online insurance website, HealthCare.gov, hasn’t gone as smoothly as anticipated.
Officials expected over 500,000 consumers to enroll in private health insurance plans through the website in October. But despite nearly 20 million visitors, only 50,000 consumers used HealthCare.gov to buy a health plan.
Missing the mark on enrollment to that degree is cause for concern. But it’s simply a symptom of a larger problem.
Design flaws and larger-than-anticipated crowds have led to site timeouts, error messages, and log-in difficulties – problems that have frustrated users and slowed enrollment.
For example, of consumers who met federal exchange eligibility requirements and submitted an application, only 3.8% have actually purchased a health plan. Compare that against the 20.9% purchased by eligible consumers through a state-run exchange.
That discrepancy can largely be traced back to HealthCare.gov's website issues.
You Never Get a Second Chance to Make a First Impression
Sure, that’s a shopworn adage. But when it comes to launching a new web service, it’s also spot-on.
Attitudes and behaviors can be difficult to change. Not to sound dire, but in many instances, your new portal will only get one chance to connect with customers. Your new app may only have one shot to be sticky enough to resonate.
Take the launch of a new online billing and payment portal, for example. Getting customers to adopt EBPP is no picnic. It takes marketing, outreach, and in some cases, valuable incentives before they even try paperless billing or web payment. Much less make the leap to full-fledged convert.
And, in most cases, success or failure hinges on site usability. How easy is it for customers to enroll? To log on? Or find their statement and make a payment?
Exceed expectations and you stand to gain customer loyalty and strong word of mouth buzz. Not to mention faster payment, lower collection costs, and less bad debt.
Miss the mark and customers simply aren’t likely to come back. If it takes too much time to access, or crashes incessantly, or looks like a security risk, that’s a signal to customers that isn’t worth their time or trouble.
So don’t leave things to chance. There are plenty of lessons that can be learned from HealthCare.gov’s rocky start. Make sure your online billing and payment portal is thoroughly tested and ready to launch by following this simple checklist.
Plan Your Work, Work Your Plan
HealthCare.gov developers were informed two weeks before site launch that users wouldn’t be able to shop health plans anonymously. Instead, they’d be required to register for an account in order to access the insurance marketplace. That crunch-time decision put more stress on the system than it could handle and caused already tight development resources to be squeezed even further.
The Takeaway: Getting an EBPP portal up and running is a massive project. It pulls from multiple groups inside your company (finance, IT, marketing, and compliance). And generally involves an outside developer, too.
With so many cooks in the kitchen, it’s essential that everyone is working from the same script.
Creating a detailed strategic plan – that includes an implementation timeline and what tasks and responsibilities are expected of each department involved in site roll-out – helps prevent communications breakdowns and last-minute updates from grinding the engineering process to a halt.
Take Your Time
An initial end-to-end test of HealthCare.gov two weeks before the October 1 rollout was marred by site slowdowns and crashes. But with a well-publicized deadline looming, pushing back the launch date would have been costly and difficult.
The Takeaway: Give yourself more than enough time to finish – and thoroughly test – your online billing and payment website prior to launch. Rushing to fit a pre-scheduled deadline without completing the right amount of due diligence will only lead to problems – either during launch or further down the road.
Better yet, anticipate that there might be setbacks and minor issues to troubleshoot by building extra time into your implementation schedule.
Sweat the Details
More than just a website, HealthCare.gov is an end-to-end insurance network that involves communication between consumers, government health agencies, and insurers.
Unfortunately, that complexity is part of the problem. Integration of all the tools needed to seamlessly apply for and purchase health coverage hasn’t gone as smoothly as anticipated. Some consumers have received inaccurate eligibility information. And insurers have reported receiving health plan applications with mistaken patient demographic data.
The Takeaway: Online billing and payment portals are similar to the federal insurance marketplace in that they’re a lot more complicated than simple websites.
EBPP portals collect and transfer billing, payment, and account information between multiple groups – your organization, its customers, and their financial institutions.
Because it’s a complex arrangement that also so happens to involve debits and credits, there’s no room for errors of omission. Before a single line of code is written, make sure there’s a project charter that explicitly spells out key details, like:
• Website design, copy, and navigation.
• Payment, funding, and customer account rules.
• Customer notification methods.
• ACH and credit card processing networks and settlement rules.
• How customer financial data will be ported between your legacy system and EBPP website.
• Will you offer customers additional payment options that integrate with EBPP, like mobile and IVR?
Test, Re-Test, Then Test Some More
Although developers carried out successful usability tests for individual parts of the HealthCare.gov website, only one unsuccessful end-to-end test was completed for the entire application. And it took place just two weeks before the October 1 site launch – preventing coders from having the time they needed to fix problems.
The Takeaway: Testing isn’t a one-time activity. It’s a process. Your EBPP portal isn’t ready to launch unless you’re as near 100% certain as possible that it works reliably. And can take the burden of heavy user traffic.
Achieving that peace-of-mind means that external developers, internal staff, and even your customers should be spending a lot of time in and around the application prior to launch.
Staff Testing
Don’t leave internal stakeholders in the dark about how your EBPP is progressing until just prior to launch. Loop them in early with an internal-only testing phase.
Most developers provide a testing environment called a sandbox for employees to experiment with prior to launch. The idea is to have your staff interact with the application. To enroll as a user, to complete payments, to view bills, to send support requests. All the things your customers typically do during an average day – with an eye towards uncovering website branding, navigation, and usability issues.
User Testing
Once your internal team is satisfied, test some more. The initial round is valuable from a functionality and usability standpoint. It helps uncover pressing design and navigation issues that need to be addressed by your developer. Plus small bugs that should be fixed prior to launch – broken links, faulty forms, incorrectly loading pages.
But what do your customers think? They’re the ones using it to view statements and make payments, after all. Invite a group of them in as beta-users to get a feel for what they really want and how they interact with the site. Then incorporate their feedback into the finished version of your portal.
Tests groups don’t have to be especially large. Web usability gurus Jacob Nielson recommends small groups – between five and ten users – that participate in several test runs.
Developer Testing
Most of the heavy-lifting during testing should be left to qualified experts – either your internal IT staff for in-house builds or external developers for outsourced projects.
Not surprisingly, this process can get pretty complex. But suffice it to say, best-class developers should be able to provide you with documentation of their testing process and results, including areas like:
• Unit testing to check that forms, links, and menus work appropriately.
• HTML verification and load-time checks to make sure your portal is accessible for users regardless of web browser.
• Testing site security to make sure everything from data transmission through user authentication is compliant with best-class standards.
• Verifying site statement presentment and balance payment functionality with an actual test file from your legacy software application.
Have a website launch or online app horror story? Share it in the comments section!
