Databases

Salesforce Bandwidth Notes

schmittr — 2008-06-26T16:42:47Z

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 practice we have found the bandwidth requirements for other commonly used programs place a much higher demand on Internet bandwidth. We have found through working with our customers that email (business & personal), email attachments, News, streaming video, stock update, place a much greater strain on the available bandwidth. We recommend the customer measure all activities to make sure they are evaluating a holistic demand on their network services. For example, is the Account Executive sending a 7MB marketing brochure or PowerPoint presentation to a customer.

The application of the formula "Peak bandwidth/number of users = average bandwidth per user" does not accurately portray the average bandwidth usage by the average user at salesforce.com. Salesforce.com handles considerably more transactions per second in aggregate from all our customers than any one individual customer would see from their end (since not all users would be actively loading pages simultaneously).

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.

However we have had some success in understanding customer's requirements by considering the number of users, the think time between transactions and the average response time.

Bandwidth = P * U / ( T + R)

P = Average page size in Kilobits as opposed to kilobytes - This conversion is necessary as bandwidth is measured in bits and not bytes (8 bites to a byte). The average salesforce.com page size when compressed is typically in the range 10 Kilobytes - 20 Kilobytes or 80 kilobits - 160 kilobits. The midpoint is 120 Kilobits.
U = Number of logged on users, assume a concurrent logged in rate of 50 - 75% of user community.
T = User think time between transactions in seconds, typically figures here range from 10 seconds - 40 seconds in call center/service environments to 120 seconds - 300 seconds in sales environments
R = Average response time in seconds, use an average of 1 - 2 seconds per page refresh

For example:
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

In a sales environment an active user would typically conduct around 15 - 20 transactions per hour.

HTTP 1.0 versus HTTP 1.1
Typical web pages (a HyperText Markup Language (HTML) document), contain many embedded objects - today twenty or more embedded objects are quite common. The large number of embedded objects represents a change from the environment in which the Web transfer protocol, the Hypertext Transfer Protocol (HTTP) was originally designed.

As a result, HTTP/1.0 handles multiple requests from the same server inefficiently, creating a separate TCP connection for each object. Each of these is an independent object and retrieved (or validated for change) separately. The common behavior for a web client, therefore, is to fetch the base HTML document, and then immediately fetch the embedded objects, which are typically located on the same server.
The recently released HTTP/1.1 standard was designed to address this problem by encouraging multiple transfers of objects over one connection.

HTTP/1.0 opens and closes a new TCP connection for each operation. Since most Web objects are small, this practice means a high fraction of packets are simply TCP control packets used to open and close a connection. Furthermore, when a TCP connection is first opened, TCP employs an algorithm known as slow start. Slow start uses the first several data packets to probe the network to determine the optimal transmission rate. Again, because Web objects are small, most objects are transferred before their TCP connection completes the slow start algorithm. In other words, most HTTP/1.0 operations use TCP at its least efficient. The results have been major problems due to resulting congestion and unnecessary overhead.

HTTP/1.1 leaves the TCP connection open between consecutive operations. This technique is called "persistent connections," which both avoids the costs of multiple opens and closes and reduces the impact of slow start. Persistent connections are more efficient than the current HTTP 1.0 practice of running multiple short TCP connections in parallel. NOTE: These persistent connections are only open for the duration of the page load � they do not remain open in the background.

HTTP/1.1 also enables transport compression of data types so those clients can retrieve HTML (or other) uncompressed documents using data compression; HTTP/1.0 does not have sufficient facilities for transport compression.

The following study showed that aggressive use of additional compression could save almost 40% of the bytes sent via HTTP:

Jeffrey C. Mogul, Fred Douglis, Anja Feldmann, and Balachander Krishnamurthy.
Potential benefits of delta encoding and data compression for HTTP.
In Proc. SIGCOMM '97 Conference, pages 181-194, Cannes, France, September 1997. ACM SIGCOMM.

Therefore we recommend at all times our customers use browsers that adhere to the HTTP 1.1 standard as it creates a number of efficiencies while using our service.

Relevant Solutions:
Use HTTP 1.1 through proxy connections:
https://na1.salesforce.com/501300000000grZ

Is Salesforce.com right for your Nonprofit?

