Contributed by Hub member Brad Struss.
You are ready to adopt Salesforce for your organization’s core program or fundraising work. The vendor’s demo was impressive and the checklist of features looks good. Now is the time to dig deep: Take the App for a test drive to ensure that it really matches your day-to-day work, talk to other organizations using the system, understand where the product is going, and find out if they support the product in the way your organization will need.
The strong adoption of Salesforce in the nonprofit and higher ed communities has led to more software vendors creating apps targeted specifically at nonprofit and higher ed institutions. Many of these are core applications like fundraising, student recruitment or case management, ones that your staff will use everyday to effectively run your organization. Choosing the right solution requires caution and diligence. It takes more than looking at a demo and reviewing a checklist of features. You need to figure out how the features really work. Once you have done that, it requires digging into questions that may not be obvious. Why is this so important? While you should be careful when choosing any AppExchange solution, evaluating a core application is especially important. Implementing these core applications involves planning, data migration, customization, and staff training -- you don’t want to go through that process again if you chose the wrong solution.
Here’s our list of things to consider when choosing a core application for your organization or institution. When appropriate, we’ve suggested what a good (and not so good) response from the vendor might look like.
1. Does the system fit your core business need?
Ask specific questions of the vendor about how the system handles processes that are key to your organization. For example, if you have an intensive client intake process, understand how the system matches your process. Install a copy in your Salesforce sandbox and try out your key processes. How well does it map to your business processes? If you will need to change your processes, what will the impact of those changes be to your organization?
2. How many other organizations are currently using the system? How long have they been using it?
If you are one of the first, you are more likely to experience the pain as the vendor goes through a learning curve on supporting and enhancing their product. A client recently told me, “We are done being on the cutting edge. We just want to be fast followers.” You need to decide which category you want to be in. Examples of pain include products with lack of adequate documentation, lots of bugs, or compatibility issues with other applications from the AppExchange. One benefit to being an early adopter is that it may give you an opportunity to have a stronger influence on product direction - the vendor should want to make sure you are extra happy.
3. What do other NPO's or Higher Ed institutions using the system have to say about their experience?
There’s no better way to get a feel for how your experience will be than talking to peers using the system today. But don’t just rely on the vendor’s reference list, ask around or post a question about the tool through social media, the Salesforce nonprofit google groups, or the Higher Ed Chatter community. Start by asking these other users about their overall impressions of the system. After that, ask them tough questions about functionality, support, documentation, and the onboarding process.
4. What is the roadmap for the system?
Understanding where the vendor plans to go with the system helps you understand how invested they are in it. The roadmap will lay out the features you will be able to take advantage of down the road (potentially saving time and money for unnecessary customizations). The roadmap will also expose current product shortcomings you may not have identified. Good vendor response: “Here’s our six month release plan. What do you think?” Not so good: “Roadmap? Um, we are going to fix some bugs next month...”
5. What support is available?
Understand how they support the product (email? phone? online forums? knowledge base?) and what the response time is. Ask other users how helpful and responsive the vendor’s support is.
6. What does the vendor provide for documentation and training?
Sadly, documentation and training resources are often the last thing to be built when creating a product. Ask what documentation the vendor has and ask to see it before you buy. If it’s a work in progress, ask them to put in writing the specific timeline for what will be available and when. Good vendor response: “Here’s the link to our documentation, video tutorials and knowledge base.” Not so good: “We are working on hiring someone to do that.”
7. What is their licensing model (site license vs. user licenses)?
Aside from cost, the licensing model impacts the functionality and information users have access to. Site licenses simplify your planning. With per-user licenses, you will need to constantly reevaluate which features each user needs and at what point it's worth paying for an additional license. In most cases with core applications, you should avoid the temptation to save money by restricting access to information or features that all users could benefit from. Let’s look at fundraising software as an example. You may be okay limiting donation information to only your licensed fund development users. However, many fundraising systems include features to track communication preferences, relationships, and employment history that may be relevant to users outside your fund development team.
8. Is what you are seeing what you actually get?
This seems like an odd question, but in one case the demo version included reports and dashboards that were not included in the application. Some vendors offer customizations to new customers. If so, find out what features you should be asking to have included as part of your setup.
9. How do they work with partners?
If your organization is using a consulting partner to help you with your implementation, understand if and how the vendor works with partners. Key related questions include:
- Do they have technical documentation available for their system? Is it complete? A system that is not well documented at the technical level will cause your partner to spend more time (and more of your money) getting the system right for you.
- Are they proactive in sharing details of upcoming releases? If you and your partner know the details about upcoming releases, it can avoid gotchas when the new releases come out.
10. Is the system you are buying a managed package or is it unmanaged?
There are pros and cons to both approaches that could fill their own blog post. Here’s the short version:
- A managed package makes it easy to receive updates from the vendor as they add features. However, a managed package makes it difficult or impossible to change core assumptions the package may make. If the assumptions of the package match how you run your organization, then this isn’t an issue. If you are buying a managed package, how many managed packages has the vendor built before? Managed packages have lots of rules about how they work. Think twice before buying a package from a vendor who is just releasing their first package.
- Unmanaged packages are powerful because they are completely flexible in how you modify or customize it. The cost to that flexibility is that “upgrading” is a time-consuming and costly manual process.
Get your consulting partner involved. If you are using a partner to help you implement your Salesforce system, they can help you answer the above questions. Your partner can also talk to peer partners that have implemented the system you are evaluating.
The above list is not foolproof (see the demise of Common Ground), but it will help you make an informed decision and reduce unwanted surprises.