Websites and Salesforce
Overview
So, you want a new website. Excellent. But wait... there's more! I like to think of a website as not only a website, but an extension of your business systems - a customer management platform.
Your "Website" includes
Your CMS (eg WordPress, Drupal, Expression Engine, Joomla)
Web Content
Analytics
Website Tracking
SEO
Shopping Cart
Forums
Your Business Systems could be:
CRM (eg Salesforce)
Email Marketing
Ordering and Distribution Systems
Case Management Systems
The Accounting System includes
Your Accounting System (eg Xero or MYOB)
Your Bank and Merchant Facility
Payment Gateway
Plus there may be other things that need to be factored in:
Apps - eg an iPad or mobile phone app.
The bits we need to work out first are:
What features are going to be included on the website
Which bits of the website need to be in your CMS
Which bits of the website belong in Salesforce
How the integrations between the Website, Business Systems and Accounting Systems will work.
Here are the rules that I try to stick by for website projects:
Just because it's on your website, does not mean it needs to be in your CMS. Your web presence that your client sees can be a multitude of systems, and be a seamless experience for you client.
Web content belongs in your CMS. Data belongs in Salesforce.
You have invested in Salesforce for a reason - don't try to replicate things in your CMS that belong in Salesforce.
Don't reinvent the wheel. If there is a plugin or another service that does the job better - DO NOT custom code it (there are some exceptions to this for exceptionally large websites).
Your client's experience is first and foremost.
Just because your web developer is a guru at doing X, does not mean it is the best solution for you (eg they may be great at doing Gravity Forms, but Form Assembly may be the best solution for you).
Nothing is sacred. Just because you currently use Drupal, it doesn't mean that WordPress or another CMS is the best for you, especially since your CMS will only be used for Content now, not Data.
Do things in stages - the back end processes could be manual for now, but as long as the front end looks good to your client that is what counts first up.
How do you know you have done it well?
There is no such thing as generating a report out of your CMS - because there is no data in your CMS.
There is no such thing as exporting data from your CMS - because data is not in your CMS, and the rare time it is, it is automatically created into Salesforce.
All financial transactions are reportable from Salesforce.
All financial transactions in your accounting system can be traced back to the source in Salesforce.
Everything you know about your customer is in Salesforce - EVERYTHING.
Some guidelines
10% data, 90% content - use a good CMS with simple Salesforce Integration.
90% data, 10% content - use Salesforce sites.
even mix of data and content - split it up into the CMS and Salesforce - it can still be seamless to the end user.
Remember, what your Web Developer calls content, we probably call it data, and data belongs in Salesforce.
When to not use a CMS at all?
You have multiple features on your website that require your customers to log in.
You want to have everything on Salesforce and no separate CMS
Look at Communities (see below) or a very basic CMS like CMS Force or the most fully featured Salesforce CMS Orchestra CMS.
Features of your Website
These are the features that may be on your website. A few of these features may be specific to NFP's only (eg Donations).
These are quick tips only, and not a substitute for a full requirements analysis, and for many reasons these suggestions may not be suitable for your requirements.
Communities
Throughout this page I have been mentioning communities. My rule for using communities is if you have more than a few features that you want your clients to log in for. Communities is the true self service portal. Yes communities is expensive, but so is custom development and the ongoing management of syncing data between systems. Licensing of communities comes in two flavours - Named Users and Active Logins per Month. You would use Named Logins for a small Community of Practice type group, and Active Logins for customer sites. If you have variable amount of logins over the year (eg your push for donations prior to tax time means that many people sign up or modify their profile), then logins can be averaged over the year.
You may have a staged approach. Customers can donate, register for an event and subscribe to your newsletter without being a community user, but then upgrade to a community user when they sign up to Volunteer or sign up for Membership.
Design
Note: there is not one mention of your website design on this page. That is almost limitless. Just ensure that the look and feel and branding are consistent (enough) across all sites. This will be much easier if you keep your main site design simple. Maybe go to town with fancy stuff on more static microsites.