drewb — 2008-03-26T16:36:49Z

Salesforce Benefits - Customer

This document is meant to be a short starting point for nonprofits to make a decision if Salesforce.com is a good choice for their nonprofit. It will give some introduction to what Salesforce.com does, and the benefits and risks involved in using it.

What is Salesforce.com?

Salesforce.com (NYSE:CRM) is a San Francisco company that makes an online database available to nonprofits. The database is very flexible, and that allows a nonprofit to use Salesforce.com for tracking donor management and other activities.

The Salesforce.com Foundation, which has overseen the donation of Salesforce.com cash, staff time, and products, currently donates 10 user licenses of Salesforce.com to any qualifying charitable organization.

What can Salesforce.com do?

Salesforce.com can help nonprofits keep track of the people they work with, and all the work they do with them. Salesforce.com can be:

A centralized contact list of all the people and organizations you work with
The place for prospecting and tracking donations, grants, memberships, and volunteering
The system for tracking just about any of your other program-related work: canvassing, phone banking, events, tabling, outcomes and evaluation, etc.

Salesforce.com allows you to easily track important communications you have with people:

It can be a shared contact list for your organization, accessible via the web or directly within Outlook
It makes it really easy to record communications and meetings, again directly from Outlook or via the web
You can cross reference communications to people and also to donations, grants, or other things

Salesforce.com has powerful querying and reporting tools:

The information you enter can easily be used to help you make organizational decisions
With the built-in report builder that requires no coding, users can build and share reports
Dashboards that display report information in charts and graphs can give EDs and Boards compelling summaries of your work

Salesforce.com likes to share:

Your information can be made available to your other technology systems (as appropriate) through relatively straightforward coding
Information from your other systems can, just as easily, be brought into Salesforce.com
Lots of affordable services, like email blasting systems, currently integrate with Salesforce.com

What can't Salesforce.com do?

Salesforce.com, like all software, has limits:

Salesforce.com isn't an accounting system. You can purchase connectors to products like Quickbooks, but accounting functions aren't handled by Salesforce.com.
If you are doing very complex donor management, Salesforce.com may not have the functionality you need to be successful.

What are the benefits of using Salesforce.com?

Low Cost: Salesforce.com is very inexpensive to use
- No server, no one to maintain the server--all you need is a browser
- No monthly cost for using the system--Salesforce.com donates 10 user licenses to every nonprofit. That's a $15,000 per year donation.
Centralized Data: You can do most of your work in one system.
- Handle people who play many roles in your organization--donor, volunteer, board member
- Support the unique work you do that most other systems can't support
Accessible and available: All you need to use Salesforce.com is a web browser and Internet access.
- It's accessible from anywhere
- It's secure
- It can talk to other modern applications
Deal with Change: Salesforce.com can easily change as you do
- Create new fields with no coding in a mater of minutes
- Add support for new ways of working at very low cost
Modern: Salesforce.com is cutting-edge software
- Connect your information to your website, email blasting, and other systems
- Connect your information to published data: address enhancement, legislative district lookup, etc.
- Updates just happen about four times a year without any work for the User

What are risks I should consider about using Salesforce.com?

Access to the system is donated:

It's like they're paying your rent--donation is only given for a 12 month period and is up for renewal every year
The company/foundation could go away, and end your donation. At this time this appears unlikely, but because they are donating a service rather than a piece of software, it's a real risk
They have your information on their servers, it's not on your computers
The USA PATRIOT Act forces them to comply with any legal government request to see your data, just like your ISP

What are the costs associated with using Salesforce.com?

Salesforce.com needs to be setup to get it to work right for you. This work is best done by a consultant familiar with Salesforce.com. Depending on complexity, the cost will range from a few thousand dollars, to tens of thousands. After that, your ongoing monthly cost to use Salesforce.com can be $0. You'll need someone to administer your Salesforce.com system after it's installed. This could be a user on your staff who is good with databases, or a dedicated IT person, depending on your needs.

Is Salesforce.com right for my organization?

Salesforce.com is a great database option that all organizations should consider because of the incredible benefits. We can help you decide if Salesforce.com is right for you. Drop us an email at consulting@onenw.org!

