Why Adding a Field Isn’t Always that Simple & The 5 W’s of Salesforce Administration

I know what you’re thinking. You’re reading the title saying to yourself “C’mon Cheryl, yes it is, in just a few clicks I can add a field. What are you talking about?” In theory, yes, you are correct. However, I wanted to share an example from a recent User Group Meeting that may not be so simple. One of our new members--who is also a new admin--was asking for help adding a field. The admin’s sales team requested a field called Billing Frequency on the Opportunity with 4 Choices: Annually, Quarterly, Monthly and Ad Hoc.

After discussing the request with her it became apparent the technology wasn’t the problem, it was the requirement itself. She showed me their org. They had three opportunity record types with three page layouts and nine profiles. She wasn’t sure which opportunity record type this field should be on, where it should go on the page layout, or who should have access. We looked at the record types and page layouts and we could make an assumption, but we all know what happens when you assume…

I explained that she needed to refine the requirement for the field with the sales team. I helped her draft an email asking everything she needed to know to a new field. She sent the email while still at the user group meeting and approached me after one of the presentations as the sales manager had already responded. It turned out the field should only be on two of the three record types, it should always be required for one of the opportunity record types when it’s closed won, and should only be required for a certain opportunity type when it’s closed won. There was also a requirement that only sales and sales management should be able to change this field, and all other users would have read only access to the field.

The sales manager also asked if he could get an email anytime an opportunity was closed with a Billing Frequency of Ad Hoc. He also asked if there was a way she could load the data in for any closed opportunities from 2015 for one of the record types.

After reading through her email with her the simple additional field requirement became:

· Add a field to two record types and page layouts

· Set up field level security for the field

· Create a validation rule to require the field in the certain circumstances

· Create a workflow rule and email template to fire when an opportunity was closed where this field was filled in with a certain value.

· Extract opportunities with criteria mentioned in above validation rule with ID’s so sales could update spreadsheet

· Load data into the Billing Frequency Field


From the above you can see why adding a field can be more than a simple request, especially if you are adding a field to an object with multiple record types, page layouts, with multiple profiles. This is why I always use the 5 W’s of Salesforce Administration when reviewing enhancement requests from users:



· Who - Who wants the request, who should be able to use or view the new configuration.

· What - What will they do with the data collected in the configuration? What is the long-term goal?

· Where - Where should this configuration be available?

· When - When should this configuration be available, when should it be required?

· Why - Why do they want this new feature, what is their end goal and how will they use it and how will it benefit our business?


When the admin I mentioned above started asking her business users the 5 W’s of Salesforce Configuration, she was able to assist them faster and more efficiently. She was able to determine what was needed upfront by asking the right questions.

What questions do you ask your business users when they submit a request to make a change in Salesforce? I would love to hear from you!

As always, thank you for reading!

Cheryl

How to SABWA When You're Not in the Same Location as Your Users

If you’ve heard Mike Gerholdt speak then you’ve heard him speak about SABWA, Salesforce Administration By Walking Around. I love this practice, but it got me thinking what if users aren’t in a location that’s in walking distance to you or what if you are a Salesforce Admin that works from home? Can you implement this practice? The answer is YES! I know this because I have done it and wanted to share a few tips. Over the past 11 years I have supported Salesforce end users in all 50 states and in over 30 countries. It’s so important as a Salesforce Admin to maintain a connection with your end users regardless of location and time zone, which is why being a SABWA admin, is such a great practice.

It is going to be even more important for us as Awesome Admins to SABWA as we start rolling out the new Lightning Experience to make sure we do this to make sure the new UI is working for our users and they know how to use it and know where to go to get their questions answered.

Here are some practices I have implemented to interact and connect with users not in the same location as me:


Hold Office Hours with a Tool that Allows for Screen Sharing and Video

I supported users in the Americas, EMEA and APAC it was sometimes really hard to support users in the other regions due to time zones, however I didn’t want the users in other time zones to feel left out so I setup weekly Office Hours meetings where the time rotated each week. For example the first Friday of every month office hours were held at 10 AM EST, the second Friday of every month Office Hours were held at 1 PM EST, Third at 4 PM EST and Fourth at 9 PM EST. Having the meeting at different times allowed users from all regions to be able to join easily.

I got to know so many users in so many different countries this way. I also always made sure to use video on my meetings so the users could put a face to the voice. It made it almost like I was there in their office helping them but I was in my office in New York City and even sometimes in my apartment.



