Service Cloud Implementation Guide. Service Company Case Study.

I decided to write this Salesforce Service Cloud Implementation Guide to share the knowledge I have collected during setting up our own process inside the company. Thankfully, Salesforce has plenty of well-written documentation. However, there were some knowledge gaps I had to fill in by myself. Here is my complete Service Cloud Implementation guide from a business owner’s perspective. At the very bottom, you will find the salesforce service cloud implementation checklist, which I have produced to make things easier. My goal was not to produce step-by-step instructions. I wanted to share what steps have I taken and what has led to success and what’s not. Take this as a Salesforce Service Cloud Implementation Guide written by the business owners in plain business language.

The shift in business model towards services

I live in Latvia – a lovely northern country in Baltics. The covid-19 pandemic has dramatically impacted our local economy. Our company was among those businesses that have not suffered too much from pandemics. Nonetheless, our customers were touched by the lockdowns and we have seen a decrease in our project’s quantity. The sizes of the projects also declined. I remember it was January, a beautiful snowy day outside when my colleague Maxim dropped me an invitation to a Zoom conference. He said we should start thinking of ways to reduce one-time costs for our customers. A few coffees later we came up to the conclusion. The economy is moving towards subscriptions, so should we. And we decided to give it a try and launched Blondie Care. A managed service program for existing Salesforce users.

The Challenge which led to Service Cloud implementation guide

The biggest problem was that we are going to have lots of smaller customers. Our offering includes packages with different services. For example salesforce administration, apex development, business consulting, user training, and so on. Even worse things became after we got feedback from the market. Our customers wanted custom packages. Some of them wanted phone support. Some of them were looking for a customer portal, so they can keep track of their inquiries. So I sat down and started googling. What are available solutions for service companies like ours? And I found nothing. Not a single case was described. Nobody shares his way of implementing the Service cloud. This led me to their thought. I should produce my own Salesforce Service Cloud implementation guide. And I also have included the salesforce service cloud implementation checklist at the end of this article.

Why I have decided towards Service Cloud

To be honest. There are not many alternatives on the market. Despite the fact, that every second SaaS company produces customer support-related tools. There are not many products on the market that really act as a business tool. Rather than fancy interfaced web apps for the narrow target audience. It’s no secret that we are Salesforce Consultancy Partners and we know the product. The only reason I have not jumped into Service Cloud straight away was the cost of the product and the complexity of the initial setup. We had first clients waiting to be served. The solution was needed to be there yesterday. So I’ve decided that evaluation of all available options will take longer than just taking the Salesforce and starting customizing it for our own needs.

Oh, by the way, there is a story on how we ended up with this solution. Mind reading this article after you finish this article.

Further reading: Salesforce for Small Business Review After a Year of Using The Product

Start with business process

Because this is the Salesforce Service Cloud Implementation Guide I need to provide some guidance. So here is the first tip. Start with your business process. Just like I did. I have started with thinking of what type of functionality will I need. And I came up with the list of processes which has to be tracked.

So here is the first tip. Start with your business process. Just like I did.

Our process

• Customer logs a case with us via email, phone or customer portal.
• We assign priority to the case and estimate resolution time.
• Customer gets confirmation notification about case submitted and resolution time estimation.
• If case exceeds 6 hours of billable time, we produce a quote for confirmation.
• If case does not exceed 6 hours of billable time, we resolve the case.
• During case resolution we track billable and non-billable time. Billable time should be written off customers plan. If billable time exceeds included with the plan, we should add this to customers next invoice.
• Once case is resolved, we close the ticket. Customer get notification about case was closed.
• Once in a quarter customer can transfer 50% of his unused services (hours) to the following month. That’s our killer feature 🙂

Drawing requirements

