Rarely do you take a cloud-based SaaS application and use it without making some kind of design changes to meet the needs of the end-users. The challenge is making the customizations your user needs, without going too far and defeating the intent and purpose of the application. This project called for me to create a design solution within Salesforce.com (SFDC), apply targeted customizations to achieve our goals, while still maintaining the intent of the application.
 
 
SFDC comes “pre-packaged” with functionality to manage the sales cycle, and is used by many companies for their sales teams to track leads, prospects, and all activities leading up to closing the sale. It can also be used to track and maintain customer services “post” customer acquisition. A hotel franchising company I worked for used the system to track franchise leads and prospects– and it worked well. They absolutely loved this system. However, there was a need to take things up a notch. This hotel company wanted to use SFDC to track and monitor the various services provided to each hotel after the franchise agreement had been finalized.
 
 
The challenge we faced was there were no “customers” (hotels) in Salesforce – only franchise sales leads and prospects. After the franchise agreement was finalized, all the Franchise Terms, Conditions, Ownership, Location, Billing, Quality Scores, Operational Statistics, etc. about the new hotel were input into different systems – Oracle, Steton, etc. Unfortunately, the other systems didn’t have the features and functionality to allow for good service management…and that was Salesforce’s sweet spot. So how could we get the rich information these other systems had and combine that with the customer relationship management features of Salesforce?
 
 
I was asked to look at Salesforce and come up with some design options that could work. Immediately I knew the only way to do what this hotel franchising company wanted was to customize parts of the system. However, it was important to maintain much of the existing functionality inherent to the system. As a result, we decided to build several new “custom objects”, all of which nicely complemented the native functionality of Salesforce.
 
 
The first custom object I suggested we create was called “Properties”. For every hotel in this company’s portfolio, we wanted a Salesforce “property record” created. We decided to keep Oracle as the system of record for franchise agreements and have this data fed over nightly to populate each “property record” in Salesforce. We did this to ensure the final agreement terms, operational status (open vs. closed), ownership info, locations, operational statistics, etc. remained in possession of those who owned the data. In this case, the service organizations were only consumers of this data.
&nbsp
 
This nightly feed refreshed every property record in Salesforce with all the latest information from finance as well as contract administration. This feed also ensured that when new properties were opened, a new property record was auto-created in Salesforce. This nightly update kept the service organizations in sync with the contracts team and that everyone was operating off of the same information. Within this new custom object, we also “tagged” each record with their respective personnel that were assigned to service that hotel. We then used SFDC’s inherent functionality (cases, logging calls, etc.) to record the various types of services performed for each hotel. These services were everything from technical support on their Property Management System (PMS) to processing rate and inventory change requests to 3rd party Online Travel Agencies (OTA’s).
 
 
However, we had one service organization that needed some additional customization to properly account for the services they provided – and basic call logs, notes, or tasks didn’t cut it. They needed something different. This team was field-based and their primary objective was to provide operational consultative services to each hotel franchisee within their portfolio. Their main responsibility was to improve the financial performance of their portfolio, and they each had annual performance goals to achieve.
 
 
I knew that we needed some additional features and functionality created in Salesforce to not only allow this team to track and report on their portfolio’s revenue growth, but also to create “mobile friendly” ways each of these team members could record the services they provided.
 
 
One of the main services the field team conducted was to host one-on-one consultative meetings with each hotel – or what they called “site visits”. Depending on the needs of the property, site visit topics could vary. The field team wanted a way to record what was discussed as well as any agreed-upon follow-up tasks for the franchisee. They would then like to use this to compare to operational performance post-visit. They also wanted follow-up reports to be sent to the franchisee and have them be drafted and contained within the system.
 
 
Knowing all this – I knew the existing configuration of Salesforce needed to be enhanced. We needed to link a way of recording site visits to the new property object. We also needed a way to show topics and action items that were part of each visit.
 
 
Before any design changes were to be made to Salesforce, I spent a good month with the business team doing what I like to call an “Iterative Requirements Gathering” (see diagram below). I took their business intent and transferred that into specific use-cases via process models. Process models are great ways to ensure that the business intent is manifested within the new system – and that the outcome is what they want.
 
 
From there I designed a “mock-up” of how I envisioned Salesforce working to facilitate this. It had to not only be easy to use for the field team members (e.g. mobile friendly) but also it needed to allow for the type of reporting and metrics this team needed. Doing this mock-up, I was able to work with the Salesforce Administrators to create a prototype in the UAT instance. From there, myself, the business teams, and the Salesforce developers played around with it and made minor changes to suit the needs of the field team leadership. (This process loosely followed an Agile methodology).
 
 
The end solution we all agreed to was to create a new custom object in Salesforce that was solely for site visits. To make it easy for the field team to use, there was workflow created within this custom object that ensured consistency in data entry which ultimately allowed for consistent reporting.
 
 

 
 
The site visit records were linked to each property record as a part of the related lists. Within the custom site visit record, we used standard Salesforce functionality such as tasks, cases, e-mails, notes, and attachments to house other important documents or follow-up items about a specific site visit. To allow for the field team to follow up with each franchisee after their visit, we used an App from the Salesforce AppExchange to pull notes and action items straight from the site visit record and into an automated professional follow-up e-mail communication. Automating this function reduced the amount of time the field team spent on re-writing follow-up tasks in e-mails.
 
 
In the years since these design changes, Salesforce has turned into the largest single system used by this hotel franchising company. Additional features have been added using the AppExchange that have furthered this company’s ability to not only service their hotels well, but to do it in an efficient and cost-effective way.