Join Departmental Meetings

Pretty much every department has weekly or monthly meetings; so ask to join, even if it’s just to listen. It was great to understand what different departments were doing overall not just with Salesforce so I could keep that in mind when writing requirements or designing solutions. I was once on the Order Management and Finance Monthly Meeting and they were discussing how Order Management reps needed to manually enter some new information from the billing system on the Sales Order after they finished processing it. I heard some grumbling on the call about how manual it was going to be. I made a note to myself to talk to our integration developer about bringing this information over via our already existing integration between sales orders and our billing system. After discussing with our integration developer, we found that the data they were going to manually enter after completing a sales order was in a table we were already were connected to and we would just need to add fields to Salesforce and to the integration to bring them over, the estimate was less than a day of development work. Everyone including my VP and our Product Owner saw the value immediately and we put the story in the next sprint to get the integration updated.

I immediately called the business leads in finance and order management to let them know we could automate this data entry and we were going to put the story for the enhancement in the following sprint. They were so thrilled that this could be done. They didn’t think it could be, but they were very happy they were wrong. It was a great feeling to come to their next meeting and announce that they no longer had to enter the information manually that we were able to add this feature for them and save them about 1.5 minutes per order which would save order management about 300 minutes per week. This meant orders were being billed and fulfilled that much faster for our customers.

Random Calls to End Users

I regularly spoke to our product owner and business leads as part of our change management & agile processes, but sometimes even our business leads weren’t aware of issues or challenges with end users. I would block out an hour in my calendar every Wednesday and call 3-4 users randomly. It was a great way to get to know people and listen to their challenges. I can’t tell you how many times I would call an end user and because so much of the business was using Salesforce for their processes they would give me feedback I never even thought of. 

 I once called a Sales Rep that was frustrated that they didn’t have a clickable link to another system like they did for other systems which passed the account name so they didn’t have to copy paste or manually type, it would bring up the correct record(s) in the other system so they could easily find what they were looking for. I had no idea sales was even relying so heavily on this other system. When I reviewed this request during our Change Advisory Board meeting everyone realized how much time that could save sales. We had the new custom link out to the business users the following day.


Send Surveys

Many of us manage survey tools such as Get Feedback, Form Assembly or Clicktools within our Salesforce org to send to customers as part of the customer service process, but what about end users? This was a great way to get feedback from end users. We allowed the surveys to be anonymous if they chose, however, we required them to tell us what type of user they were so we could group the feedback by Sales, Marketing, Customer Service, Legal, Sales Ops or Finance & Order Management.

We sent these out every other month to all of our end users and included a link to a survey form when we closed out cases so they could give us feedback on a particular issue or about anything in general.

Many features added to our backlog were because of these surveys. These surveys really showed our end users that we were listening. It was great to send our weekly release email and highlight the items that we released that were ideas from our end users.

I hope this helps some Awesome Admins out there who work remotely or sit in different offices from your end users that you can still SABWA without actually walking around. I would love to hear from you if you have implemented some things to work with end users you may not sit near.


As always, thank you for reading and I hope to see some of you at the Salesforce Tour in NYC on November 18th!


All the best!



Cheryl

Falling in Love...With Service Cloud

I fell in love with Salesforce Service Cloud nearly a decade ago in 2006. I was working at a startup managing an org as a Solo Admin with around 50 users, which were mostly from Sales and Marketing. There were a few departments within customer support: Service Center, Field Service and Engineering. Each of these departments had a shared Salesforce license they could use to login to see what the customer purchased or where they were in the sales process. However, these shared licenses only gave them read only access.

The Service Center Team sat in the office answering customer calls and emails. The Service Center was also responsible for handling escalated issues, meaning if they couldn’t resolve an issue through the phone or email and it needed to be escalated, they would make sure the question or issue was being resolved in a timely manner by Field Service or Engineering. Everything they were doing was tracked in spreadsheets or emails.

The Field Service Team was out in the field servicing our customers on site. The service visits were both routine visits and from service calls. Everything this team did was tracked in a separate set of spreadsheets. These also weren’t real-time so we had instances where two field service members would end up on the same property in the same day because data was only getting updated once a day.

My first few months at this startup company were really spent getting the Sales and Marketing teams up and running on Salesforce. I had to do major cleanup of roles, profiles, fields, objects and data. I also rebuilt all of their reports and dashboards and helped them define KPI’s. It was around that time that the company moved into a bigger office. Up until that time Sales and Marketing sat in one office and Customer Support and Engineering sat in another.

