Build vs Buy: 4 Considerations When choosing a customer portal

Customer Information and Customer Portals

Pop quiz: Where do your customers go when they need something?
If you’re like 90% of B2B Customer Success teams, the answer probably is: it depends.

Most organizations lack a single defined repository of where customer information sits. Scattered between the website, email attachments, and the help site, it can be difficult for customers to navigate the maze of content. And as engagement plummets and support costs rise, the need for a central repository of all customer-facing material becomes apparent. But for organizations investing in customer portals, should you build one in-house, or purchase an off-the-shelf solution?

Let's look into 4 key considerations when deciding whether to build or buy when standing up a customer portal, and the implications they have for growing businesses.

Types of Portals

As far as customer portals are concerned, there are largely two different kinds of portals:

Single Use Case Portals

Single Use Case Portals are largely designed around a singular problem and are created to solve only that need. Examples of single use case portals might be onboarding or training portals, where the end goal is to have the customer use the portal when they have a single specific need.

Extensible Portals

Extensible Portals Are the multi-tool for customer engagement. These portals will often have separate modules for different use cases - a training section, onboarding section, content section, and so on. While they contain more functionality, they are usually a heavier lift to get started and will take more time to maintain.

Choosing the Right Portal

The right kind of portal for you will depend on how immediate and deep your needs are. If you’re facing a specific onboarding issue, a single use case portal might be a great option - but if you’re trying to tackle the general problem of customer engagement being low, you may need a larger and more extensible portal to create the kinds of experiences that would raise engagement. Lastly, an important consideration for the kind of portal to choose is how personalized you want the experience to be.

Key customer portal questions to consider:

1. Will every customer logging in see the same thing?

2. Will different customers get different views based on where they are in their journey?

3. Should different users see different content/training/next steps based on their user role or activity within the platform?

While we’d like to imagine customers flocking to the portal and getting unique experiences, creating and maintaining these views can be difficult. Ensure you’ve settled on the right amount of customization you’ll need before diving headlong into the process of standing up a portal.

Takeaway: Whether Building or buying, make sure you’re solving for the right use cases. Don’t pigeonhole yourself into single use cases if you know bigger issues are around the corner - but understand the time horizon you need to see benefit by, and ensure you’re getting immediate benefit.

How will the portal be updated?

Many teams that build their own portals create a fantastic portal on day 1… but by day 100 they’ve gone stale. Keeping in mind the maintenance and updating needed to make the portal the experience you want it to be for customers is going to heavily guide your build vs buy consideration.

The "Hub and Spoke" Issue

As a first step, think about how you’ll manage your portal. Most organizations utilize a ‘hub and spoke’ model, where ownership of the portal is shared among SME’s in different groups. Those SME’s are responsible for keeping their ‘section’ of the portal up-to-date, and do so by meeting with the people that are in charge of maintaining the portal. This model introduces a ton of internal friction, and leads to content not being updated.

The hub and spoke model of home-built customer portals is popular, but can be fraught with issues. We recommend a shared approach, where users can actively add and update content when it becomes available (or automatically update via an integration). Those users can be responsible for content engagement and ultimately own their experience for users. Once you’ve settled on a management strategy, think about your content lifecycle and the people that will be managing the portal.

Customer facing teams and portals tasks:

* Add new content

* Suggest content for users

* Retire old/inaccurate material

* Keep up with Customer Pages

* Update different types of content - things like learning paths and onboarding guides

Takeaway: If you need a portal to be updated often, consider building that into the process from the start. Building your own portal may seem attractive to allow the organization to ‘own’ the process, but a self-made portal often becomes difficult to update and becomes stale over time.

Customer Portals and Integration with your Internal Tech Stack

While your new portal may come with loads of functionality, it may need to integrate with one (or more) of your internal CS tools in order to be valuable. Important integration points to consider include:

Content

Where is the content within the portal coming from? Is it being sourced from another system (e.g. your knowledge base), or will all of the material in the portal be brand new? How often is the content updated, and how do new things enter the portal?

CRM’s and CSP’s

If you’re creating personalized views - where do the account and user information come from? Where do the analytics of activity within the portal go to and how do they influence downstream processes?

Help Desk

Quick call out here - If you have an existing process to manage helpdesk tickets, you likely will not need to integrate with a helpdesk platform. On the other hand, if your support processes and resources are scattered, integrating your customer portal with a help desk or ticketing system can be a great way to put both education and support into a single workflow and skyrocket the kinds of customer engagement you’d want to see within the portal.

Application Activity

Should the portal be influenced by how users interact with your product? If so - how will that information make it in the portal?

Takeaway: While standalone portals can be valuable, so much of the benefit of a customer-facing portal is unlocked when it starts to interface with your other internal systems. If your team is able to easily Identify the key integration points and has a plan for building all of the integrations, building can make sense. However, if you have more than 3 systems you know you’d like to integrate with, it will typically make sense to purchase an off-the-shelf solution.

Customer Analytics, Workflows, and Other Important Considerations

Finally, let’s review some of the scattered (but important) implications that a portal may have for the organization and discuss the implications they have on building or buying a portal

Analytics

Regardless of the portal solution you go with, recording customer activity within the portal is going to be a huge priority for the CS team as it’s going to be a leading indicator of engagement. If building, how will you track engagement and where will the engagement go? If buying, how granular of an analytical report will your vendor provide?

Alerting/Workflows

Oftentimes, activity within the portal is going to lead your CSM’s to want to take action - imagine a customer that heavily interacts with upsell content, or a user that visits the same help content several times in a row. How will the system notify your CS team based on activity within the portal? Can the system go as far as to open deals in your CRM based on activity? Define how you’d like the portal to push your CS team to activity.

Previewing Portals

If you’ve chosen a personalized portal experience - how will your CSM’s be able to see what their individual customers and users are seeing? Does the application have the ability to preview or show a ‘read only’ portal?

Takeaway: Keep in mind that a customer portal should ideally make an impact far beyond a user logging in and interacting with it. Identify the ways that you’d like your portal to interact with CS and other teams - and, if building, ensure your internal team has the appetite to build this functionality.

Conclusion

Standing up a customer portal is a large cross-department effort that should have a giant impact on how you interact with your customers. As a final takeaway: If you’re looking for a simple place to store content or onboarding paths that you can direct customers to, building is likely the better option. However, as soon as you start to add use cases, it becomes a slippery slope of functionality that internal teams are often unprepared to support. As complexity increases, buying becomes the more economic option.