Reminder of the Options

Part 1 provides a detailed review of the directions that data can flow, and the types of architectures you can use to support your solution:

• Data can be outbound to constituents, provided by individual constituents, or exchanged among constituents.
• There are all-in-one solutions, two-system solutions, and solutions with an API or data proxy layer.

Three patterns, three potential solutions: it’s temping to think they align 1:1 – but then a whole second article would have been a waste of time. But it is important to keep them in your mind as you determine the best-fit for your organization and use case(s).

Portal Architecture Considerations

To make the right selection you need to balance your overall data ecosystem, staffing, budget, audience interest, as well as projected growth over time. I keep wanting to create a simple decision matrix, but an easy solution eludes me still.

Audience Engagement

The first major consideration is how will your audience actually engage with the portal. This should drive not only how you build it, but if you build it at all. Lots of organization believe their constituents are all waiting for a great portal to see all their information, update their addresses, and even communicate with each other. This is rarely true. None of us is short on things to do online – you need to be clear about what makes your portal worth their time.

When you align your project to your audiences interest, a portal is powerful, useful, tool that can make a huge impact. But if your audience isn’t interested in what you offer them, you just spent a bunch of money on a web site no one uses. There are times when the most effective constituent portal is none at all – because you can use those resources elsewhere.

Think carefully about how many of you constituents want to log into your portal enough to:

1. Remember it’s there.
2. Care enough to take the time to log in.

You spend something like 40 hours (probably more) a week thinking about your organization’s work. They spend 40 hours (or more) a week thinking about their employer’s work, also their families, friends, all the companies and nonprofits they interact with, politics, meal planning, shopping, and whatever else – there isn’t much time left for your organization.

Think about the features you can provide that are valuable to your audience and the best way to deliver those. For example, organizations often want to give people places to update their address or payment information. But think about the last time you moved, did you want another place to change your address information? Another common ideas is that nonprofits want to make delivery of annual tax receipts cheap and easy. If successful that means a wave of use once a year that might save your on mailing costs – of course you can also ask for a gift in that mailing so it might not actually be a net gain.

Questions to ask:

• What problem does this portal solve for my constituents? Do they care if I solve it?
• What is the best way to deliver our solution to our constituents?
• Will my constituents be willing to log in at all?
• How will this portal empower themselves or to support our work?
• How many people need to use the portal each week, month, or year for it to be successful?
• Do we expect that number to grow over time?
• Will likely traffic be spread out, or come in a wave?

Technology and Data Ecosystem

Your portal does not exist is a vacuum. Your organization has lots of technology kicking around these days, and you want the tools you select for this project to build on your overall technology landscape. When I make a recommendation to a client, I spend a lot of time asking them about the tools that are already in place and how they are used. I’m looking for tools that could be the basis of the portal, reveal the expertise of their staff, and would work well with Salesforce (or other technologies I’m part of introducing). I am also trying to understand some of the history about those tools and how they came to be.

If there are other complex systems, and they are working well, that’s a sign that an organization can probably handle more complex architectures. It’s also a sign they probably know how to benefit from that complexity. But it’s also a sign their staff may be consumed with what they have. If they have all simple systems I am going to be inclined to keep my solution equally simple.

Questions to ask:

• How many interconnected data systems do we have today? Do they work well, or are we struggling to keep up?
• If we add a new system will it enhance our digital presence or pull attention from other critical systems?
• Are the solutions we are considering related to technology we already use, or are they entirely new?
• What kinds of resource, limits, and features does my main CRM provide?
• What other technical resources do we already have in place that we could leverage?
• Did past projects go well, or leave a bad aftertaste?

Staffing

Your solution will require staff support. Even the simplest of systems will trigger requests for help using it. The more complex the solution, the more skilled your staff need to be to make sure it runs smoothly – and the more staff you need to support it.

You staff bring two things to the table: time and skills. They need to have the skills to support your solution, and the time to use those skills effectively.

Please do not just plan to push your staff harder, you need to find ways to remove other tasks from their plate or add people to your staff if you want to avoid burn out.

If you use an all-in-one solution, you probably just need people who understand that platform, know how to engage with your user constituents, and can work with to provider’s support team. The more systems you need the more platforms your team needs to understand, and at least one person needs to have a deep understanding of how the whole thing works.

