01 · We launched. Then growth stalled.

Bill Pay was Square's answer to the other side of invoices: helping sellers organize and pay their business bills using Square Checking or any card.

I worked with my team to launch the product, but early adoption quickly plateaued.

We were seeing:

• 2K monthly active users
• 24% conversion
• 54% drop-off at Add a Vendor

I had four weeks to understand what was holding the product back and identify an opportunity to improve conversion.

My question wasn't “what should we redesign?”

It was: where is the experience breaking down, and why?

02 · The funnel told me where to look

I mapped the activation funnel and found one clear outlier: Add a Vendor.

More than half of sellers dropped off during vendor creation.

Meanwhile, the rest of the payment journey, entering payment details, confirmation, and scheduling, was performing as expected.

Session replay helped me understand the behavior, but it didn't explain the hesitation.

So I went to sellers.

03 · The problem wasn't the form. It was the work.

When I talked to sellers, a pattern emerged.

Bills were already arriving in their inboxes. To pay one through Bill Pay, they had to:

Find the bill → open Bill Pay → create the vendor → enter the information → continue paying

For sellers, vendor creation felt like administrative overhead.

They didn't want a better way to create vendors.

They wanted to skip creating vendors altogether.

That reframed the opportunity for me:

How might we remove vendor setup from the payment experience rather than optimize it?

This became the design principle for the next iteration.

04 · I explored how far we could automate the setup

I explored several approaches to removing vendor setup.

One idea was letting sellers search for a biller and connect it to Bill Pay. It reduced some effort, but still required sellers to leave the context where their bills already lived.

The stronger opportunity was to bring the bill into Bill Pay and let Square do the setup.

I proposed a two-phase approach:

• 01 · OCR — Automate vendor creation from bills sellers already have.
• 02 · Email forwarding — Extend that automation to bills arriving directly in their inbox.

This gave us a way to validate the behavior incrementally instead of making one large feature bet.

05 · V2: Make the bill do the work

The experience:

Scan → Read → Pre-fill → Create vendor → Review

OCR extracted the vendor and bill details and automatically created the vendor record.

But I didn't want automation to become a black box.

When the system couldn't confidently read something, I designed an exception path that surfaced the missing information and asked the seller to provide only what was needed.

Automate aggressively. Ask for help only when necessary.

06 · V3: Meet sellers where their bills already are

OCR solved the problem for physical bills. But many sellers received their bills through email.

So I extended the same mental model into their inbox.

Email forwarding

Sellers could forward a bill to a dedicated Square email address.

Receive → Forward → Extract → Review → Schedule

The bill appeared directly in the Bill Pay queue as a draft payment.

From there, sellers could review the extracted information and schedule the payment.

I intentionally kept the UI lightweight. The goal wasn't to create another complicated workflow. It was to remove workflow altogether wherever we could.

07 · Designing for when automation fails

Automation only works if sellers trust it.

So I designed the experience around the failure cases, not just the happy path.

What happens if...

• The bill format isn't compatible? Notify the seller so nothing silently fails.
• The OCR can't read a required field? Ask only for the missing information.
• The seller forwards to the wrong address? Provide clear feedback so they know what happened.
• The bill can't be processed? Keep the seller informed rather than leaving the payment in an ambiguous state.

Make automation feel effortless, but never make it feel invisible.

08 · Each iteration moved the same funnel

Rather than waiting for one large redesign to ship, we measured each iteration against the same activation funnel.

Baseline → V2 → V3

Each release built on what we learned:

Baseline → OCR → Email forwarding

The result wasn't one big feature that magically fixed Bill Pay.

It was a series of focused, measurable interventions that progressively removed friction from the same core problem.

09 · The bigger lesson

This project reinforced something I now look for in every product: don't just optimize the workflow. Question the workflow.

Our initial instinct could have been to make vendor creation faster, clearer, or easier.

But the research showed that the bigger opportunity was to eliminate the work entirely.

That led us from:

“How do we make vendor creation better?”

to:

“How do we make vendor creation unnecessary?”

That shift helped turn a post-launch plateau into measurable product growth, and gave us a repeatable way to continue improving the product after launch.