Tracking "Ladder of Engagement" Organizing With Salesforce

jon — 2008-03-04T22:09:17Z

Here at ONE/Northwest, we're keenly interested in helping environmental organizations use databases as powerful tools for grassroots organizing. We're trying to bake proven organizing strategies into database tools.

In this short article and the accompanying screencast, we'll demonstrate one example of this: how we're modeling a "ladder of engagement" in a Salesforce.com relationship management database.

The folks at Online Engagement, drawing on work by Steph Legault, summarize the concept of the Ladder of Engagement as follows:

The Ladder of Engagement sets out a simple scale for ranking different activities that online supporters may engage in. Low on the ladder are quick and easy items such as signing an online petition or forwarding an email to a friend. At the top of the ladder are the most involving forms of activism, including meeting with elected officials, organizing local actions, and making donations.

High Engagement

Recruit friends/family
Upgrade monthly donation
Signup for monthly giving
Renew single donation
Make single donation
Make a phone call
Write a letter
Attend a "real world" event
Sign petition
Viral / Tell a friend
Send an e-postcard
Subscribe to e-Alerts / Issue Alerts
Subscribe to eNewsletter
Enter a contest
Visit website

Low Engagement

Over time, an individual supporter would be expected to engage in a variety activities, both high and low on the ladder. The goal of an engagement strategy is not just get increased numbers of people involved, but also to encourage them to climb the ladder of engagement.

Here's an example of how Amnesty Canada used a ladder of engagement in a real-world campaign.

In other words, groups are communicating with their members and engaging them in the activities that affect policy decisions. Each action has an associated leadership value, and as a person completes more actions, their leadership score increases. Over time, you track people's progress up the ladder, and ask them to do more and more high-engagement actions.

Here's a short 5-minute screencast by Steve Andersen, ONE/Northwest's Database Program Manager, in which he demonstrates how to use Salesforce to model a ladder of engagement strategy:

Why this is interesting

A relationship management database that can track people through a ladder of engagement helps you create targeted prospect lists for people you might want to focus your limited outreach resources upon. For example, you can easily write queries that show you:

Everyone who took an action last year but hasn't taken one this year.
People who've taken multiple easy actions, but not yet taken a harder one.
All your members who haven't taken actions, and all your leaders who aren't members.
Everyone who's taken an action and is interested in a particular issue area.

While your organizers likely know all of your most engaged activists personally, and have a lot of information in their head about these folks, a database can helps you keep track of your "second tier" activists -- the folks you really want to develop into top-tier activists. These people are large in number, yet easy to lose track of because you don't see them as often.

Questions you should ask yourself

Do you know who your most active leaders are? Is that information recorded anywhere other than inside your organizers' heads?
Do you currently have the ability to target your outreach to people whom you know are likely to respond based on their past actions for you?
What are the 5-7 long-term issue areas or campaigns that you want to track activists' interest in over time?
What are the rungs in your ladder of engagement? Are you effectively moving people up that ladder?
The essence of effective organizing is person-to-person contact. But, are you capturing those "touches" in your long-term organizational memory so that can be continually building and deepening the relationship, rather than starting over from scratch again all the time?
How would your organization make the shift to a culture that, in the words of Steve Wright of the Salesforce.com Foundation, combines both passion and rigor. Are you recording your work in sufficient detail that you can analyze what's working, and what you need to do next?

Creating the Relationship-Centric Organization

jon — 2007-09-25T17:38:22Z

Our friend, colleague and fellow database consultant Paul Hagen has written an excellent piece for Idealware entitled "Creating the Relationship-Centric Organization." In it, Paul does a great job of explaining the conceptual leap from "donor databases" to "constituent relationship management" (CRM) -- thinking about ALL of the relationships your organization needs to track, manage and grow:

Every nonprofit manages relationships with constituents, whether through a sophisticated tool or through scraps of paper, Excel spreadsheets, and miscellaneous databases. However, managing through these informal and decentralized methods is inefficient if not downright chaotic.... Isolated silos of contact data means that supporters may only hear about one aspect of the organization – for instance, they may hear about fundraising needs but miss communications that would tell them about accomplishments or volunteer needs.

Poor management of constituent data translates to greater costs, lost revenue, and decreased impact.