At the first glance, our business process doesn’t seem to be over complicated. In fact – it’s not. However, it includes functionality that is not available out of the box. For example – billing would require tracking of available and used hours during the billing period. We needed to see how many hours are left with clients’ subscriptions. Secondly, we needed to track time. There are plenty of time trackers on the market, but we wanted to keep everything in one place. So here is the second tip. Draw your requirements.

So here is the second tip. Draw your requirements.

Next should have been structuring my thoughts and translating them into requirements. I used my beloved Notion app and shared my thoughts with colleagues. That way I had a chance to get instant feedback on potential flaws in requirements. Thankfully my colleagues were responsive and by the end of the day, I had a clear list. I decided to share my list below:

Case logging

• Send email to our customer success email
• Manually log a case via Salesforce
• Log a case via Customer Portal
• Log a case via Chat in our customer success website

Case management

• Assign case to agent.
• Communicate with customer via Salesforce.
• Track time which it took to resolve the case.
• Change statuses and notify customers about the statuses.

Billing

• Track services left in the contract.
• Bill overspend hours plus regular subscription fee.
• Track non-billable time (so we actually track unprofitable customers).
• Generate invoice every month and send it to customer.
• Reset limits after invoice was generated.
• Keep history of tracked and billed time.

The Roadmap

After I looked at all of my requirements I came up with the conclusion. I should split this into what’s mission-critical and what’s not. It is not so easy, especially considering we have already sold some non-existing functionality to our customers. For example one of the clients wanted access to the customer portal. He wanted to log and track all of his cases inside the portal. So I sat down and started thinking. My thinking process was as follows. “We need to log cases and resolve them. That’s mission-critical. Everything else is nice to have features and selling points. At the end of the day, customers are paying us for resolving their issues with Salesforce.”

So here is the third tip from me. Think of mission critical processes which can’t be eliminated. Prioritize them and build a three, four or whatever it is, steps in which you will be rolling out functionality.

So here is the third tip from me. Think of mission-critical processes which can’t be eliminated. Prioritize them and build three, four, or whatever it is, steps in which you will be rolling out functionality. So did I and produced a roadmap split into four phases. And of course, I’m sharing this with you. Oh, forgot to mention. By splitting the process into multiple phases, you reduce the time it takes from building requirements to a functional product. Also, the earlier you get your hands-on experience from the product, the earlier you understand where you were wrong. For example, I have adjusted the roadmap 180 degrees from the original one. Below is my final roadmap. It’s not perfect, but this is what I used.

Phase 1 – MVP

• Register a case manually.
• Register a case via email.
• Send notifications to customers.
  • About new case registration.
  • About case closing.
• Track time used.

Phase 2 – Customer Portal

• Register case via customer portal.
• Track customer contract limitations.
• Add ability to transfer services.
• Add approval quote (remember, we are approving billable time every time it exceeds 6 hours with customer).
• Automatical reset of the contract every month, with ability track extra hours.

Phase 3 – Omni-Channel

• Ability to send inquire in chat.
• Full billling tracking in salesforce.
• Automated approval process for cases exceeding 6 hours of billable time.

Phase 4 – Call Center

• Ability to track sales and convert them to service contracts.
• Automatically raise a case when incoming call comes in.

The Architecture

If you are still reading this, probably you are interested in how we managed to implement all this. Well, it’s all about architecture. In simple terms, we made a set of decisions on how we are going to track things. And the first step was to decide on fields. So my fourth tip would be – decide on fields and their business meaning. Think long-term. Try to predict what would you want to know in the future from your reports. The more scenarios you will be able to evaluate, the less of a problem it will be for you in the future. Don’t forget to check the salesforce service cloud implementation checklist at the end of the post.

So my fourth tip would be – decide on fields and their business meaning. Think long term. Try to predict what would you want to know in the future from your reports.

Creating a future-proof architecture of the system is not only about fields. It’s also about relations you are building across your system. Sometimes it’s better to get a good Salesforce professional at this point. Thankfully I had plenty of them sitting in the same room. So we created a couple of sandboxes and started playing around. The final result was there in a couple of days. Again – we had to be in a hurry. Our first customer has submitted a case. Here’s what we have built.

