This chapter discusses how to implement the Oracle Mobile Field Service - Voice application.
This chapter covers the following topics:
To implement the Oracle Mobile Field Service - Voice application several steps needs to be performed. These steps are outlined in the section below.
To successfully implement the Mobile Field Service - Wireless application, complete these steps in the order shown in the following table:
Required | Step Title |
---|---|
Yes | Implement Oracle AS Wireless Server (10.1.2). For information on implementing the Oracle AS Wireless Server, see the chapter discussing the implementation in this guide. |
Yes | Implement Oracle Field Service. For information on implementing Oracle Field Service, see the Oracle Field Service Implementation Guide. |
Yes | Implement the Mobile Field Service - Wireless application. For information on implementing the Wireless application, see the chapters discussing the implementation in this guide. |
Yes | Deploy the Voice Gateway. |
Yes | Set Up Profile Options for Oracle Mobile Field Service - Voice. |
Optional | Set Up Voice Files (.wav). |
Optional | Add Voice Grammer for Material Debrief Alpha Numeric Search. |
Voice-enabled applications that enable information access for workers on-the-go will soon be considered essential at all value-driven organizations. When mobile workers have immediate voice access to personal and corporate information, they are more productive, efficient, and responsive to customers, thus increasing the organization’s return on investment (ROI). An organization can further increase its ROI by handling routine call center questions with automated voice-enabled applications, thereby enabling call center agents to focus on revenue generating calls. In the past, deploying and integrating interactive voice response (IVR) platforms and custom voice-enabled applications in an organization’s data center was challenging and costly due to the proprietary hardware and software, redundant infrastructure, and staffing they required. Oracle has greatly reduced these hurdles by creating an architecture that leverages an organization’s existing IP-based infrastructure, thus offering easy integration, no redundant infrastructure or staffing, and a better user experience than IVR.
The Oracle Mobile Field Service - Voice application can be deployed with just two new, open standard, easily integrated components. These components are:
The wireless and voice capabilities of the Oracle Application Server, OracleiAS Wireless.
The VoiceXML gateway (supporting VoiceXML 2.0 standard).
For organizations that desire an immediate deployment or minimized capital expenditures, these components are available at hosting facilities worldwide.
Most organizations today have both the Interactive Voice Response (IVR) and web infrastructures installed. Legacy IVR applications such as, paging, auto-attendant, and moviefone give callers access to information delivered in audio through keypad-entered dual-tone multifrequency (DTMF) tones. The IVR infrastructure is typically a black box platform, containing proprietary hardware and software, including its own database and technology stack. IVR platforms are rarely distributable, are usually difficult to integrate, and often require their own Information Technology (IT) department.
This figure represents a typical organization’s IP data center, with the addition of the two components required to deploy the Oracle Mobile Field Service - Voice application.
This figure diagrams the delivery of a voice application to a caller. In this simple (unpersonalized) example, a caller dials the phone number of the voice gateway. The phone number is associated with an initial VoiceXML page, either static, or dynamically generated. The voice gateway answers the phone and (1) the user asks for calendar. The voice gateway uses speech recognition to determine what the caller uttered and then (2) makes an HTTP request to OracleiAS Wireless for a VoiceXML page containing the user’s calendar in audio. (3) OracleiAS Wireless relays the request for calendar to the Application. (4) OracleiAS receives a response in XML from the Application, and (5) transforms it into the markup language appropriate for the user's device, in this case VoiceXML. (6) The voice gateway interprets the VoiceXML and plays the calendar over the phone line for the caller. These steps should be familiar because it is the web model of delivering applications to end users.
The VoiceXML Gateway can also be hosted at a third party service provider based on the architecture depicted in the figure below.
The hosted VoiceXML Gateway should support VoiceXML 2.0 standard.
Using the Oracle Mobile Field Service - Voice application, technicians can perform several functions related to the service requests and tasks assigned to them at a customer site. Using a combination of phone and voice, technicians can perform functions that include:
Accessing Task Details.
Accessing Service Request Details
Calling a Customer
Changing Task Assignment Status
Creating a Labor Debrief
Capturing an Expense Debrief
Capturing a Material Debrief
Capturing a Counter Reading
When entering debrief information for a task using Oracle Mobile Field Service - Voice several profile options can be set to assist with entering this information by phone and voice. These profile options are detailed below along with any other profile options that are required for the Oracle Mobile Field Service - Voice application.
Navigate to the Profiles page to set these profile options (Functional Administrator: Cores Services > Profiles). The table below lists the profile options for the Oracle Mobile Field Service - Voice application. Below the table, these same profile options are detailed.
The Mobile Field Service - Voice application works with the Text-To-Speech (TTS) server. All of the data from the Enterprise database is read out using the TTS server. However, better quality of the voice application can be done using the voice wav files for the static prompts and messages.
The default wav files are shipped for language code en (English) and territory code (US). So the file naming convention is filename_en_US.wav (e.g., csfwTaskNumber_ en_US.wav). The language code and the territory code are taken from the Enterprise database for the user. So if the user has a different territory code or language code, then the TTS server would be used instead of the wav files since the files are not shipped. However, these files in the different language can be recorded and copied to the same location where the _en_US files are, then the wav files are picked at the execution time. For a user, language code is mandatory and the territory code is not. So if the territory code is not there in the database, then the file name becomes filename_TERRITORYCODE.wav (e.g., csfwTaskNumber_en.wav).
To support other languages other then US English, you can create similar .wav files for other languages providing a better experience for the voice users.
You can add new records into the ‘CSF_PHONETIC_VALUES’ table in the case where it is required to add new voice grammar for Material Debrief Alpha-Numeric entry. For example, to enter ‘C’ using Voice command, a user can speak ‘C’ or ‘charlie’. To add one more option for ‘C’ say ‘california’ you can add this entry to the above mentioned table.
Note: Currently, there isn’t a user interface (UI) to configure this table. You will have to use backend commands to perform this process.
For more details on the CSF_PHONETIC_VALUES table structure, please refer to Oracle eTRM at, http://etrm.oracle.com.