When we moved into our new office we were put into quads of desks. My quad mates were the Service Center Manager, the Field Service Manager and the Accounting Manager. On the third day of being in our new office, I walked into what seemed to be Customer Service chaos. Everyone seemed to be running around and upset. When I asked what was going on, I was told that the master spreadsheets that were saved on the shared drive with customer visit and call information had been corrupted. They had a few local saved versions, but they were a few days old, so they were trying to piece the data back together. The information contained in these spreadsheets contained critical data for these teams that tracked who had an open issue, who was attending to it and when a customer last had a service visit.

I offered up my services to help restore the data in the sheets based on emails and notes. As I was looking at the data in the spreadsheets something clicked in my head. This information belonged in Salesforce. These teams were working with the same customer data as Sales. Why should customer data be in all these separate places? I remembered something I heard about at a Salesforce event that finally made sense to me at that very moment, “A 360-degree View of Your Customers.” That is exactly what we needed to have and I was determined how to figure out how to use Salesforce to give us that 360-degree view.

Later that day as most of the chaos settled I started to do a bit of research on how customer service used Salesforce. I found some really good articles on the help section from Salesforce about Cases, Web to Case and a brand new feature called Email-to-Case. I had never used Cases before, but I thought, what the heck, why not try it out and see what the data would look like with a few of our customers.

I looked at the spreadsheet and configured their process right into cases. I was excited to see that cases operated like Leads, Accounts, Contacts, and Opportunities, which were the objects I was most familiar with at that time. I could add fields; have page layouts and record types. In a few hours I had a working prototype of what I thought would be a good solution for the Service Center team. I loaded cases from a few of the customers that called in frequently to see what the data looked like. I created a couple of reports so I could show them how they could look at the cases in a detail view or at a high level through a metric.

A few days later, when things seemed to be a bit calmer I approached the Service Center Manager and asked if I could show her something in Salesforce. I showed her what I built out with cases and explained the idea of web to case and email to case. I also showed her some documentation about CTI systems, Self-Service Portals and connecting Salesforce to them. The Service Center Manager loved everything I showed her. We spent an hour or two each day over the next week perfecting what I had built and showing a few other people on the team.

Since the Service Center Team was using a shared license that only had read only rights we needed to purchase 15 licenses to fully get them on board. Our plan was to build something out and “wow” the management team so they would sign off on this expense.

The following week, I sat with the Service Center Team manager in the CEO’s office along with the COO explaining to them everything we built and our proposed plan. Phase I was going to be getting cases up and running, a data migration of existing calls, setup of web to case and email to case. Phase II was going to be creating an escalation process and bringing on Field Service and Engineering Teams. Phase III was to look at doing a self-service portal and CTI integration. The CEO and COO loved everything we built so far and our phased project plan. We got sign off on the additional licenses for Phase I and Phases II and III would be put in the budget for the following year.

Building out Phase I took about two weeks including the data load. It was really exciting to see Service Center Team members entering cases while they were on the phone as well having the ability to see if a customer had any open cases with us right when they called. No guessing, no searching multiple spreadsheets. Everything was right there for them on the screen in Salesforce.

The changes we made for the Service Center also ended up having a very positive impact on Sales. In the past, Sales Reps would sit with Service Center Team members to understand if any of their clients were calling in or if any had issues that were up for renewal or a good candidate for a new product or upsell. Sales no longer had to do that. They had the information at their fingertips. It was immediately apparent to everyone in the company how efficient Salesforce was making our Service Center Team.

A few weeks after our go-live with Phase I, the CEO and COO met with me and told me to go ahead and purchase additional licenses for Field Service and Engineering and start work on Phase II and they would see about getting budget for a portal as well as a CTI phone system for Phase III. Phase I had proven to them that the spend now would save money in the long run due to the efficiency it brought the teams supporting our existing and expanding customer base.

It took just another few weeks to have Phase II rolled out which allowed us to have escalation process right on Salesforce as well as gave a unified system where Marketing, Sales, Service Center, Field Service, and Engineering were looking at the same customer data. It was an incredible experience for me to see the value of my work right in front of me.