The center element of our system is Service Contract. Service Contract stores all the data about the contract. I have included more information about how the service contract is organized. Just keep reading.

Here is an oversimplified diagram of how we decided to organize our Objects in salesforce. There is a custom object called time entries. It acts as a linking object between Cases and Services Contracts. Service Contract stores information about customer remaining limits this month. They also store information about services included in the package. When the reset date occurs – current limits are reset.

Terminology

Here are some basic things you need to know before reading further. Please note, that for the purpose of service cloud implementation guide simplicity, I have removed the least important objects from this description. Also, there is a short salesforce service cloud implementation checklist at the end of this article. So here we go.

• Billing Cycle. A 30 day period, represented by field Next Monthly Limit Reset Date. Not a calendar month, but 30 day period.
• Billing Quarter. A 90 day period, represented by field Next Quarterly Limit Reset Date on Service Contract object in Salesforce.
• Limits. Monthly service limits (hours) customers are eligible for. It’s something simillar to entitlements.

Service Contract

Represents currently active, physically signed contract with the customer and includes all the information relevant to the contract.

Fields

• Next Monthly Limit Reset Date. This field represents billing cycle for the client and the date when an order will be automatically populated based on product information related to Service Contract. This field is automatically updated and is being manually set only once – when new Service Contract is created (most likely will be automated based on Contract Start Date).
• Next Quarterly Limit Reset Date. This field represents Service Transfer restriction cycle. Some Service Contracts might include an option to transfer Service Limits to the next month, in case they were not fully used by the customer in current billing cycle.
• Service Transfer Restriction checkbox. This field represents if customer has utilised his right to transfer Services during current billing Quarter. If checkbox is set to TRUE – you can’t transfer Services, until Next Quarterly Limit Reset Date occurs and system (via Flow) removes the tick.
• Service Transfer Allowed. Represents if the Services Contract included Service transfer option as such. If contract does not include such option, you won’t be able to transfer services to the upcoming month.
• Service Transfer Limit. Represents maximum amount of Services (based on Contract Service Lines, Monthly limit field) which could be transferred to the next month.
• Approval Threshold. Represents maximum amount of hours which could be logged without prior approval with the client.
• Approval Threshold Value. Represents maximum amount of hours in monetary value which could be logged without approval with the client.

Relations

• Contract Line Items. Represent customers actual subscription product which the customer have signed up for. This Contract Line Item is being added to recurring order which is being created automatically in the end of each billing cycle.
• Contract Service Line Items. Represent which services are included with the Service Contract and what limits have been already used and which of them are still available. If limits are overspend, quantities with negative value will be added as Order Products when next billing cycle occurs and before limits are reset.
• Time Entries. Represent time spent to service the customer.
• Cases. Represent cases, which where created while Service Contract was active and which have impact on customer billing during the Service Contract active phase.
• Orders. Represent recurring orders created automatically in the end of each billing cycle. Include Contract Line Items plus those Services which where overspend in the end of billing cycle.

Contract Service Line

Represents limits available to customers and limits included with the contract. This Object and its entries are being used during the automatic process of resetting the limits. Again, you can use this as a service cloud implementation guide, but try applying your own business logic.

• Monthly limit. Represents monthly limit of hours included with the contract. If not overspend, no additional billing will be applied to the customer. If overspent – negative value is used as quantity during order creation process.
• Billable Used This Month. When a time entry is created and it is marked as billable, Flow automatically updates this field, thus representing how many billable hours was used during current billing cycle.
• Remaining this month. Represents how many hours have been left, before customer will be billed for extra hours.

The remaining this month’s field value could exceed the Monthly Limit field when customers have made a transfer of services from the previous month. This is being updated automatically by flow, buy addition of Transfer Amount field and Monthly limit field during Limit Reset process in the flow called “Service Contract Limit & Billing Scheduler”