Is your organization Relationship-Centric?
How well is your organization doing with its CRM strategy? Our sector divides into four categories on this critical measure:

Constituent Chaos. Some organizations have constituent data scattered everywhere. They have irregular, one-size-fits-all communications with supporters, and miss many opportunities to gain more value from constituents or grow relationships. These organizations can be described as being in a state of Constituent Chaos. They are underserving their organizations’ mission by failing to engage supporters more robustly.

Self-Centric. Self-Centric nonprofits have constituent data consolidated into one or only a few places (they are likely to be newer organizations with up-to-date systems), but focus their attention primarily inward rather than on interactions with the outside world. Like organizations in a state of constituent chaos, they do little to differentiate between their supporters and miss many opportunities to cross-promote different aspects of the organization.

Enlightened Stone-age. Enlightened Stone-age nonprofits appreciate and actively seek to engage their constituents with high quality interactions, but a multiplicity of data collection mechanisms requires staff to jump through hoops to coordinate outreach.

Relationship-Centric. The organizations that have contact data consolidated in only a few places, have regular targeted interactions with constituents in which they cross-promote different aspects of the organization and create opportunities to grow the value of their constituents are Relationship-Centric nonprofits. They maximize their relationships with supporters: they regularly increase the average donation size and effectively engage an increasingly wide swath of constituents to take actions to meet the organization’s goals.

If your organization is thinking about how to improve your database situation, Paul's article is a great background piece. The concepts he describes are at the heart of ONE/Northwest database consulting practice.

Read the whole article at:

http://www.idealware.org/articles/
relationship_centric_org_CRM.php

Donor Management Process Maps - Part 3: Donation Processing

steve — 2007-04-11T16:19:27Z

None of our processes up till now have handled real money. In this post we’ll look at what happens when the check comes in.

Processing money is where organizations start to differentiate their processes. For example, some groups have Memberships, where a donor gets an annual term and some level of member benefit. A key part of managing members is managing their expiration dates, and making sure memberships don’t lapse. Other groups just take donations that are generally on a yearly cycle–if a donor gives $100 in June 2005, it is considered a loss if their next gift doesn’t come in by June 2006 for at least $100.

This process map (Fig. 1.) starts with a check and the decision if the gift is a donation or a membership. Then we check to see if this is an expected payment (it’s already in the system) or one we weren’t anticipating.

Fig. 1. Processing the money when it comes in is where things start to get a bit complicated (PDF)

The gift then gets connected to an appeal, to help us determine the source of the money and also allow us to measure the return on those outreach efforts.

The last, and very important step, is to create a new gift 12 months out. This gift will be marked as “Prospecting” so we know it’s not a check that came in, but rather an opportunity for revenue in the future. By doing this, we’ll make sure not to lose track of this donor and their potential gift. And it will also inform our financial forecast for the next year. If you put all your potential gifts on the calendar, you can then see what your revenue picture will look like (Fig. 2.)

Fig 2. Some sample data representing all gifts for 2007. Red indicates gifts that have been received. Blue indicates gifts that have not yet been solidified.

As you might imagine, this can be very helpful in the budgeting process, and in dealing with cash flow issues. Most groups have their giving weighted heavily toward the final quarter of the year, as in this graph. By forecasting potential revenue, that picture becomes much clearer and can be managed more effectively.

Donor Management Process Maps - Part 1: Prospecting

steve — 2007-04-11T16:11:44Z

Adapted from a blog post by Steve Andersen.

ONE/Northwest has been helping nonprofits build databases for over a year now. During this time we have worked with about 10 organizations of various sizes–the largest being about 20 staff. A big part of our work is mapping out how these groups do fund development. Tracking donors, members, grants, and payments is a big part of what all nonprofits do. We sit down with each org and talk about how they raise money, so that we can understand the work in enough detail to be sure the database we build will support them in that work.

Turns out, these groups raise money in pretty similar ways. In this article, we share some process maps that describe donor management at these organizations. We’ll start with two maps that focus on taking a new donor prospect through the ask process. There are many other processes that go into managing donors, but we’ll start here.

