memberships consulting research events speaking books clients company
email
password  
Register   Help Sign In


Search our

advanced search
Search

 

HOW SHOULD YOU MANAGE CUSTOMER AND PARTNER PORTALS?
Patty’s Dream Team: Roles and Responsibilities You’ll Need for Your Customer-Centric Organization
By Patricia B. Seybold, December 6, 2007

(A PSG Classic – Originally Published February 2005)

NETTING IT OUT

When I originally wrote this prescription in 2005, many companies hadn’t yet implemented customer portals, although many did have partner extranets. Now, many firms do offer customer portals. Others are planning to launch customer and partner portals in the coming year. But few companies have gone to this next logical step: combine the oversight of customer portals with the oversight of partner portals. Most businesses still assign these responsibilities to different business owners with little or no coordination between them (except for some shared technology infrastructure). So, I decided the time is ripe to revisit this recommendation.

We define customer portals as customer experiences that are designed and delivered via the Web to specific groups of customers—for example, small business customers, individuals in a specific client account, or individuals in a common community of practice (such as corporate cash managers or high school English teachers).

We define partner portals as customer experiences that are designed and delivered via the Web to specific groups of channel partners—for example, partners that serve small business accounts, partners that sell to the pharmaceutical market, value-added resellers in Brazil, the system integrator that supports your 10 largest accounts, or all of the employees who work for a particular channel partner.

We believe that customer and partner portals should be designed and evolved side-by-side in order to best serve both audiences and to leverage common information and services.

But where should this function sit within your organization? Who should be responsible for designing, evolving, and managing your customer and partner portals? In this report, we provide some guiding principles you can use to evolve your own customer and partner portal organizations.

HOW TO THINK ABOUT MANAGING YOUR CUSTOMER AND PARTNER PORTALS

In watching our clients struggle to come up with the “right” organizational structure to manage and evolve their customer and partner portals, we keep seeing the same mistakes being made over and over again. Maybe some of these practices are creating problems for your organization, too.

In this report, our concern is specifically centered around portals that deliver customer experiences to external stakeholders, such as customers and partners.1 You may (or may not) find some of these suggestions useful when you think about portals for internal stakeholders—your executives, managers, associates, and employees.

We have some “Do’s and Don’t’s” that may help you design the roles and responsibilities for your own customer and partner portal initiatives.

WHAT NOT TO DO

Let’s start with the “Don’t’s.” They are:

• Don’t make portal design and evolution an IT function.

• Don’t separate portals from ebusiness.

• Don’t separate portal design and evolution from those of your other customer touchpoints, such as contact centers and IVR systems.

Let’s take a closer look at each of these caveats.

Don’t Make Portal Design and Evolution an IT Function

In many organizations, portal design and management is still being handled as if it’s an IT project—a project that you do once and then move into maintenance mode. But portals aren’t projects; they’re living, breathing customer experiences.

We believe that customer and partner portals should not only be specified by the business, but they should be managed within the business. The look and feel of a portal, the site navigation, the customer experience, the marketing and e-merchandising of products, the findability of information, the accuracy and consistency of the information presented, even the online tools and wizards used by customers—these should all be under the direct control of subject matter experts and professionals within the business. The functional evolution of the sites, the continuous refinement of Customer Scenarios®, and the continuous improvement of usability, content, merchandising, search, and navigation should also be the responsibility of business users.

Portal platforms and tools are now becoming sufficiently mature that it’s increasingly easy to let business end users manage the day-to-day design and evolution of customer and partner portals, leaving to the IT organization the tasks of implementing, maintaining, and supporting the underlying infrastructure.

Don’t Separate Portals from Ebusiness

Ebusiness was once considered a separate, fast-moving business unit that was purposefully walled off from the “real” business. Since 2002, however, ebusiness executives and their teams have been integrated back into mainstream business operations in most firms. Today, many ebusiness executives report to companies’ marketing organizations. They are responsible for their companies’ faces to the outside world—for setting the strategy and the priorities for evolving the companies’ various externally-facing Web sites, extranets, and, most recently, customer and partner portals.

