Out of the ashes of SuperPay rose SuperDial, the next big pivot for SuperBill. While filing out-of-network claims for patients in SuperPay, we needed to call a patient’s insurance company to verify their benefits. This took over 30 minutes per call (working through the insurance company’s automated IVR system, waiting on hold, etc.), and we desperately needed to streamline this process to remain profitable.

With recent developments in AI, we made our own “robodialer” that would call insurance companies on our behalf. This worked quite marvelously for us, and we quickly realized that practices, billers and RCM companies alike all needed the same thing, just different “scripts”. Thus began the SuperDial journey.
My role
I was the sole designer at this 8-person company and designed every feature in the app / page on the marketing site. I also did a good deal of full-stack development, from implementing 2-factor authentication to handling most of the front-end UI work. I lightly PM-ed the portal features by developing product roadmaps, and performed the bulk of QA testing before we deployed to customers. Typical startup role!

Script Builder
Customers can configure custom “scripts”, which tell us what questions they’d like us to ask. V1 was a simple google form-esque builder. After user feedback, our script builder evolved to allow question nesting (“if the answer is X, ask this. If Y, ask this instead”), references to inputs (similar to code snippets → if I want to reference the patient’s name, I can say {patientName}), and a support tab.

Challenges: Not designing ourselves into a box - there are so many ways you can “tell us what answers you want”. We didn’t want to create something too complicated and make script creation a thing we’d have to explain to users. But script creation also needed to be flexible enough to win over companies with very thorough requirements.

Placing Calls
We started out saying, “to place calls, upload a CSV with required inputs” (inputs being stuff like patient name, date of birth, etc. – all the info we’d need to get the right answers). We soon found that we’d need to allow quite a few different ways for users to place calls based on various use cases: CSV upload, manually enter on our portal, API, practice management software (PMS) integration.

Challenges: Creating a good user experience for all ways of placing calls without overwhelming the dev team with complexity (more ways to place calls = more things to maintain = more potential bugs).

Viewing Results
After our AI completes a batch of calls, we display the results in a table and let users download a CSV file of the successful and/or failed calls. Of course, as needs developed, the results page became more and more robust - a full-out detailed results view for practices who’ve linked their PMS, rolled up stats, etc.

Settings / Dev page
A catch-all page to hold all the settings and developer tools. Manage your team accounts, test out the API, and view your call settings.

Marketing page
I’m quite happy with our marketing page - I designed and built the site in Webflow, and wanted it to look techy and trustworthy (and not too "trendy"). SuperBill should feel legit and professional, and not like a startup of 8 people haha. I chose a style that had the color pop + animations of tech startups, but read a little more straightforward / corporate.
Check out the website

Lessons learned

Building a single platform for multiple use cases
We had one platform that would both let large RCM biller companies place batches of 1,000’s of provider inquiry calls at a time, and also let a dentist office automatically verify a patient’s benefits three days before their appointment. I learned how to create a tailored experience for each of our 3 main use cases without overwhelming our code base with “if” statements, and that mostly meant mapping out user journeys and a LOT of interviews.

Handling customer-facing interactions
For awhile, we were building features so quickly to win deals that sometimes we'd unknowingly break things in the process. When customers got upset (and sometimes threatened to cancel their contracts), I learned how to communicate (transparently and frequently) to keep them with us. This was pretty big for me since my prior UX roles weren’t customer-facing.

I also triaged customer feedback and requests. I prioritized them based on our roadmap, and oftentimes I ended up being the one implementing features since our developers were mostly focused on AI machine-learning work.

Growing my full-stack skills
During lighter design periods, I'd put on my dev hat to keep us moving forward! I already knew how to build components in React with front-end calls to the database, but given the complexity and higher security needs of the app, I had to learn how to properly write (python) back-end code.

Developing a style
My previous company had a very defined style guide, so developing an implementable style from scratch was new for me! I had a lot of fun coming up with our design style, and then created reusable components using TailwindCSS to make implementation even faster.