These process maps aren’t about technology at all–they’re about work and how it gets done. We’re creating a snapshot of how orgs work, and who does that work. It’s not about Salesforce.com, or even about databases. All this work could be supported by post it notes and phone calls. Taking the technology out of the picture gets us to focus on the work, which is the real point.

OK, now some vocabulary about process maps. Circle is the starting point, rectangles are things that happen, diamonds are where decisions need to be made, rectangles with a wavy bottom are documents that fit into the process, and the last shape on this first page is a link to another page. Arrows show you the direction of the flow, which is generally left to right.

Activities are put in a “lane” for the person who is responsible for that work. On these maps you’ll see lanes for Donor Management and Solicitor–if things are happening in their lanes, those folks are the ones doing that work.

So let’s look at our first process map:

Fig 1. Process map taking a new donor prospect through the steps necessary to move them to an ask for money (PDF)

This first map (Fig. 1) starts with a new donor prospect dropping in our lap. We then bring in an outside solicitor (i.e. board member) if that makes sense. Some initial communications brief the prospect as much as necessary, leaning on key collateral that already exists. We can have as many informational touches as necessary before we hit the end of this map and head off to the ask, which is on the next page.

Fig. 2. Process map taking a new donor prospect through the ask process, getting them to a yes/no decision (PDF)

We start where we come in from the previous page. You’ll see that most of the activities in the ask process are in the center lane, which is whomever is leading the donation, either donor management staff or a solicitor. Sometimes the ask occurred early on (like if the prospect is the ED’s sister) otherwise we create a team of folks for the ask meeting, brief them, have the meeting, and thank the prospect. Then we act on the donation if they’ve pledged by recording it and looking into corporate matching opportunities. If they didn’t commit, did they say no or do they just need more info? We can have more meetings to get to a yes or a no. Then we’re done!

Checks sometimes are written at the ask meeting, but sometimes not. The next process in the flow deals with handling donations as they come in. We'll cover those in future articles.

Donor Management Process Maps - Part 2: Renewing Donors and Following Up On Open Pledges

steve — 2007-04-10T17:48:52Z

In part 1 of this series we showed processes for moving new donors through the ask process. In this post we’ll look at renewing major donors, and how to follow up on pledges that have been made by donors, but for which payment has not yet been received.

Fig. 1: Process for moving renewing major donors through to giving (PDF)

Dealing with renewing donors always starts in the database since renewing donors have already given to the organization (Fig. 1). Starting from a list of donors who are coming up on renewal data, the process is very similar to that for new donors. It is generally shorter, however, since these donors already know something about the organization. Solicitors can be involved, and the flow generally looks like the new donor flow.

Because these people have a deep relationship with the organization (deep enough that they have given money anyway) communication with the donor should be specifically tailored to that relationship, so the process captured is very generic. In this process, some groups I have worked with always ask for names of friends and relatives who might be interested. This is a great way to expand the social network of your supporters.

We end at the same place we ended before, with a donor committing to give, or choosing not to give.

If a new or recurring donor commits to give, we record the pledge as one of the last steps in the ask process. There is often a delay between the pledge being made and the payment coming in. This next process handles follow up on open pledges.

Fig. 2: Process for following up on pledges (PDF)

The donor management staff starts with a list of all recorded pledges that are approaching or past their donation date (Fig. 2). With each pledge, the decision has to be made if follow up at this time is called for. It’s a case-by-case decision that has tons of factors influencing it.

If the pledge is followed up on, gather the response from the donor and record any changes they’ve made to their pledge (payment date, amount, etc.)

Then the organization will go back to view unpaid pledges at some point in the future that makes sense for them. Any pledges that have been paid won’t be on the list any longer–they’re no longer outstanding. This review is ongoing.

In our next installment we’ll look at processing payments that come in. We’ll start with handling checks that come in the mail, then get more complicated, with handling online gifts that are made at an external system, as well as gifts that are broken into multiple payments.

High Engagement
		Recruit friends/family Upgrade monthly donation Signup for monthly giving Renew single donation Make single donation Make a phone call Write a letter Attend a "real world" event Sign petition Viral / Tell a friend Send an e-postcard Subscribe to e-Alerts / Issue Alerts Subscribe to eNewsletter Enter a contest Visit website
Low Engagement