The FixItFast Scenario


Options



Fix it Fast Scenario: Table of Contents

The Background Story

In the contract maintenance business, providing fast, reliable repair services is critical to building solid customer relationships that ensure ongoing business after the initial contract sale.

FixItFast Inc (FiF), a mid-sized supplier of maintenance services for large household appliances, understands this challenge. FiF provides extended warranty contracts for appliances sold by Big Box. At the time of purchase, Big Box receives a percentage of the contract price, and FiF relies on a continued relationship with customers for ongoing business.

With other companies entering the contract maintenance business, FiF needs to differentiate itself as a company that understands and responds quickly to true repair emergencies. To achieve this goal, they plan to develop a mobile strategy that will:

  • Improve customer satisfaction by providing a convenient mobile interface for reporting appliance issues

  • Add value and efficiency by tying into existing repair dispatch services that are currently only available over the phone

  • Ensure that urgent incidents are handled quickly by deploying the nearest available repair technician in the field

By connecting directly with customers, they hoped to improve the overall customer experience and deliver a mobile strategy that meets the needs of the customer, customer service rep, and repair technician in the following scenario.

The tale of the leaking water heater

The Customer: Lynn

Sample chart

Lynn, a FiF customer, purchased a hot water heater from Big Box last year.

Upon returning home from work one day, Lynn walks into her kitchen and sees water seeping out from under a door. On closer inspection, she notices that the hot water heater is leaking. A sticker on the appliance reminds her that she has purchased an extended warranty. The sticker says to visit the FiF website to search for common issues.

  • Lynn navigates to the website and searches for known causes of her problem.

  • After ruling out several possible causes (loose back hose, loose top cap, and so on), she follows a link to download the FiF mobile app and report a problem.

  • After downloading the app and confirming her identity, she is prompted to take a photo of the FiF barcode on the hot water heater.

  • Lynn submits the picture of the barcode and proceeds with the problem report.

  • She provides the LED error code displayed by the water heater and is assigned an incident number.

Moments later, Lynn receives a text message asking her to verify that the problem is an emergency. Lynn is relieved to know that FiF is responding quickly to her issue.

The Customer Service Rep: Jay

Sample chart

Any requests for emergency service go to Jay, a Customer Service Rep, for validation. Jay uses a web application at the call center to process requests. Upon receiving notification of Lynn's urgent incident:

  • Jay clicks a link to view the details of the incident.

  • He confirms that Lynn has performed the recommended checks, and then calls her to verify that she will be home for the repair.

  • He clicks Dispatch, and Lynn's address appears on a Map, along with all the technicians in her vicinity and their estimated availability.

  • The request is automatically dispatched to the nearest technician.

After a few minutes, the status of the request changes. Jay can return to monitoring the Customer Service queues knowing that a technician with a good customer satisfaction rating is on the way to help Lynn.

The FixItFast Technician: Joe

Sample chart

Joe, a FiF Technician, is out in the field and hears his mobile tablet buzzing with a notification coming in. He has enough time to complete another repair before his day ends, so he looks at his tablet and sees a map with a red blinking pin. An emergency repair request has been dispatched.

  • Joe clicks the notification to display the incident report with a description of the issue.

  • After looking at his schedule and the location of the repair, he accepts the job to let dispatch know that he is on the way.

  • The job details change to show the full details of the customer and the problem.

  • Joe clicks a link to look up other issues that have been fixed with that brand of water heater. He doesn't know if he will have a signal at the customer location, so he downloads all the information to his device.

  • He clicks an arrow to activate directions to Lynn's house, and he is on his way.

Meanwhile, Lynn receives a notification in the FiF app with a picture of her technician, a license plate number, and the approximate arrival time.

When Joe arrives, he troubleshoots the problem by viewing the information that he downloaded to his device. After making the repairs, he swipes Lynn's credit card, and an email receipt is sent to Lynn. He updates the report and thanks Lynn. On the way to his truck, he changes his status in the application to 'unavailable' to let FiF dispatch know that he is done for the day. Joe is pleased because he was able to make the repair and process the payment without having to call in to FiF like he would have done in the past.

Later that evening, Lynn tells her dinner guests of her near disaster and how FiF lived up to its name. After a good laugh, they all agree to try FiF for extended warranty coverage the next time they buy appliances at Big Box. Before Lynn turns in that night, she notices a screen on her mobile device to rate her experience with FiF - she gives it 5 stars!

How Does Fix It Fast Deliver?

The Mobile Program Manager: Mike

Sample chart

As the VP of Services, Mike is responsible for growing the business and, ultimately, for the profitability of the business unit.

The current business involves partnerships with service technicians across their geographic coverage, combined with a call center. The call center staff receives calls from customers, assists them over the phone by collecting customer and product information, and walks them through common issues and diagnostic steps. If the problem cannot be resolved over the phone, a service technician is dispatched.

Last year Mike managed the effort to replace their manual support system with a cloud-based customer experience solution. The Oracle RightNow and Siebel integrations have been a great success with customer service representatives in the call center as well as customers accessing the system through their PCs.

It was Mike's idea to expand their service delivery model to include a mobile interface for both customers and technicians.

Mike worked closely with Eric, the Enterprise Architect, during the evaluation phase to ensure that the best solution was selected and that strict security and monitoring requirements were met.

When the new apps are rolled out, Mike will start each day reviewing the usage of the web and mobile systems to ensure that they exceed their adoption targets for the mobile apps while also reducing call center costs. By reducing the time required to resolve each service request and showing the CEO and CTO the tangible benefits of their cloud-based mobile strategy, Mike will be well positioned to move into his new role as Chief Mobility Officer.

