Opportunities Will Really Matter

In Contact we have Opportunities and we'll have them in Salesforce, too. I have a feeling, though, that many people will find they matter a lot more in Salesforce than they did in Contact.

Why? Well, because in Salesforce Opportunities are the ONLY way to forecast. There is no such thing as the 3 month forecast form we have now, where you write 3 numbers -- how much this month, how much next month & the month after. With Salesforce, those 3 numbers will be computed mathematically from the Opportunities.

We decide what Opportunity amounts to include in those 3 numbers, and that's a topic we'll be discussing as we prepare Salesforce for roll-out and, I imagine, re-discussing as we begin using it. There will be several stages of an Opportunity and we will determine what Opportunities in which stages will we include or exclude from our Forecasts.

The stages, at least at this point, are:

1. Prospect
2. Qualify
3. Cover the Bases
4. Expecting to Close
5. Closed Won
6. Closed Lost

I expect that we will include the Opportunities in stages 4 and 5, those that we're expecting to close and that have closed -- and been won.

How does that sound to those of you who forecast now? Do you feel you'll be able to create Opportunities and manage the stages with this type of logic?

For sales reps, the Opportunities also play into the Focus Four form and discussions you have with your managers. I plan to design a dashboard in Salesforce that will show the opportunities in the Focus Four quadrants so that you don't need to create the Opportunity in Salesforce and turn around and write it again on a Focus Four form.

Using the Opportunities in this way will fit into one of the goals set by the sales department, to have a better, more detailed view of what is in the "funnel" (the opportunities out a ways, waiting to be funneled into real sales).

Location, location, location

I promised to write about some of my customization plans in Salesforce.com. One of them is regarding locations.

In Dexter, as you know if you use Dexter, you can pick a billing location from Contact and a jobsite or shipping location from the Sites database. There are times when that scheme doesn't work so well. If a client has several billing locations, you have to create the company several times in Contact. And then when you're making Contacts you have to decide, which Company will I put this Contact under? Sometimes you might have to decide to put the same contact under two companies. Not good!!

In Khameleon, it's set up that every company can have as many locations as needed, and they can all be under the same company. One issue in Contact, though, at least as I understand it, is that if you need to put in a different "Attn to" name, you end up having to create a new location for each "Attn to" name. Not good!!

I'm hoping to avoid those issues in Salesforce by having one Company -- in Salesforce they're called Accounts -- and a custom object called "Locations". You will be able to create as many Locations for each Account as needed, and then you will be able to choose whichever location you want in the Projects you create (another custom object I'm creating in Saleforce, more on that later). And you'll create all your Contacts under the one Account, and, again, be able to choose whichever Contact you want, wherever you want, on the Project.

In my current plan, I'm keeping the Account object (in Salesforce there are "objects" rather than forms) very simple, not even requiring an address. That way you won't have to create an Account, put all the address info in, and then have to create a Location and put that same address info in there. When you create a Contact, you'll have the option to associate him/her with Location(s) but it won't be required.

Sound good?

One concern I have, though, is whether at any point we'll wish we had the address information in the Account. What if we're looking at a report or dashboard of a bunch of Accounts and we wonder where they are? Should I require putting in the city and state at least? But what about when there are billing addresses in several cities & states? Would it be okay if you had to pick one "best" city and state for each account, probably the headquarter's? Would you resent having to put the city and state in on the Account object, and then still having to create the Location and put that same city and state in again??

Such deep, philosophical questions!

Next I'll talk about one of the biggest changes -- for some of you -- in Salesforce: Opportunities. No more 3 Month Forecast forms, only Opportunities. Change is a-comin'.

I've looked at clouds...

I sent out an email a while back saying "Pivot's moving to the cloud!"

I like this cloud computing stuff. My use of it started with my work at my church. (On Fridays I work as a "techie" for my church. When I found out that you could get Google Apps for free if you're a non-profit, I immediately thought that'd be perfect for a church -- no servers to maintain, no worries about the fact that the minister and the youth leader have Macs while the rest of us has PCs, no back-ups. Sounded great. And it has been good for us. I wrote an article about it for a networking website I use.

Here at Pivot, our first foray into the cloud is with Salesforce.com. I'm glad that Pivot is moving to this technology and also personally happy that I get to learn more about Salesforce.com.

Why do I think it's a good thing to move to the cloud, you ask? Well, since you ask, I'll tell you. Personally, I have always preferred the software side of IT over the hardware. I enjoy making databases work, creating processes through technology, getting feedback from users on what helps them work better and implementing that through software. I'd do those kinds of things all day rather than update or build servers, take apart computers, hook up monitors and cables, blah, blah, blah. I know some people tend to think of IT people in a similar way as mechanics, but that mechanical side of things is what I have to do, rather than what I really like to do.

Cloud computing, therefore, is right up my alley. There is no hardware. Well, there's no software, either. In fact, Salesforce.com's tag line is "no software", as in the image at the beginning of this post. But, even though there's no software to install, it functions like software, except through a browser. The fun part of Salesforce.com for me is the designing part. I can create custom fields and objects, arrange them in the way that makes the most sense, and also do more advanced things such as creating work flows and automated tasks (which I still need to learn how to do).

Salesforce.com, like Google, also offers their product to non-profits for free so I began using it when I got it for my church. One thing that impressed me greatly is the way I could do so much customization, yet not "break" it. You know how Khameleon has a bunch of Herman Miller customizations, and because of that when Khameleon is updated, we lag quite far behind because they have to do a bunch of testing to make sure the HMI customizations will work with the new software upgrades? With Salesforce.com, they've done a great job of making it so that the customizations continue to work even as they're adding new features all the time.

In my next blog, I'll talk about some of the customizations I'm working on in Salesforce.com for Pivot. I'll be interested to hear what you think of my plans.