• Price. Price of the Service in case the limits are overspend.
• Non-Billable Used This Month. All Time Entries summed up which was marked as non-billable.
• All Time Billable. Simple counter, updated by flow each time time entry is created. Used to track Service Contract all time statistics.
• All Time Non-Billable. Simple counter, updated by flow each time time entry is created. Used to track Service Contract all time statistics.
• To be Billed Total. Amount which will be billed for extra hours in the end of the billing cycle.
• Transfer amount. Represents amount of hours which will be transferred to next month during billing cycle reset.

Time Entries

Represent any time that was spent while servicing the customer. Time entries can be billable or non-billable. Depending on the type, they are added to Service Contract billing or not. Both – Billable and Non-billable hours are aggregated on Contract Service Lines, but in different fields, so that non-billable Time Entries do not affect customer’s billing and would not spend assigned limits.

Fields

• Amount of Hours. Represents amount of hours spent to fulfil Service Contract obligation.
• Billable checkbox. Represents if this Time Entry should be added to Service Contract billing. If ticked, it writes off limits from Remaining this month field.
• When have Occurred. By default Today’s date, but could be modified to file billing hours occurred in the past.

Relations

• Account. Represents an account which this time is applicable for.
• Service Contract. Represent Service Contract this field is applicable for.
• Contract Service Lines. Filtered lookup. Represents which Service this Time Entry is particularly applicable form. Once chosen, it will affect limits written off Service Contract.

Orders

Represent billing record which is billed to a customer and is populated automatically via Flow at the end of the billing cycle based on the date in the field Next Monthly Limit Reset Date. Includes all Contract Line Items included with the Service Contract and all overspend Services (Services that had negative value at the end of the billing cycle).

There is a flow, “Generate Recurring Order for Service Contract” which is triggered automatically, which creates order. This flow is triggered by another flow “Service Contract Limit & Billing Scheduler”

Once an order is created, it should be sent to the Xero billing platform. Currently, the process is manual, and once an invoice has been populated in Xero and sent to the customer, the order status should be manually updated as Activated.

Other objects

I have excluded some objects, for the purpose of simplifying an article. We don’t want to end up with too much of a technical post. Hopefully, this gives you a rough impression of what have we done in order to make things happen. Also, I have not included reporting in this article, as our reports are still in progress at the moment of publishing this article. We change them almost daily. A have also skipped the part about security. Anyway, this won’t be possible to write down everything in one article. Finally, I have not included anything object-specific in the salesforce service cloud implementation checklist at the end of this article.

Final step

Now when I was done with the basic setup of the system I had to onboard our services agents. A lot of consultants and business owners underestimate this point. What I did was make two-hour-long training sessions. Secondly, I have set up 30-minute Q&As every morning for the first two weeks after the launch of the product. And lastly, I have created a chat group, where I answered questions ad-hoc.

So here is my last tip. Chose “go live” date and prepare for it.

So here is my last tip. Choose a “go live” date and prepare for it. Send an email to everyone to onboard people. Don’t be too technical, just use simple terms. And provide proper training. By proper training, I mean that you have to make sure, that everyone involved knows each and every aspect of functionality which related to them.

Hope this article was helpful. You can always ask us for help with your Service Cloud setup. We will be happy to address any questions.

Cheers.

Salesforce service cloud implementation checklist

Oh, and I have promised to provide you with the salesforce service cloud implementation checklist. Here is what I believe should be checklist items.

• Business process described
• Requirements drawn
• MVP (Minimum Viable Product) defined
• Rollout roadmap defined
• Resources found (consultants, specialists etc.)
• Team is aligned on the scope (I’d call it pre-flight check)
• Launch date defined
• Pre-launch emails sent (at least two)
• Launch traning done
• Reccuring meeting planned
• Feedback collected