The Enterprise Architect: Eric

Sample chart

After reviewing cloud-based and on-premise mobile suite offerings, Eric selected an mBaaS solution provided by Oracle. The Mobile Cloud Service provides easy-to-use tooling for backend integration and shaping mobile-friendly RESTful APIs. Other differentiators are the enterprise-grade, built-in security and role-based entitlements with the rich analytics that Mike requires to help him know that the mobile strategy is on track. Of course, these are in addition to all the other common features of mBaaS, such as data sync, push notifications, location, and mobile presence services. The integrated documentation and community provided by the Mobile Cloud Service were also influential in his final decision to the choose the Oracle offering.

The Service Developer: Samir

Sample chart

Background: After meeting with Eric, Samir understands the urgency to deliver a mobile capability that goes beyond simply providing mobile friendly web pages. Samir has been chosen to build APIs that will be consumed by Mobile Application Framework to support new mobile applications for incident reporting and technician dispatch. Although Samir will not build the mobile apps himself, he needs a clear understanding of the flow of data and process to ensure that he designs the right APIs to connect to the RightNow system and other enterprise systems needed for technician dispatch.

The new mobile customer support channel needs to offer a variety of features, including: interactive knowledge search, the ability to create, update, and escalate incidents, the ability to send push notifications to the mobile device as incidents go through their lifecycle, and preferences for controlling alerts and notifications.

The new dispatch / technician mobile channel needs to leverage location and presence services to find available technicians in the field based on the location of incoming emergency repairs. The ability to update incidents based on role must be considered for technicians. Only Supervisors can update the original report from the customer. Technicians can add and edit comments on the incident report.

From past experience, Samir knows that he should meet with Mia, the FiF Mobile Developer, to understand the data and services required by the mobile apps before proceeding with any service development. Mia's requirements drive what data needs to be obtained from backend systems and how that data needs to be aggregated and shaped for mobile consumption. Most backend systems at FiF use XML to transmit data; however, a mobile strategy requires many optimizations, and the data needs to be transmitted as JSON for efficiency.

FiF Development: After speaking with Mia, Samir reviews the data types and mobile APIs that she has defined. She has determined that most of the resources she needs for the mobile app are available, but there is nothing for managing contacts needed by the FiF Customer (for self-registration and profile updates) and FiF Technician (for getting contact details for incidents). Mia defines the API and resource model for contacts that Samir needs to implement. To provide the missing contacts API, Samir identifies the Siebel connector APIs that he needs to expose.

When Samir has a clear understanding of the data and operations provided by Siebel and RightNow, he writes services that map the Siebel and RightNow artifacts to the resource model and APIs that Mia has defined. To meet the mobile API definition, he adds custom logic to shape the data going into and coming back from Siebel and RightNow. Samir completes the APIs for Mia and publishes them to the Developer Portal so that Mia can browse, search, and test the new services that implement the APIs she defined.

Samir and Mia discuss how security and analytics will be gathered for the customer mobile app. Samir's idea is to issue a token to the mobile device when the customer downloads the mobile app and scans an appliance for the first time. Every time the app interacts with the APIs, the token will be sent and validated by the backend, and metrics about location, device type, and the APIs leveraged can be streamed. This information can then be viewed by Mike, the Mobile Program Manager, to understand factors that influence the success of the FiF mobile strategy.

The Mobile Application Developer: Mia

Sample chart

Background: Mia knows from previous experience to keep mobile as simple as possible. Although the FiF on-line customer support portal offers a rich set of features provided by RightNow, she knows that the success of the new mobile apps relies on how quickly and easily the customer (and technician) can gain access to critical information in an emergency repair setting. Supporting built-in mobile features, such as the camera for scanning appliance barcodes, will greatly improve the overall experience.

FiF Development: After Mia and the UX team complete the application flows and basic screen designs for the customer and technician mobile apps, Mia identifies the data and operations that are needed for each screen. She then logs into the FiF MCS development instance to browse the service catalog and find the REST APIs that will provide her with the resources (data) that she needs. The service catalog provides Mia with a list of the REST APIs, data structure formats, data sync operations, and the notification delivery details, along with integrated documentation to assist with usage. Entitlements for each API are displayed so that she knows which APIs are available to each user role.

Mia notices that there is an API to obtain incident reports for appliance models, but there is no API to manage contacts. She defines the mobile API that she needs and writes a mock service implementation that allows her to continue developing the mobile app while Samir, the service developer, builds the real service.

She contacts Samir to let him know that she has defined a new API that needs to be implemented.

When Samir finishes service development, he contacts Mia to let her know that he has added the necessary API, and he informs her of the entitlement associated with it. That's no problem because Mia and the UX team have already identified the customer and technician user roles, and they have designed the two apps accordingly.

The Mobile Cloud Administrator: Amanda

Sample chart

Now the APIs are implemented and Amanda, the MCS Administrator, is poised to monitor the services to ensure that they are running smoothly. She uses built-in diagnostics tools in MCS to identify and fix problems, and she handles permissions for team members to ensure that mobile developers have access to all the APIs and environments that they require to move the development artifacts through the stages of the development lifecycle.

What's next

So now that you have seen how the business works and the major players, it's time to take a look at how Oracle Mobile Cloud Service helps solve the business problems.

In this tutorial you will create an Oracle Mobile Cloud Service backend or MBE to support the Incident reporting side of the business. You start with a simple API. Later you add Users and security and storage collections.

You eventually tie the API to a REST service.