You also should consider aligning your technology selection to what your team either knows, or wants to know. Most of the time you want to play to your team’s strengths not ask them to develop a whole new skill set from scratch.

Questions to ask:

• What roles do we need to have for your portal to work?
• What work do we want done by our staff vs consultants?
  • Who will answer support requests?
  • Who will respond if there is an outage?
• Do our current staff have time for new responsibilities?
  • How can we reduce their workload to offset new requests?
• Can we hire more staff?
• What technologies do our current technical team members already know?
  • What are they interested in learning?

Budget

Obviously all this will cost money. There will be some combination of license costs, hosting fees, implementation costs, support contracts, staff salaries, and other expenses. Just because a sales person says their solution works “out of the box” does not mean it’s free to get started.

You need to account for the implementation cost: how much will it take to setup and train people on the new system?

You also need to plan for maintenance costs: what will it cost to keep it running every year?

In very broad sweeping terms my experience is that most of the time an all-in-one solution will be cheaper and faster to implement than a two-system solution. But all-in-ones often have higher annual operating costs. Those operating costs are likely to grow linearly with audience size. A two-system solution, while more expensive to setup because of the complexity, will often have a lower annual cost and lower price escalation curve.

When you are considering your options, those are the two budget figures to make sure you understand. What will it cost to setup? How much will it cost over the first 5 years? And what factors will impact those two figures?

Different organization can tolerate different cost structures. If your organization prefers to invest up front and have lower long-term costs, you should make a plan to optimizes for that. Other organizations want the lowest upfront risk, but can tolerate higher costs – particularly if they are linked to a successful and growing solution.

More complex systems are also riskier to build. There is a greater chance of hitting problems that require extra budget to resolve.

Questions to ask:

• What will each of my main choices cost to implement?
• What are the 1, 2, and 5 year costs likely to be?
• What factors will drive costs?
• What is my organization’s budget tolerance for up-front vs long-term costs?
• How firm is the budget? What are my contingency options for overruns?
• What are my options to control costs if there are problems?
• What can our staff realistically do vs what do we need to pay consultants to do?
• If we learn the portal isn’t working, what will it cost to cancel our contracts early?
• If my traffic will be in small bursts, will I have to pay extra for those bursts, or pay all year for services we’re not using?

Closing Thoughts

There is no one right answer to these questions, and they lead to complex matrix of decision making.

Take the questions I’ve posed, and have a robust and honest discussion about them. Ask your own questions. If you have a consulting partner you trust, have them test your answers and add their questions as well (sure, they are incentivized to get your to build it, but they should still have insights you want).

To make your final selection I suggest you write out a 3-5 year plan – this is a thing consultants can help you do well. Test it with your internal team before taking it to leadership. Make sure you understand it, and that your team understands it, particularly if a consultant wrote it.

I’ve been down this road a few times, and seen organizations make great decisions that led to successful projects, careful decisions that led to portals no one used, and wise decisions to walk away from their vision for a new plan. You need to be open to all possible paths.

Good luck!

This is the first in a series on what your choices are, and now to select the right one. The architecture you select will drive the implementation cost, maintenance costs, and scalability.

The Purpose of Your Constituent Portal

Before deciding on the architecture of your portal, you need to have a clear understanding of its intended purpose and expected scale. The purpose of the portal will also dictate the direction(s) data flows, and the scale will help you plan the long term costs.

If you can’t clearly state why you need a constituent portal, you don’t need one.

Different organizations have different reasons to create portals. Companies that sell products may want a warranty or support portal. Nonprofits often want a donor portal that provides tax receipts and allowed recurring donors to update their gift information. Member organizations want a place for members to see their benefits, update their information, and renew their memberships. And so on.

The purpose of your portal will determine the direction that data flows through it. There are essentially three directions that data can move.

Outbound Data

You can send data from your organization to your constituent. That could be things like receipts, memberships status, or product warranty information. Anything that is data you have, that your member might need to see, but not update.

Data Exchange

You can allow constituents to update information. That could be address changes, support requests, donation schedule updates, event registration details, and more.

Data Network

Your third option is to allow you constituents to exchange information with each other. This could be a any form of member community where they engage with each other.

When planning a network, remember you have to plan for content moderation and acceptable use policies.

Primary Portal Data Architectures

