This project has been my passion for several months, so I am thrilled that we have just been able to launch version 1 this week!

So my goals for this article are to go over:

What was integrating with Progressive Leasing like before this project? What prompted us to start a change?
How were our competitors solving for integration to retailers?
What is a “dev portal” and how can it be used to help Progressive integrate retailers?
Then finally, what have we just rolled out, and what are our plans for future versions of this project?

First I want to start with a story about our ideal partners.

Randy Phelps is a sales executive with Botherton, a medium-sized, regional furniture retailer.

As a pandemic sweeps the nation, he notices a sharp dip in his company’s earnings. About 40% of his customers’ monthly credit card transactions are being declined.

Randy needs to provide an alternative payment method for his customers. As his company’s technical resources are slight, he needs to recommend a solution to his executive leadership that is both quick and easy to integrate. He researches his options and discovers Progressive Leasing.

Randy reviews product details and demos on the Progressive Leasing website. He finds the opportunity compelling and shares his thoughts with Botherton's CTO, James Bartholomew. James enters the Progressive Leasing developer portal and evaluates the implementation process from a technical perspective. Thanks to the provided APIs and documentation, James agrees with Randy that Progressive Leasing would be an ideal alternative payment method for customers and not be a burden on his small technical resources. Together, Randy and James present the opportunity to their firm's CEO.

From this story, we see that there are two different types of personas involved in making this decision to pair with Progressive Leasing.

Randy is the example of the Business Manager persona.

As a Business Manager, he wants to review the product to make sure it will meet his company needs and enable them to make money.

James would be the example of the Developer persona.

As a Developer, he reviews the technical documents to see if it is EASY to implement, as well as secure, on top of the business value it offers.

So now we want to jump in to the problems Progressive was facing with our previous integration process.

Coordination: Retail partner integrations require extensive upfront resources to determine a solution. Both from Progressive and the retailer. (hours on phone calls- spanned over weeks).
No testing options: We don’t have a sales tool that allows potential partners to quickly evaluate our tech documents, so they can understand what it takes to become a partner. (Tom and Mike often become part of the sales process due to the lack of distributable documentation, but we do not give our retailer partners a trust signal they can use to evaluate us.)
Scalability: Each partner integration requires manually customized documentation.
Discoverability: Potential merchants do not know we have a retailer solution they can integrate.

This is a visual of retailer's current experience on progleasing.com. The location and size of the “For Retailers,” button is itty bitty and tucked away in a corner.

Why do these problems matter? We would now like to walk you through the opportunity we are losing out on...Lets quantify it.

Currently about 2% of all site traffic that comes to progleas.com, click on “For retailers” (That ends up being between 15-20k page-views per month).

So lets say only 1% of that traffic clicks on contact us...,.that would generate 150-200 new retailer leads per month.

And if only 10% of those retailers lead to newly formed partnerships, that would be 15-20 new retailers onboarding per month.

The average retailer generates $800-900 per day in invoice, so for the 15-20 new retailers that would be 4.4 million new every month.

But we would need to integrate those partners, which is why the problems we listed matter.

So how is our competition handling integrations?

We will dive into two examples.

The first is Affirm.

1. Notice the title sentence--- They want two things very clear---you can integrate with them AND the what that gives is an alternative payment method.

2. They are highlight e-commerce. That is the first options of action they give, so they must bring a lot of value and dollars to Affirm.

3. They still have other ways to integrate. The call to action buttons lead to more detail.

- Affirm uses a layered approach. After their landing page that we just saw, they lead to what is marked here as 1. They use this as a middle layer. They explain in paragraph form, easy to understand, the different elements that are important to the integration they offer.

- The second page here, is the next layer after that. This is completely technical and refers to their rest API. However the elements are organized in the same way as the middle layer- the difference is this communicates how to technically make it happen for the retailer.

Next, we have Katapult.

Similar to Affirm, we notice a landing page. The first sentence they show also calls out integrations.

• Next, you see the logos to e-commerce platforms just as Affirm had.

• And of course other forms of integrations as well.

The main difference between Affirm and Katapult is that Katapult has a closed API. Which means they require a login to see that more technical documentation. You must apply to be a merchant before that can be viewed.

Although we only showed two options, there were clear patterns we saw across our competitive analysis.

• The clear callout that you can integrate

• They have e-commerce platform plug-ins

• And whether behind a login or out in the open, the ability to see and test an API.

ITS IMPORTANT TO NOTE THAT OF ALL OF THESE WERE SHOWN THROUGH A DEVELOPER PORTAL.

So now we have talked about the problems we see our Prog retailers go through, AND we talked about how are competitors are handling this need, so now lets talk about why Progressive should care about the use of dev portals.

So what is a developer portal?

Well a developer portal should explain the business value of the platform.

• Allows potential partners to try before they buy—give them a trust signal.

• It provides a common knowledge area, Where all parties involved in the purchasing decision can learn about Progressive, and stay informed.

• It also provides technical support, that is self-service, to save time. With an implementation guide for your API.

We suggest a three layered approach. It would look similar to our competitors, with a homepage that appeals specifically to developers, then a set of components.

Below you can see an example of the landing page that is live currently, as well as wireframes demonstrating how the second and third layers will look once we have completed the API documentation that will go

Also here, not mentioned earlier, is a basic iteration of a feature we plan to build in a future version where our personas can take a quiz in order to be led to the integration that is best for them. Which would help reduce the amount of time our Solution Architects need to spend on the phone and zoom with clients.

So what's next?

•Well, we will work the partner API team. With them owning the technical documentation, we want to make sure that the shell we build to guide retailers through those layer, create a seamless path to that documentation.

•Part of that work is making sure we have consolidating and proposed the proper documentaion.