About a month after we went live with all of the service teams on Salesforce we started building out monthly and weekly metrics. I used to do all of the reporting for the company so I knew that the average “Time to Solve” for Service Center was just over 2 business days. After having these teams on Salesforce for just over a month it was brought down to less than a day. The average “Time to Solve” was 6 hours, I did the numbers three different times, just to make sure. When I clicked “Run Report” and saw those numbers, that’s when I knew, I was in love. I had become the biggest fan of what was known in 2006 as “Salesforce for Service & Support”, now known as the very robust Service Cloud. The amount of efficiency I could bring to end-users was nothing short of incredible. Not only did I become a fan, so did my end-users. The customer service teams loved Salesforce and actually helped me get to my first Dreamforce in 2006, but that is a story for another day.

Eventually my career grew and a few years later I was bringing thousands of customer service users onto Salesforce at a billion dollar financial services firm, building out self service using portals and communities, integrating with entitlements systems and lots of other fun complexity. My favorite projects over the past 11 years of working on the Salesforce platform mostly involve Service Cloud.

I even rolled out Service Cloud for a team I was managing a few years ago where we were managing thousands of Salesforce Users. We used it to manage requests and our internal escalation process. Service Cloud can bring efficiency to teams doing any kind of support work, not just customer service.

Now, a question for you, the reader, when did you fall in love with Service Cloud? I would love to hear your story.

As always, thank you for reading. See you all at Dreamforce!!

My Awesome Admin Heart

My Awesome Admin Heart

This was originally posted on my Facebook last month while I was expressing some random thoughts. Some friends encouraged me to turn this into a blog post, I hope you like it.


I will forever and always be a Salesforce Admin. I do not care how far I move up in the world, my heart and soul will forever be with the awesome admin community.

I have been that person spending my Friday night figuring out a formula or validation rule that just was not working. Then, I was that person jumping for joy at my parents’ house, my apartment or even at my desk when I finally got my formula or validation rule to work!

I have been that person on the phone with end users at 9 PM helping them through a problem. Then, I was that person tearing up at my desk reading a thank you card from the user I helped. I not only helped them, I taught them.

I have been that person cleaning up data; making it pretty and designing validation rules to make it useful. Then, I was that person presenting my efforts in front of executives, getting nods and smiles for my dedication to clean data.

I have been that person almost in tears heading to a user group because I had a boss that was screaming at me to do something that I didn't know how to do; walking out of the meeting with renewed hope when someone helped me. Then, I was that person moving onto a job where I was appreciated for the knowledge I gained within the community.

I have been that person who built an amazing solution in an afternoon in the best platform in the world wowing end users. Then, I was that person that realized Salesforce was the only platform I ever wanted to work on.

I have been that person accepting an award from business users for my design and implementation of a large-scale solution. Then, I was that person presenting an award to others who have built even better solutions.

I have been the person who was yelled at when something I built didn't work as expected (oops should have tested it in sandbox first). Then, I was the person that learned from my mistakes and implemented a better process, admitting that I could have done better.

I have been that person taking a phone call from another admin in my local community helping them sort through a formula field they could not build. Then, I was that person who realized that serving those in my local Salesforce community was my calling and my duty.

I have been that person wiping away tears of a new admin at a user group who had Salesforce thrown upon them not knowing what to do next. Then, I was that person who realized I could help these new and next generation admins by sharing my knowledge and things I have learned over the past decade.

I have been that person who planned my whole weekend around a Salesforce release going live in sandboxes so I could play with the new features. Then, I was that person who found the Salesforce community on Twitter, realizing I was not alone in my plans.

I have been that person who begged my manager to send me to Dreamforce. Then, I was that person who brought back so many ideas that my boss became so excited about Dreamforce he allocated budget for both of us to attend the following year.

I have been that person who helped another admin just because. Then, I was that person that told them to pay it forward.

I have been that person who shook in fright before presenting at a user group meeting for the first time. Then, I was that person being asked to interview for positions solely based on my presentations at user groups.

I have been that person who realized that presenting at a user group was not so bad, so I decided to lead one. Then, I was that person who decided to lead three.

Through the good the bad and the ugly I have been a Salesforce Admin. Forever and always an Awesome Admin.


Thank you for reading.

Cheryl

PS - Here are my upcoming speaking engagements:

4/16 - 9:00 AM - NYC Salesforce.com User Group - Process Builder and other Awesome Admin Tools

4/23 - Salesforce World Tour Chicago - You can find me in the Admin Zone 

4/30 - 6:30 PM -  Financial Services Salesforce.com User Group - Householding/Spring '15 Features