Enhancing Customer Experience with Oracle Service Cloud
By Sunil Gandhe, COO, Onsitego and Suyash Bharadwaj, Assistant Vice President-Product, Onsitego
Sunil Gandhe, COO, Onsitego
OnsiteGo is an after sales service company with a focus on providing consistent customer delight. Standardized processes, trained & super motivated employees, and technology to automate complex workflows into simple solutions are the key pillars for a delightful customer experience. To address the technology aspect, we decided to go for Oracle Service Cloud after a comprehensive evaluation cycle. We considered building niche solutions in-house so that we could have more control on that functionality and make changes quickly. In our case, we built an in-house solution to manage a database of our customers with active warranties based on the data shared by our clients. We then integrated this system with Oracle so that service requests could be created immediately.
In this article, we would like to present our learnings– some were expected and some were surprises!
1. Process first or Technology first!–Processes existed, but in the minds of our people. As part of partner workshops, we documented the processes that were very clear to us. The expectation was that these processes will be mapped to the system. Some processes for newer service models were fuzzy and we used the system to define the process for us. So while we used existing knowledge to define processes in majority of the use cases, in some of the others, it was the system adoption feasibility, which guided us. This exercise helped set up Standard Operating Procedures for the service organization.
2. People, people and people–By nature, human beings are resistant to change. You cannot possibly imagine where the resistance could come from–process owners, passive end users or folks who just like to oppose any change! Once a prototype was prepared, we involved end users and process leaders for feedback/ inputs. We made them realize that it is their project—It is a business and not an IT project. We built a sense of ownership. This exercise also helped us in getting as many exceptions to the rule and made the SOP document as exhaustive as possible.
3. Time-Resource Discounting–New requirements, surprises, shocks increase your planned effort, budget, and timelines. Even if you are a rock star project manager, a buffer has to be built to cushion these delays. The stretch need not be shared with the teams but the leaders will have to be cognizant of this and consider this factor while planning and resourcing. Like-wise our timelines also extended but we took a conscious call to not get rattled by it but to focus on the quality of delivery.
4. Expectation setting—We set expectations of the end users in terms of what they will get now, what they will get later, and what they will not get at all. Providing reasons made the exercise objective. A lot of times the implementation and end user teams were at loggerheads.
Suyash Bharadwaj, Assistant Vice President-Product, OnsitegoThis is where conflict resolution skills of the leader who was driving the project got tested. Some tough decisions had to be taken to ensure that project was on track and did not spill over.
5. Introduce the change when/where it hurts the least—Let’s face it. Despite the best of effort before you go live, some unexpected issues will crop up. To mitigate this risk, we keep support teams ready (internal and external) and go through this change when the business is a little lean or if it is cyclical when the downward cycle starts. This allows the teams to focus on the change and address issues better rather than get panicky at the drop of a hat. For example, avoid quarter/year ends (finance and sales teams), holiday season for hospitality/airline industry etc. We had no option here but to go live when the service volumes had already peaked but we mitigated the risk by doing a pilot phase in a city where service volumes were low. Then we went live pan India.
6. Adapting to the change—Bringing in software does not change things overnight. It takes time to fine tune it. So we had our implementation partner do the demo not once or twice but many times over the course of going live. We even had various users use the staging environment with mock cases to learn, condition and train the teams better. We mimicked the Go Live and it helped us in 2 ways: The teams were better trained and we got a hang of the things to come.
7. Communication—At an organization wide level, we provided information on the project and why we are undergoing change in the form of fancy emailers and meetings. We discussed this on internal forums like facebook’s workplace. We also kept our clients informed of this change and made them a part of our Big Change.
8. This is a journey!—There is rarely (perhaps never) a 100 percent mapping between planning and execution. Initially, there were teething issues but over a period of time these issues ceased to exist. Some new issues took their place! We found solutions for them as well. It took time for users to get used to the system. Post stabilization, new processes/ requirements started flowing in. In short, stability is a myth! This was a road to continuous improvement. Once we were satisfied with how we were managing systems for internal processes, then we graduated to analytics or thinking of how we can work more closely with our ecosystem like clients, vendors, partners etc. We built a pecking order to guide us what issues to sort first.
9. Success criteria of the project— Identify the processes that will get streamlined. Best is if we can set a target from a metric standpoint. For example, in our case it was TAT for various processes and sub processes; NPS (pre and post go-live). This helps in evaluating the success of the project in an objective manner.
10. Customer First Approach—In a service industry like ours, all this is being done for the customer. We never lost sight of how customer was benefitted. Hence after every process or a requirements gathering workshop, it was important for all of us to take a step back and think whether the customer’s experience is being enriched from this project. The above tenner is an experiential output and will certainly be different for other organizations. But we are sure there will be quite a few common threads running across your projects and the way we handle them determines their success! Choosing a software and a partner to implement it are just the beginning of a journey towards continuous improvement. According to us, that is just the tip of the iceberg!