Portals for External Stakeholders Are Ebusiness Initiatives. Portals used to be thought of as an evolution of companies’ intranets. Portal direction and implementation used to be handled by an IT organization in consultation with the departmental sponsors and end users of the portals. That’s beginning to change. Portal initiatives are no longer thought of as IT projects; they’re business initiatives. And, unlike “projects,” portals don’t go away. They live on as vital customer relationship channels.

Here’s the bottom line: External portals shouldn’t be separated from the rest of your ebusiness strategy and initiatives. Any portal that is externally facing—a portal that is used by a group of customers, partners, suppliers, investors, or other external stakeholders—should be designed and managed by business leaders in much the same way that the rest of your externally facing ebusiness sites—your corporate Web site, your ecommerce site, your customer support site(s)—should be evolved and managed: to deliver a consistent, cross-channel customer experience.

Don’t Separate Portal Design and Evolution from Those of Your Other Customer Touchpoints

This brings us to our third “Don’t.” Your customers and partners deal with your organization through a number of touchpoints and channels—not just your e-channels. If you design and manage your customer and partner portals separately from your contact centers, your IVR systems, and any other customer-touching technology platforms, you’re much more likely to provide a fragmented experience to your customers.

That’s why we advocate having a cross-channel, cross-lifecycle customer experience (CX) team that is responsible for the quality of all of your customers’ experiences across all touchpoints and across all of the stages of those customers’ interactions with your firm and its partners. Your customer and partner portal initiatives should be tightly integrated into your cross-channel customer experience design and management strategy.

WHAT TO DO

Emerging Best Practices and Principles

Here are some basic best practices and principles that may help you think through the right organizational structure for your customer and partner portal initiatives. Some of these practices predate the arrival of portal platforms as a distinct technology solution. Yet many of today’s portal platform technologies lend themselves well to the adoption of these principles. That’s because portal platforms typically separate the logical design of customer experiences from the physical design and delivery of the services that support those experiences.

Here are some basic, but perhaps radical, ways we suggest you think about designing and managing your customer and partner portals:

1. Customer segment advocates/owners are responsible for the design and evolution of customer/partner portals.

2. Customer account/relationship managers should maintain the portals for their accounts.

3. Customers and partners should administer, customize, and personalize their own portals.

4. Your customer experience design team is a business organization, not an IT one.

5. Your IT organization is responsible for developing, provisioning, and maintaining portal services.

6. Portal design and delivery should be tightly integrated into a cross-channel, cross-lifecycle customer experience design and delivery organization.

1. Customer Segment Advocates/Owners Are Responsible for the Design and Evolution of Customer/Partner Portals

Who should “own” each customer portal? We’ve found that the person best equipped to understand the specific requirements for each audience is the full-time “advocate” or segment owner for that audience.

For many companies, the idea of having specific customer experience owners for particular market segments is a new idea. For other companies, the customer segment owner role is a natural evolution from existing ebusiness and/or marketing responsibilities. The customer segment owner is the person whose job it is to understand the requirements and needs of a particular group of customers.

We’ve described the roles and responsibilities of customer and partner segment advocates or “owners” in a separate report.<a href="#2"><sup>[2]</sup></a> In the following example, we’ll recap and summarize many of the points that are most relevant to our discussion of customer advocates’ involvement in portal design.

*Footnotes*
1) Please refer to “Customer Portals: Central to Your Customer Experience Strategy,” January 27, 2005, http://dx.doi.org/10.1571/psgp1-27-05cc, and “Partner Portals Should Be Combined with Customer Portals,” February 10, 2005, http://dx.doi.org/10.1571/psgp2-10- 05cc, for our discussion of customer and partner portals and their interrelationships.

2) See “Customer (and Partner) Segment Advocates,” September 9, 2004, http://dx.doi.org/10.1571/os9-9-04cc.
*Footnotes*

This report continues...

To read the full report: http://dx.doi.org/10.1571/bp2-17-05cc.