In the elementary and secondary school I attended, there was a quote on the wall that has stuck with me: "Good, Better, Best: Never let it rest, until good becomes better and better becomes best." Looking at some of the best companies that made their name in recent years, their founders also set out to find a better way. They set some of the best examples of finding a better way. It is this drive to innovate that makes humans thrive.
Starbucks founder Howard Schulz outlines in his book that he wanted his customers to have 'a better coffee experience' in his stores, from the smell, to how the baristas make the drink in front of you. Even if today, with thousands of stores, the experience may not be as consistent, but the idea is there: a better way.
Netflix initially set out to find a better way than what Blockbuster had to offer. And then they offered a better way to delivery TV shows. I may not fully buy into the idea as they are totally dependent on bandwidth providers, but still, for some, it is a better alternative to traditional cable.
Tesla thinks that a bunch of heavy batteries is a better way. It may not work for some who can only afford one car that will serve both as a commuter and a long distance road trip vehicle. Or some may think that lugging around all that weight isn't really the best way. But still, until that next idea, Elon Musk thinks that he has a better alternative to the internal combustion engine.
Jeff Bezos knows that there's a better way to shop. And he thinks there is a better way to deliver products. And Whole Foods thinks there's a better way to buy groceries, and a better choice for what to eat.
Not everybody will agree with these companies that they are the best. That is why there is competition. The common thread is that each of these companies are finding better ways to do things. And that, to me, is a great thing. Always find a better way. There's got to be a better way.
Wednesday, February 26, 2014
Tuesday, February 18, 2014
Close Date?
To a sales user who has used Saleseforce or Siebel or SAP CRM for quite a while, the term 'Close Date' on an Opportunity is not new. But sometimes, to a person who does not encounter the term on a daily basis, the term is ambiguous.
So what is Close Date? If the opportunity is still open, or in play, or active, it is a future date, or it is the "Expected Close Date". And if the opportunity is already closed, it is the date when it was closed.
Depending on your sales process, it is usually when you receive the order from the customer, or when the order is booked in your order management application, or when the contract is signed. If it will be fulfilled through a third party reseller, it could be when the point-of-sale information comes through. That is, if you win the opportunity.
Salesforce.com does not automatically change the close date once an opportunity is closed. And that is where some of the reporting and dashboards become skewed. For example, a sales rep can reasonably expect something to close in January based on commitment from his customer. But situations change and he needs more wins in December to meet his quota. He convinces the customer to purchase in December and closes that opportunity early. If he is not diligent enough to update the Close Date, a regular Win report will show that opportunity as being won in January, not December.
Similarly, if a sales rep has an early stage opportunity that he expects to close in June, he will put a Close Date in June. And if after further qualification or further discussion in February, he clearly sees that his product cannot answer the customer's needs, so he marks it as Lost. That opportunity will be marked as Lost in June, not February.
If management is measuring Win/Loss ratio by quarter, then it may not be completely accurate if we rely on the standard Salesforce.com functionality.
It is relatively simple to update the Close Date when an opportunity is closed. Create a Workflow Rule that will fire when the criteria: Opportunity: Closed equals True.
And create a field update that will set the Opportunity Close Date to TODAY(). It is that simple.
Now, if for some reason, you want to keep what the rep originally entered, for example, to measure how accurate they predict the Close Date, you can instead update a read-only field called "Actual Close Date" to TODAY(). If you do measure accuracy of Close Date, you may still want to update the Close Date to today's date when an opportunity is Lost. Measure only the accuracy of Won opportunities. And of course, to see how far off the rep is, a formula that will subtract one from the other will be necessary. Depending on your business, it may be acceptable to be in the same month, or the same week, not necessarily accurate to the day.
As always, evaluate what makes sense for your organization.
So what is Close Date? If the opportunity is still open, or in play, or active, it is a future date, or it is the "Expected Close Date". And if the opportunity is already closed, it is the date when it was closed.
Depending on your sales process, it is usually when you receive the order from the customer, or when the order is booked in your order management application, or when the contract is signed. If it will be fulfilled through a third party reseller, it could be when the point-of-sale information comes through. That is, if you win the opportunity.
Salesforce.com does not automatically change the close date once an opportunity is closed. And that is where some of the reporting and dashboards become skewed. For example, a sales rep can reasonably expect something to close in January based on commitment from his customer. But situations change and he needs more wins in December to meet his quota. He convinces the customer to purchase in December and closes that opportunity early. If he is not diligent enough to update the Close Date, a regular Win report will show that opportunity as being won in January, not December.
Similarly, if a sales rep has an early stage opportunity that he expects to close in June, he will put a Close Date in June. And if after further qualification or further discussion in February, he clearly sees that his product cannot answer the customer's needs, so he marks it as Lost. That opportunity will be marked as Lost in June, not February.
If management is measuring Win/Loss ratio by quarter, then it may not be completely accurate if we rely on the standard Salesforce.com functionality.
It is relatively simple to update the Close Date when an opportunity is closed. Create a Workflow Rule that will fire when the criteria: Opportunity: Closed equals True.
And create a field update that will set the Opportunity Close Date to TODAY(). It is that simple.
Now, if for some reason, you want to keep what the rep originally entered, for example, to measure how accurate they predict the Close Date, you can instead update a read-only field called "Actual Close Date" to TODAY(). If you do measure accuracy of Close Date, you may still want to update the Close Date to today's date when an opportunity is Lost. Measure only the accuracy of Won opportunities. And of course, to see how far off the rep is, a formula that will subtract one from the other will be necessary. Depending on your business, it may be acceptable to be in the same month, or the same week, not necessarily accurate to the day.
As always, evaluate what makes sense for your organization.
Thursday, February 13, 2014
My, How Far We Have Come
In the early days of CRM and Salesforce Automation (hey, we didn't even call it that), we equipped our field agents with laptops and a printer. That proved to be too heavy, but the idea was that they were mobile enough to do everything they needed to close a sale.
The early adopters were our top sales teams who had the most experience. Translation: they were twice my age at least. The first day of classes was basics of computers, and in later courses, included typing!
That was in 1995.
The Toshiba Satellite T2400 had a really small screen. So screen real-estate was at a premium. We had to be creative in screen design and overall user experience (the term was not widely used then). Now, back on mobile devices, screen real estate is again at a premium.
The next year, I was speaking to a field operations executive from the local licensed Coca-Cola bottler, and we were talking about enabling their field representatives (who rode on their trucks) to do everything they needed on a laptop, and connect at the end of the day to upload everything. I never followed up on that lead, but at the end of the conversation the hesitation was the cost of the laptops (they had to be the rugged kind from Panasonic at that time), and having to connect at the end of their shift via dial-up.
Now, the idea is no longer outside the realm of possibility. Connectivity is instant. There is no need for an end-of-day synch. And there is no need for an actual laptop. The tablet has replaced the laptop as the mobile device of choice for field work. That same problem could be solved in a few months if not several weeks.
In 1999, we were experimenting with WAP apps (Wireless Application Protocol) for field reps and customers to access their customer and product information and make payments. Unfortunately the screens severely hampered the user experience, and the connectivity was spotty at best.
Up until 2009, I have had users clamoring for a mobile offline version of their CRM. They say they could be on a plane or on a train, and there is no connectivity. They have to be able to work offline and synch back up once they are in the office.
Fast forward five years and many carriers now offer Wi-Fi on board, and if they didn't, your phone will most likely have a signal and a data connection. And bandwidth is far cheaper than what it was then.
What you give up in computing power, you make up with the mobility, the ease of use. And you can always perform server-side heavy computing, much like the old days of mainframes and thin-client architectures. So a lot has changed, but some things remain the same.
Apps used by field sales are no longer designed with a desktop or laptop user in mind, now they are mobile-friendly first, or at least, considered at the same time as their PC counterparts. But mobile devices don't have a lot of storage, much like the old days of PC computing. So the same principles around efficiency that applied then still apply now.
I can hardly believe it has been less than twenty years. And yet, the technological evolution is outstanding. I'm sure that it will only get better from here. I've posted somewhere before about software programming, "The language may change, but the logic remains the same." In the same manner, the technology may change, but some basic principles will not.
The main thing that still holds true today for CRM and SFA, or any app that you expect a sales person to use, is from one of my early users who took time to write me a letter (on paper) in 1996. He was a seasoned sales rep and managed a large sales team in a regional office. Referring to one module in our app, he said, "This requires a PhD in Computer Science. I cannot use this. Keep it simple!"
The early adopters were our top sales teams who had the most experience. Translation: they were twice my age at least. The first day of classes was basics of computers, and in later courses, included typing!
That was in 1995.
The Toshiba Satellite T2400 had a really small screen. So screen real-estate was at a premium. We had to be creative in screen design and overall user experience (the term was not widely used then). Now, back on mobile devices, screen real estate is again at a premium.
The next year, I was speaking to a field operations executive from the local licensed Coca-Cola bottler, and we were talking about enabling their field representatives (who rode on their trucks) to do everything they needed on a laptop, and connect at the end of the day to upload everything. I never followed up on that lead, but at the end of the conversation the hesitation was the cost of the laptops (they had to be the rugged kind from Panasonic at that time), and having to connect at the end of their shift via dial-up.
Now, the idea is no longer outside the realm of possibility. Connectivity is instant. There is no need for an end-of-day synch. And there is no need for an actual laptop. The tablet has replaced the laptop as the mobile device of choice for field work. That same problem could be solved in a few months if not several weeks.
In 1999, we were experimenting with WAP apps (Wireless Application Protocol) for field reps and customers to access their customer and product information and make payments. Unfortunately the screens severely hampered the user experience, and the connectivity was spotty at best.
Up until 2009, I have had users clamoring for a mobile offline version of their CRM. They say they could be on a plane or on a train, and there is no connectivity. They have to be able to work offline and synch back up once they are in the office.
Fast forward five years and many carriers now offer Wi-Fi on board, and if they didn't, your phone will most likely have a signal and a data connection. And bandwidth is far cheaper than what it was then.
What you give up in computing power, you make up with the mobility, the ease of use. And you can always perform server-side heavy computing, much like the old days of mainframes and thin-client architectures. So a lot has changed, but some things remain the same.
Apps used by field sales are no longer designed with a desktop or laptop user in mind, now they are mobile-friendly first, or at least, considered at the same time as their PC counterparts. But mobile devices don't have a lot of storage, much like the old days of PC computing. So the same principles around efficiency that applied then still apply now.
I can hardly believe it has been less than twenty years. And yet, the technological evolution is outstanding. I'm sure that it will only get better from here. I've posted somewhere before about software programming, "The language may change, but the logic remains the same." In the same manner, the technology may change, but some basic principles will not.
The main thing that still holds true today for CRM and SFA, or any app that you expect a sales person to use, is from one of my early users who took time to write me a letter (on paper) in 1996. He was a seasoned sales rep and managed a large sales team in a regional office. Referring to one module in our app, he said, "This requires a PhD in Computer Science. I cannot use this. Keep it simple!"
Saturday, February 8, 2014
Salesforce's New Report Folder Sharing
If you haven't enabled Salesforce's new Report Folder Sharing feature (Setup | Reports & Dashboards | Folder Sharing), here are some things to consider before doing so.
The biggest advantage is having more granular control of report sharing permissions. For example, you can delegate users as managers of a folder without having to give them "Manage public reports" permission on their profile. And then the rest can be viewers.
In the past, you set the folder to "Read Only" or "Read and Write", and that dictates what every user can do on that folder. Only users with the "Manage public reports" permission can write to folders that were generally Read Only. Even if a user's access was "Read and Write", without the "Manage public reports" permission, they cannot overwrite their old reports. They had to save a new version and ask an admin or someone with that permission to delete the old reports.
Once the new Folder Sharing is enabled, the interface for setting permissions changes. Before, you click "Edit" on the folder and at the bottom, pick groups, roles, or just all users (include or exclude portal users).
With the new folder sharing, there's a "Share" menu option when clicking on the folder, and a popup allows you to pick users, groups, roles, roles and subordinates, and then select a permission: Manager, Editor, Viewer. (Details on each permission can be found here.)
Now on to the biggest disadvantage: In the past, if you had a folder that was shared to "All Users", i.e. the first two radio buttons above, when you schedule a report to be emailed, you can pick specific users from the list without doing anything else.
But with the new feature enabled, there is an extra step, even if the folder is shared to All Internal Users or All Users. First you have to share the folder to those specific users. Or create a public group with all of the users who need to receive the emailed report, then share the folder with that public group.
Only then will you be able to select those users or that public group as recipients of the report.
Note that previously scheduled reports will not be affected. But for new scheduled reports, the step above is necessary. I received so many calls about it, I even raised a ticket with Salesforce Support, and they said it is a "feature", not a bug.
Thanks for reading!
The biggest advantage is having more granular control of report sharing permissions. For example, you can delegate users as managers of a folder without having to give them "Manage public reports" permission on their profile. And then the rest can be viewers.
In the past, you set the folder to "Read Only" or "Read and Write", and that dictates what every user can do on that folder. Only users with the "Manage public reports" permission can write to folders that were generally Read Only. Even if a user's access was "Read and Write", without the "Manage public reports" permission, they cannot overwrite their old reports. They had to save a new version and ask an admin or someone with that permission to delete the old reports.
Once the new Folder Sharing is enabled, the interface for setting permissions changes. Before, you click "Edit" on the folder and at the bottom, pick groups, roles, or just all users (include or exclude portal users).
With the new folder sharing, there's a "Share" menu option when clicking on the folder, and a popup allows you to pick users, groups, roles, roles and subordinates, and then select a permission: Manager, Editor, Viewer. (Details on each permission can be found here.)
Now on to the biggest disadvantage: In the past, if you had a folder that was shared to "All Users", i.e. the first two radio buttons above, when you schedule a report to be emailed, you can pick specific users from the list without doing anything else.
But with the new feature enabled, there is an extra step, even if the folder is shared to All Internal Users or All Users. First you have to share the folder to those specific users. Or create a public group with all of the users who need to receive the emailed report, then share the folder with that public group.
Only then will you be able to select those users or that public group as recipients of the report.
Note that previously scheduled reports will not be affected. But for new scheduled reports, the step above is necessary. I received so many calls about it, I even raised a ticket with Salesforce Support, and they said it is a "feature", not a bug.
Thanks for reading!
Subscribe to:
Posts (Atom)