Hardi Jain · AI and SaaS product manager

ENTERPRISE · STORY 06

How do you give an external agent enough access to sell, without giving them access to the business?

Enterprise payment links · access governance · role-based access

The business needed distribution. The platform needed control.

01 · THE CONTEXT

Payment links were moving beyond the enterprise.

Payment Links allowed merchants to collect payments without requiring a technical integration.

For an enterprise such as an insurance company, the person creating the link wasn’t always an employee. There were two very different users.

02 · THE PROBLEM

The existing permission model was too broad.

An external agent needed one capability: create a Payment Link for a customer.

Too little access and the agent cannot work. Too much and enterprise data is exposed. That tension is the story.

03 · THE WORKAROUND

So the enterprise became the middleman.

When merchants couldn’t safely give access to external agents, the request travelled through internal teams instead.

What looked like a support problem was actually a product problem.

04 · DISCOVERY

I started with the support queue.

Rather than treating tickets as isolated operational issues, I grouped the requests, found the repeating patterns and traced them back to product gaps.

The missing capability wasn’t another support workflow. It was a permission primitive designed around the Payment Link job to be done.

05 · THE PRODUCT QUESTION

What is the smallest surface area an external agent actually needs?

The useful question was not which permissions this user should have.

It was what an agent needs in order to create and manage their own Payment Links, and nothing beyond that.

06 · THE DECISION

From broad access to scoped capability.

Don’t give users access to a product. Give them access to the capability they need.

07 · CAPABILITY ISOLATION

A deliberately narrow workspace.

The agent gets a workspace built around one job, not a filtered version of the merchant dashboard.

That is capability isolation, not simply role-based access.

08 · DATA ISOLATION

The agent sees their work. The enterprise sees everything.

Two levels of visibility. The agent asks to see what they created; the enterprise asks to see everything the organization created.

09 · SECURITY BY DESIGN

Restricting navigation wasn’t enough.

Hiding a menu item does not protect a record. Access had to hold at the interface, at the data and at export.

10 · EXECUTION

Turning a permission problem into a product system.

I converted recurring support issues into a product problem, defined what an external agent needed to accomplish, and specified what they could see, create, view and export.

The balance to hold was merchant productivity against enterprise data protection.

11 · THE TRANSFORMATION

Manual delegation became controlled self-service.

The agent stopped routing through the organization to do their job, and the enterprise gained a view of everything the agents did.

12 · WHAT CHANGED

Five different people got a different answer.

A recurring class of access requests moved out of manual intervention and into the product.

Access is a product decision

In enterprise products the question isn’t simply who should have access. It is what this person needs to accomplish, what information they need to accomplish it, and what should remain invisible.

Next story

Contact me

Connecting the dots

“You can’t connect the dots looking forward; you can only connect them looking backward.”

— Steve Jobs