We’ve been customizing Salesforce.com for nonprofits for more than a year now – we’ve helped enough nonprofit’s customize, migrate data, integrate with payment tools, Vertical Response and more – and we have just enough information from all of those projects to begin to see what happens AFTER we’re done.

As most know – moving to a new tool of any sort provides benefits and challenges. When I upgraded to the Microsoft Office 2007 suite, I had to fight with the toolbar, and finding the “print” button was excruciating – I wasn’t used to where things were, wasn’t ready to explore new offerings – I just wanted to have all of the new features available so I could use then when I was ready. I’ve been using Word and the other Office tools since their inception – so I’ve been through this before, but I was reminded that even an updated tool, with a LOT of user and usability testing can pose adoption challenges.

Imagine what it’s like moving from MS Access, or FileMaker Pro, or eTapestry to Salesforce then? Add in a complicated data migration, some thinking about doing things in new ways -and all of a sudden Monday morning with that new tool can be grim. Here are some things that you can do to get ready to adopt and adapt!

• It can be easy to overlook some of the key players in your agency – the volunteer that enters data, the finance expert that reviews and reconciles donations, the program team that matches volunteers, the development officer that plans events. Using Salesforce successfully means that your WHOLE team uses the tool actively – not just for reporting. So – you’ll want to make sure their voices and needs are heard during planning – so that when the tool rolls out – they know what they are getting!

• Every agency needs a product champion, a go get it, I love it, this is great, I can help you make it work for you. You don’t want to rely on your vendor for this – you need to OWN this expertise in house. This should be the person in the agency that is excited about Salesforce, participated in planning, has read the documentation, and isn’t afraid to try.

• We provide documentation for all of our projects, and you should expect that from a vendor. Make sure that it has both general information (how do I look up a contact) as well as information specific to your needs (how do I match a volunteer with a client). The information you need to “do it yourself” is probably in your documentation.

• That’s right – no one knows better than you. Make a quick “job aid” – a one page tip sheet, a “I always forget this step” list, and more. You can help your team over the hurdles with some very targeted, agency specific help documents.

• On launch day, have your vendor on hand. Sure, it will cost more -but if your team is frustrated on Monday, and doesn’t get help until Friday – you might not ever get them to use the tool.

• This is an on demand, use it every day type of tool. It won’t add much value if you update contacts, create follow up notes and activities, and create opportunities only every once in awhile. Meet someone at a party that might support your mission? Add them to Salesforce, create a giving opportunity, and make a follow up note to call or write.

• Don’t forget the 70/30 rule – about 70% of your time and money will be in the planning, training, and retraining category, and about 30% in the actual implementation. That sounds like a LOT of money – but if your team can’t get a driving license – the care won’t help much.

It’s easy to assume (at least for me) that most if not all of my nonprofit customers have been able to acquire a nice broadband connection. So I was surprised (but shouldn’t have been!) when one of my customers wanted to know what the bandwidth usage would be like if they moved their work to Salesforce. They have a shared infrastructure and some stringent requirements for ensuring that a certain amount of their pipeline is available to their constituents.

We considered an onsite usage test – but we would have had to reveal customer data – plus – we’d be making things up – what they really wanted to know was “how much bandwidth will OUR implementation of Salesforce use?”

So -we asked Salesforce -and they provided a LOT of information. Here’s the key points:

Bandwidth Required for Users
Salesforce.com is designed to use as little bandwidth as possible so that the site performs adequately over both high speed, dial-up, and over the air Internet connections.

• While average page size is on the order of 90KB, salesforce.com uses compression as defined in the HTTP 1.1 standard to compress the HTML content before it is transmitted as data across the Internet to a user’s computer. The compression often reduces the amount of transmitted data to as little as 10KB per page viewed due to the lack of image content. The site was designed with minimum bandwidth requirements in mind, hence are extensive use of color coding instead of images. Our average user also is known to view roughly 120 pages from our site per day.
• Our application is stateless, therefore, there are no communication requirements in the background once the page loads like traditional client server applications e.g. Outlook. Therefore once the page loads there are no additional bandwidth requirements till a user queries or writes information to salesforce.com.
• In short, it is difficult to specify customer bandwidth because of the nature of the Internet and individual corporate usage. Network latency, peering issues, bandwidth at upstream providers, users using their Internet connections for other use besides salesforce.com, etc. all affect the perceived performance of the connection and the amount of bandwidth required to keep performance adequate.
• A Salesforce.com deployment of 80 users with 75% of the users concurrently logged in with a think time between transactions of 2 minutes: Avg Bandwidth = 120 * 60 / ( 120 + 2 ) = 59 Kbits/sec

Obviously – your mileage may vary depending on the nature of your connection to the internet as well as what other internet related work you are doing. It’s likely more helpful to know your total bandwidth needs and to understand how they all fit together rather than to know what Salesforce uses by itself.