To support your portal, whatever the data flow is, there are three main data architectures you can choose from, each which a different strengths and weaknesses. The more complex your architecture the more options you will have for what it can support, but it will also increase costs and maintenance efforts. Bigger is not always better – sometimes it’s just more expensive.

1. All-in-One Constituent Portals

In an all-in-one solution your constituent portal is part of your CRM. For obvious reasons this is the type of portal that your CRM vendor wants to sell you. In Salesforce land this means Experience Cloud. There are also many nonprofit-focused CRMs which include one in their solution. When your portal is part of your CRM you get a bunch of advantages:

• Data all lives in one place. There is no data sync to worry about setting up or maintaining.
• You have one vendor. That means you can centralize your support arrangement and billing.
• They are often fastest to implement. They are designed to be fast to market to help make them the obvious choice.
• They generally do not require a developer. Again, your CRM vendor really wants you to select this path, so they clear as many hurdles as they can.
• There is only one technology stack. By leveraging the technology of your CRM your investments in learning that technology carry over, at least in part, to your portal.

There are also downsides:

• New template system to learn. The CRM’s portal likely has a different template system than the CMS on your main web site. That may be hard to make match your primary online branding.
• The vendors make a lot of assumptions. To provide that ease listed above they make assumptions about how data flows, security, user experience, and how other elements should work – those assumptions may not match your ideal solution.
• Costs often scale linearly. There are usually license costs that are scaled based on user count meaning your costs grow as the portal grows at more or less a 1:1 rate. While there are price breaks and other incentives this is the right expectation to have for estimating.

2. External Constituent Portal

In this pattern an external constituent portal moves the user experience from within your main CRM’s sphere of influence into a separate platform. In my career I’ve mostly built these with Salesforce as the CRM and Drupal as the portal platform – it’s a powerful pairing. The strengths and weaknesses here are more or less the mirror of the all-in-one portal.

• Your web team may already know the technology. If you use the same technology as your web developers use for your main web site(s) they already know who to handle design and branding.
• You have greater control over the User Experience. The assumptions that go into the portal are yours not the ones imposed by the CRM.
• You have greater control over security, along with data flow and formats. Since they aren’t built around assumptions you don’t control you have greater control and freedom.
• Costs typically grow more slowly. It is less common to have per-user license costs in this context so the cost curve is likely closer to logarithmic.

The downsides:

• You have to handle data synchronization. The two systems means data has to pass back and forth.
• You have two different vendors/platforms. When you had one system everything was centralized, now you have two different systems handling constituent data.
• This design typically is harder to implement. All those short cuts your CRM provider had in mind for you are gone. Even if you use a purpose built solution it’s going to take more time and effort.
• This approach generally requires a developer and/or data architect. To implement this pattern you need someone who understands both platforms – ideally both for setup and support.

3. External Constituent Portals with Data Proxy

In some situations it makes sense to insert a data proxy, or API layer, between your main CRM and your constituent portal. This creates a layer of abstraction, security, and data augmentation that can benefit a lot of organizations. While this is the most complex of the three main architectures it is one I find is frequently overlooked – in part, I suspect, because no one partner benefits from selling it.

This setup certainly isn’t for everyone, but when it’s the right fit it makes a huge difference. It also creates a significant number of iterations – all of those arrows could be one directional or two directional.

An extra data layer makes the most sense when data from your CRM is going to multiple places and/or needs to be augmented by an external data source. For example think about an organization that provides trail maps for hiking or paddling. All that data geocoding those trails does not need to be in your CRM, but you probably want to know which members are interested in which trails so some trail data is needed there. Meanwhile in public you want a great deal more information all linked together. An organization like that may have a portal for members, a web site to find trails for non-members, apps for iPhone and Android, and perhaps a public API for other people to use to build their own web sites with. That’s a lot of API calls all with different data sets, all of which need to be very fast.

Your CRM is designed to be very stable and reliable – it is not designed to be very fast. What’s more, you often have limits on the number of API calls you get in your package (with extra fees charged if you go over). By inserting another layer between your CRM and other services you can bypass these limitations.

There is another added benefit to this design pattern, and that is increased security. By creating an additional layer in your system you are able to create a separation of concerns between the various systems. Each should have access to only the data is absolutely needs from any of the others.

How to Pick?

There are lots of considerations that go into selecting the right architecture for your project – which is why that’s getting it’s own post soon.