In the first part of this tale, we explained our current partnership strategy, with a focus on our Add-on Mart partners. We also offered up a profile of our partnerships champion, Klaus Haertel. In today’s story, we’ll complete our analysis of the partnership onboarding process, and show you how it makes life easier for everyone within our business ecosystem.
Before we get started, here’s a quick recap of the partnership stages that we covered in our preceding story:
- Preliminary product research and internal demo.
- Identifying and recruiting proof-of-concept (PoC) customers.
- Signing a partnership agreement.
- Running a PoC and analyzing customer feedback.
- Finally, improving the scalability and technology stack of the prospective partner’s solution.
Now, on to “stage 6” for partners who are adding a solution to our Add-on Mart: the onboarding process. And a bonus surprise along the way: we’ll also be talking a lot about deploying those solutions via Kubernetes in Docker containers. Then, we’ll drive quickly through stages 7 through 10 – the last steps for our active, fully fledged Add-on Mart partners.
Stage 6: Packaging for the Add-on Mart (Cloud)
A key step of the proof-of-concept stage is to run and re-run (and re-run) the custom business logic code, virtually everywhere. By “business logic” code, we mean the thing that delivers the actual functionality of the solution. What we are doing is making sure that the code interacts with PortaSwitch correctly, and that the “end-to-end” process really does provide value to the end user.
After the PoC testing is over, it’s time to wrap that code so we can automatically deploy it for a new customer and run it safely in Add-on Mart Kubernetes. And that means a few more steps.
The Add-on Mart Partners Kubernetes Checklist
6.1. Pack your code into a Docker container
A quick tip: during the PoC, it’s a good idea to write and run the code using Docker. That’s going to save you a lot of time.
6.2. Provide a template for deployment configuration
As an Add-on Mart partner, there are a lot of “things” you will need for the configuration files: server name, IP address, or the security token for accessing the PortaSwitch API, for example. When developing locally (hello, PoC), you can simply type them in. Here’s the “but”: now (hello, Production Stage), the “things” have to be replaced with variables to test for different customers. So, when we deploy the code for customer A or customer B, we populate it with the given values for that specific customer.
6.3. Create a log. Make sure it’s compatible with Add-On Mart
We all aim for perfection. However, we know there is no “hassle-free” software code. (Except, of course, for that one-line “Hello World!” program you wrote during your first programming lesson.)
So, when your code runs in the cloud for customer #434, that customer might report a problem. And both you and our PortaOne support team need to know exactly what went wrong. Quickly.
To allow this, the code has to produce logs and debug messages. And, it has to do this in a format that can be picked up by the Add-on Mart log collector and transferred to our centralized storage. Once it’s there, you (or your development colleagues) can access the log via our web UI to figure out the problem and fix it. However! Please keep in mind that you will not be able to access the actual running code that’s on our production Kubernetes.
6.4. Interact with Add-on Mart using management APIs
This is where we test the interactions. These include functions such as “accounting” – meaning, the reporting of end-user usage for analysis and (last but not least) monetization of your module. Of course, the actual definition of a chargeable metric depends on the business model of your module. For example, the developer of a video conferencing app may charge a CSP for the total duration of video calls per month. In contrast, the developer of an MS Teams integration module might decide to charge for the total number of unique users who activated that feature, regardless of the number of calls they made.
As the module owner and Add-on Mart partner, you are responsible for calculating these usage stats and passing them on to the Add-on Mart accounting team. Once you’ve done that, it will get aggregated and applied to each CSP who is using your module.
6.5. Create a configuration schema and UI for your module
Each instance of your Add-on Mart module needs a set of parameters. As an example, there is the address of the PortaSwitch it should connect to. Our goal here is to ensure that the administrators can manage these parameters conveniently and track all the changes. For that reason, direct editing of the text files is a bad option.
As an Add-on Mart partner, you define which parameters your module needs. From there, Add-on Mart provides a simple REST API for changing those parameters for specific instances. On your end, the web application you provide will allow you to view or edit them. Here’s some good news: we happen to have a template application (written using the no-code platform bubble.io). And you can use it! (At least for changing some fields and their layout.) You’re also welcome to create your own from scratch.
Stage 7: The QA Screening
Explaining this one is easy. After analyzing and implementing the customer feedback from our successful PoC and pumping up the technology stack with our production-only solutions, then comes the quality assurance. Here, we test the about-to-be-born Add-on Mart app for smooth automated roll-out in the cloud and adequate cloud resource demand, and check it for any security and privacy risks. As a result, your product will feel smoother in the hands of your end customer.
Stage 8: Public Launch
Direct customer outreach matters more in B2B marketplaces than it does in the consumer apps you’ll find in the App Store or Google Play. Why? Because there are not that many “category top sellers” charts in the B2B world. Therefore, we boost your public launch via Add-on Mart by notifying our PortaOne customers that a new partner solution is available within our ecosystem.
And while we promote Add-on Mart as the ultimate B2B marketplace and the most significant locomotive for our partners, it’s essential to understand that it is not the only customer-facing channel. In fact, there are many options for our Add-on Mart partners! It’s all specific to the solution itself. Perhaps we might integrate a partner solution into PortaSwitch more deeply on the architectural level. Other solutions might improve the cloud infrastructure. Or the service delivery to the end user. And so on.
How We Help Our Add-on Mart Partners Launch (and Promote) Their App
Nevertheless, from the perspective of our Add-on Mart partners, the process is very straightforward. If you’ve ever published an app via Google Play or the App Store, you’ll find that it’s a lot like that. But our process is actually more precise, because we don’t (currently) have millions of apps. Realistically, we expect several thousand, at max. As of now, there is about one hundred. That means our review team is not overwhelmed, and can dedicate more time to our valued Add-on Mart partners.
Finally, after all the formalities (and metadata) are filled in, our marketing team joins the conversation. It’s their job to figure out a few joint measures to promote your solution to our PortaOne customers and prospects.
Stage 9. The First Payment
Just like our support and marketing teams, our payments team are alive human beings. That means you can ask them questions and track your payments. And in fact, they are instrumental during the launch stage.
We use the revenue sharing model with our Add-on Mart partners. The exact “revshare” distribution depends on two things:
- The amount of effort our marketing, sales, technology, and support teams have to invest in selling your solution.
- The amount of post-sale resources (mainly support, but sometimes technology) we will have to invest when customers start using your solution.
Klaus Haertel explains: “Revshare distribution depends mostly on what functions of the value chain our Add-on Mart partners expect PortaOne to cover. So there is room for negotiation for each case.”
Stage 10. Adding More Apps into Add-on Mart (and a Look at the PortaOne Accelerator)
Every “business being” in existence wants her operation to grow. So when we see that an app in our Add-on Mart is finding success and making our customers happy, we want to make that happen again. Please repeat the order, let’s do more together! An example of such a repeating success story is Yealink, which first started with modules for the T3 device line: T30P, T31P, T31G, T33P. Once those were self-certified, they added the T4, T5, VP59, and W70B device lines.
This is where the PortaOne Accelerator comes in. We are currently working on a support process to help our Add-on Mart partners enable faster growth. Via this accelerator, we will provide partial financing, along with mentoring from our best team members as well as reliable people from our personal and professional networks. Expect more news soon! An announcement about our first acceleration batch and information about how you can get involved is on the way.
Coda
This concludes our brief overview of the onboarding process for our Add-on Mart partners. You now can see the bigger picture: from the preliminary product research and PoC to your first payment and becoming part of the PortaOne Business Acceleration Program. Have any questions or want more information? Please contact Klaus at klaus.haertel@portaone.com.
