Common view for customer support

A network device sends, to a customer device, real-time customer data for a service campaign running on a service provider network. The network device receives a customer authorization to share the customer data with an agent of the service provider network. The customer authorization includes session context information related to the presentation of the customer data. The network device determines if there are predictive options for the customer data. When there are no predictive options for the real-time customer data, the network device sends, to the customer device, a first feed of the real-time customer data and sends, to the agent device, the session context information and a second feed of the real-time customer data. The session context information enables the agent device to build an instance of the customer data that is similar to a presentation on the customer device, without sharing the customer screen view.

BACKGROUND

Companies use call centers to address consumer inquiries and/or resolve consumer problems. A caller's call is often transferred to a device associated with a human agent to service the inquiry and provide desired assistance. The caller's inquiry often relates to information presented on a display screen of a computing device.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Systems and methods described herein provide diagnostic and monitoring tools to enable agents to better assist customers of a service provider network. Customers of the service provider network may be entities that use Internet-based services offered via the service provider network. For example, customers may include content providers that provide content for consumption by end-users (end-users may also be referred to herein as “consumers”). Agents of the service provider network may be representatives that provide technical support for customer inquiries.

Customers may obtain diagnostic and monitoring information via a self-serve web portal to reduce the need for customer support calls and reduce wait times to obtain service status. Diagnostic results, real-time data, customized reports, and other information may be provided to each customer. When a customer contacts an agent for assistance, the customer's inquiry typically relates to information that the customer is viewing through the web portal. In order for the agent to understand the customer's problem, it may be necessary for the agent to see the same data that the customer is viewing through the web portal.

Screen sharing technology is not a preferred option for allowing the agent to view a customer's data. Particularly, screen sharing can raise privacy concerns because the agent is given access to other information on the customer's screen that may not be relevant to the customer's inquiry. Thus, systems and methods described herein provide a common view of data for customer support inquiries that permits customers and agents to interact with the same data, without using a screen view that may share unrelated customer information. Furthermore, systems and methods described herein permit more and different types of information to be integrated into what customers or agents are looking at, providing a more holistic high-fidelity view, rather than the agent being limited to a graphically identical view in a screen-sharing context.

FIG. 1is a diagram illustrating concepts described herein. As shown inFIG. 1, a customer105may initiate a call with an agent115at a call center. The call may connect the customer105and agent115via, for example, a telephone connection or chat session. Customer105may have a question about particular information that customer105has accessed through a service provider web portal. The particular information may be presented, for example, via a web browser window or tab along with other information on a screen of a customer device110. Customer105may authorize agent115to initiate a common view on a screen of agent device120. Data from the service provider web portal may be fed to customer device110and agent device120and synchronized to permit a common view of the data in real-time. Only data relevant to the customer inquiry is shared with agent device120, thus protecting the privacy of customer105. As described further herein, the data views may be interactive. Thus, agent115may use the common view on agent device120to propose changes to a customer's campaign. The proposed changes and simulated effects may be presented in a common view on customer device110and agent device120.

FIG. 2is a diagram that depicts an exemplary network environment200in which systems and methods described herein may be implemented. As shown inFIG. 2, network environment200may include, a service provider network210including a data server215, a customer network including one or more customer devices110, a public network230, and one or more agent devices120. Components of network environment200may be connected via wired and/or wireless links. In one implementation, components in network environment200may communicate using application programming interfaces (API) to regulate interactions between devices and systems.

Customer device110may include a computational or communication device. Customer device110may enable a user to send/receive messages, view data/content, and interact with other devices. For example, customer device110may include a personal computer (e.g., a laptop or desktop PC), a tablet computer, a smart phone, or other types of computational or communication devices that can communicate with devices in network environment200. In one implementation, customer device110may include a web browser or dedicated application configured to access data and services from devices in service provider network210via public network230. In other implementations, customer device110may be configured to exchange instant messages or conduct chat sessions with one or more of agent devices120.

Agent device120may include a computational or communication device. In one implementation agent device may be a device similar to customer device110that enables an agent to send/receive messages, view data/content, and interact with other devices. In contrast with customer devices110, agent device120may be configured to access data and services from devices in service provider network210without going through public network. Particularly, in response to an inquiry from a user of customer device110, agent device120may access data from service provider network210that relates to a particular customer account.

Service provider network210may include one or more wired, wireless and/or optical networks that are capable of receiving and transmitting data, voice and/or video signals, including multi-media signals that may include voice, data and video information (generally referred to herein as “services”). Service provider network210may include a wide area network (WAN), a metropolitan area network (MAN), an ad hoc network, an intranet, a satellite based network, a fiber optic-based network, and/or a combination of these or other types of networks. Additionally or alternatively, service provider network210may include a cellular network, a Public Land Mobile Network (PLMN), and/or another mobile network. In some implementations, service provider network210may provide redundancy and/or the ability to distribute network loads. For example, service provider network210may include an IP network or a multiprotocol label switching (MPLS) network implementing an Interior Gateway Protocol (IGP) or another protocol that implements a minimum cost end-to-end path for routing between nodes. Service provider network210may provide one or more interfaces to connect to client devices (e.g., customer device110or other devices residing on customer network220).

Data server215may include one or more devices, such as server devices or network devices, that enable customers to configure and monitor services provided to consumers (e.g., clients of customer network220). For example, data server215may provide a web portal that may enable an operator of a particular customer network220to configure and monitor a service campaign (such a marketing effort, a product launch, new content, or other Internet-based services). As a particular example, data server215may enable customers (e.g., operators of customer network220or other content providers) to register billing accounts and particular content for toll-free data services. As another particular example, data server215may provide configurable diagnostics to monitor customer services (e.g., network services associated with a particular customer service campaign) provided over service provider network210and systems integrated with service provider network210. In one implementation, data server215may include or be in communication with forwarding boxes (not shown), in service provider network210, that store performance metadata and physical configuration data that may affect the ability of service provider network210to support services for customers. According to implementations described herein, the forwarding boxes may respond to capabilities queries from data server215(or a controller) to communicate particular performance metadata and/or configurations within a software-define networking (SDN) environment.

Customer network220may include a local area network (LAN), a WAN, or a combination of networks that provide services to consumers. Customer network220may be managed, for example, by a customer (such as a content provider) that provides video and/or data services to consumers in conjunction with service provider network210. Customer network220may include one or more gateway (GW) routers (e.g., customer premises equipment) that act as a secure gateway for devices (e.g., customer devices110) within customer network220.

Public network230may include a WAN, an intranet, a telephone network (e.g., the Public Switched Telephone Network), or a combination of networks. Public network230may include, for example, an untrusted network, such as the Internet. Public network230may further include transport and/or network devices such as routers, switches, and/or firewalls.

The number of customer devices110, agent devices120, service provider networks210, data servers215, customer networks220, and public networks230illustrated inFIG. 2is exemplary and provided for simplicity. More of these devices and other network devices, such as routers, gateways, switches, etc., may be included within the networks of network environment200. In some embodiments, functions of devices in service provider network210may be performed by different devices or combinations of devices.

FIG. 3is a diagram illustrating exemplary components of device300according to an implementation described herein. Each of customer device110, agent device120, and components within data server215may include one or more devices300. As shown inFIG. 3, device300may include a bus310, a processor320, a memory330, an input device340, an output device350, and a communication interface360.

Bus310may include a path that permits communication among the components of device300. Processor320may include any type of single-core processor, multi-core processor, microprocessor, latch-based processor, and/or processing logic (or families of processors, microprocessors, and/or processing logics) that interprets and executes instructions. In other embodiments, processor320may include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or another type of integrated circuit or processing logic.

Memory330may include any type of dynamic storage device that may store information and/or instructions, for execution by processor320, and/or any type of non-volatile storage device that may store information for use by processor320. For example, memory330may include a random access memory (RAM) or another type of dynamic storage device, a read-only memory (ROM) device or another type of static storage device, a content addressable memory (CAM), a magnetic and/or optical recording memory device and its corresponding drive (e.g., a hard disk drive, optical drive, etc.), and/or a removable form of memory, such as a flash memory.

Input device340may allow an operator to input information into device300. Input device340may include, for example, a keyboard, a mouse, a pen, a microphone, a remote control, an audio capture device, an image and/or video capture device, a touch-screen display, and/or another type of input device. In some embodiments, device300may be managed remotely and may not include input device340. In other words, device300may be “headless” and may not include a keyboard, for example.

Output device350may output information to an operator of device300. Output device350may include a display, a printer, a speaker, and/or another type of output device. For example, device300may include a display, which may include a liquid-crystal display (LCD) for displaying content to the customer. In some embodiments, device300may be managed remotely and may not include output device350. In other words, device300may be “headless” and may not include a display, for example.

Communication interface360may include a transceiver that enables device300to communicate with other devices and/or systems via wireless communications (e.g., radio frequency, infrared, and/or visual optics, etc.), wired communications (e.g., conductive wire, twisted pair cable, coaxial cable, transmission line, fiber optic cable, and/or waveguide, etc.), or a combination of wireless and wired communications. Communication interface360may include a transmitter that converts baseband signals to radio frequency (RF) signals and/or a receiver that converts RF signals to baseband signals. Communication interface360may be coupled to an antenna for transmitting and receiving RF signals.

Communication interface360may include a logical component that includes input and/or output ports, input and/or output systems, and/or other input and output components that facilitate the transmission of data to other devices. For example, communication interface360may include a network interface card (e.g., Ethernet card) for wired communications and/or a wireless network interface (e.g., a WiFi) card for wireless communications. Communication interface360may also include a USB port for communications over a cable, a Bluetooth™ wireless interface, a RFID interface, a NFC wireless interface, and/or any other type of interface that converts data from one form to another form.

As will be described in detail below, device300may perform certain operations relating to providing a common view of data for customer support services. Device300may perform these operations in response to processor320executing software instructions contained in a computer-readable medium, such as memory330.

AlthoughFIG. 3shows exemplary components of device300, in other implementations, device300may include fewer components, different components, additional components, or differently-arranged components than those depicted inFIG. 3. Additionally or alternatively, one or more components of device300may perform one or more tasks described as being performed by one or more other components of device300.

FIG. 4is a diagram of exemplary functional components of data server215. The functional components may be implemented by, for example, processor320in conjunction with memory330. As shown inFIG. 4, data server215may include a data module410, a device correlator420, a network correlator430, a customer interface module440, an agent interface module450, and a validation/arbitration module460.

Data module410may track service provider data for network performance and/or resources associated with customers. For example, in one implementation, data module410may provide data for network services, security, and/or applications/hosting associated with a particular customer. Examples of data provided by data module410include network availability status, performance reporting, metric reporting, a network topology, fault and trouble management, security and/or threat identification services, and/or customer platform access services for the customer's network. In a further implementation, data module410may track bandwidth use data correlated to particular customer products and/or activities. Data module410may also incorporate thresholds for network activity to identify predictive trends. In one implementation, data for data module410may be updated in real time or near-real time.

Device correlator420may receive device parameters from customer device110to identify possible delay times for display of data on customer device110or agent device120. In one implementation, device correlator420may assemble the parameters into device type profiles. Device parameters that device correlator420may receive from client device110may include, for example, a customer/agent identifier, a type of device, network access configurations, and an applicable software type (e.g., a browser type/version a dedicated application/version). The customer/agent identifier may include a unique alpha-numeric sequence for a particular user (e.g., of customer device110or agent device120). The type of device may include a pre-defined description code for a type of customer device. The pre-defined codes may include a make and a model descriptor. For example, the codes may identify device types and/or operating systems to distinguish between when customer device110or agent device120is desktop computer running a Window's operating system and when customer device110or agent device120is an iPad 4th Generation tablet running iOS 8.3. The network access configurations may include an access capability (e.g., 3G, 4G, Wi-Fi, etc.) of customer device110or agent device120. The applicable software type may include, for example, a type of web browser (e.g., Google Chrome43, Firefox 37.0.2, etc.) or application (e.g., a custom application, or “app,” to present data from service provider network210). Device correlator420may apply known processing characteristics of the device parameters to determine a lag time for a display of data on customer device110and/or agent device120.

Network correlator430may identify a location associated with customer device110(e.g., a geographical region relative to data server215). Network correlator430may also identify a connection speed, a minimum bandwidth, a number of hops, and/or other characteristics of a network connection between, for example, customer device110and data server215. In one implementation, network correlator430may also identify a location associated with agent device120, along with a connection speed, a minimum bandwidth, and/or other characteristics of a network connection between, for example, agent device120and data server215. The characteristics of the network connection for the network correlator430and the device parameters described above in connection with device correlator420may be referred to as session context information.

Particularly, customer interface module440may use information from device correlator420and network correlator430to identify, and compensate for, a lag interval between the display of data from data module410as presented on customer device110and the display of data from data module410as presented on agent device120. Customer interface module440may apply predictive algorithms compensate for the relative delay experienced by customer device110. The predictive algorithms may, for example, apply known historical data trends to real-time data to compensate for the lag interval between receiving/display data on customer device110and receiving/display data on agent device110when the data is sent from data server at the same time. In another implementation, customer interface module450may compensate for the lag interval between customer device110and agent device120along with compensating for a communication lag for a corresponding telephone communication between the user of customer device110and the agent at agent device120.

Customer interface module440may also receive and implement user input from customer device110. For example, customer interface module440may receive user input to enforce privacy settings and/or block sharing of particular data with an agent. In other implementations, customer interface module440may allow for modification of campaign settings and/or diagnostic services, approval of changes proposed by an agent, or proposing changes that can be implemented by an authorized agent. The customer input may be received via customer interface module440and relayed to agent interface module450and/or validation/arbitration module460for implementation.

Agent interface module450may also receive and implement user input from an agent at agent device120. For example, as described below in connection withFIG. 6, agent interface module450may receive agent input to change campaign configurations or diagnostic settings for a customer. The agent input may be received via agent interface module450and relayed to customer interface module440and/or validation/arbitration module460for implementation. In another implementation, agent interface module450may insert marker or place-holders into the agent view to maintain continuity with the shared data presentations that include masked data, as indicated on customer device110.

Validation/arbitration module460may receive proposed changes from agent interface module450or customer interface module440. Validation/arbitration module460may confirm or reject feasibility of the changes based on, for example, network policies, capacity limitations, subscription limitations, etc. In one implementation, validation/arbitration module460may evaluate current or projected network activity to ensure that a change to the customer campaign can be performed at a current or scheduled time without adversely impacting network performance. In another implementation, validation/arbitration module460may model a proposed change to determine its impact on service provider network210and other customers of service provider network210. For example, validation/arbitration module460may apply additional bandwidth requirements, network connections, etc. for a proposed change to a simulation of service provider network210. If validation/arbitration module460determines that a proposed change is feasible and not in conflict with other customers, validation/arbitration module460may provide a simulated data view of the proposed change to customer device110and agent device120. Validation/arbitration module460may use customer interface module440and agent interface module450to request a confirmation from one or more of the customer (using customer device110) and the agent (using agent device120) regarding the acceptance of the proposed change. In another implementation, customer device110may implement automated inquiries to initiate a proposed change and arbitration for a service campaign. For example, customer device110may have multiple proposed changes that may be stored and asynchronously submitted based on results from validation/arbitration module460(and/or an agent's response).

AlthoughFIG. 4provides exemplary functional components of data server215, in other implementations data server215may include additional, fewer, or different functional components. For example, functions of customer interface module440directed to customer device110and functions of agent interface module450directed to agent device120may alternatively be provided to their counterpart devices to synchronize presentation of data.

FIG. 5is a block diagram of exemplary functional components of customer device110. The functional components may be implemented by, for example, processor320in conjunction with memory330. As shown inFIG. 5, customer device110may include a browser510that includes a customer service plug-in520. The customer service plug-in may include a data module530, a command module540, a change simulator550, and a synch module560.

Browser510may include a web browser to access data server215. For example, browser510may support hypertext transfer protocol secure (HTTPS) communications to enable a user of customer device110to access data from data module410(e.g., via customer interface module440).

Customer service plug-in520may allow a user of customer device110to activate a common view, between customer device110and agent device120, for customer support. In one implementation, customer service plug-in520may include a user activation menu to allow a customer to initiate a common view with an agent. For example, in conjunction with a telephone call or chat session between the customer and the agent, the agent may request the user of customer device110to enable a common view. The user's selection of the common view option may be signaled to data server215to allow the agent to view the customer data from data server215.

In one implementation, customer service plug-in520may communicate, to data server215, in the request to enable a common view device information (as used, for example, by device correlator420described above) and network connection information (as used, for example, by network correlator430described above). Using this information (along with other information collected by data server215), customer interface module440may provide synchronized data to customer device110and agent device120.

Data mask module530may provide a selection mechanism to mask (or make private) particular data from the agent's common view. For example, a user of customer device120may select or highlight particular data fields shown on a screen of customer device120. Data mask module530may indicate the data selected for masking and signal to data server215to mask the selected data from agent device120. Data mask module may, for example, associate highlighted screen coordinates with particular data field or objects in the customers' graphical user interface. In one implementation, placeholders may be inserted into the agent view to maintain continuity with the shared data presentation.

Command module540may provide a selection mechanism to propose changes, to customer settings, that can be implemented by the agent and/or tested. Additionally, command module540may provide a user input mechanism to approve changes proposed by an agent in a common view setup.

Change simulator550may receive simulated data, corresponding to a proposed change, from data server215. In one implementation, change simulator550may include a banner or other notification (e.g., use of color, transparency, etc.) to distinguish a proposed/simulated change from real-time customer data.

Synchronization module560may apply algorithms to “speed up” or “slow down” presentation of data on customer device110to provide synchronized viewing of data with agent device120. For example, synchronization module560may apply lag times from speed tests, etc. to synchronization algorithms provided to customer device110by data server215. In another implementation, synchronization module560may apply algorithms to “speed up” or “slow down” data that is not actually presented by customer device110(e.g., on a display) but is used by customer device110for other purposes. For example, customer device110may use data from synchronization module560to propose and/or approve changes using automated systems that would not require visual presentation of synchronized data. Thus, data from synchronization module560could be applied directly into customer algorithms.

FIG. 6is a block diagram of exemplary functional components of agent device120. The functional components may be implemented by, for example, processor320in conjunction with memory330. As shown inFIG. 6, agent device120may include a common view application600with a platform module610, a command module620, a change simulator630, and a synch module640.

Common view application600may allow a user of customer device110to request a common view, between customer device110and agent device120, of customer data. Common view application600may receive, from data server215, an identical data feed as is sent to customer device110with adjustments for display timing being applied by either agent device120or data server215in some implementations.

Platform module610may receive session context information, from data server215, of the session between customer device110and data server215. Platform module610may use the session context information to simulate on agent device120the presentation layout of customer data on customer device110.

Command module620may provide a selection mechanism to propose changes, to customer settings, that can be simulated by data server215and/or approved by the customer. Additionally, command module620may provide a user input mechanism to approve/authorize changes proposed by a customer in a common view setup with the agent.

Similar to change simulator550, change simulator630may receive simulated data, corresponding to a proposed change, from data server215. In one implementation, change simulator630may include a banner or other notification to distinguish a proposed/simulated change from real-time customer data.

Synchronization module640may apply algorithms to “speed up” or “slow down” presentation of data on agent device120to provide synchronized viewing of data with customer device120. For example, synchronization module640may apply lag times from speed tests, etc. to synchronization algorithms provided to agent device120by data server215. In another implementation, synchronization module640may apply algorithms to “speed up” or “slow down” data that is not actually presented by agent device120(e.g., on a display) but is used by agent device120for other purposes. For example, agent device120may use data from synchronization module640to propose and/or approve changes using automated systems that would not require visual presentation of synchronized data. In such an example, data from synchronization module640could be applied directly into algorithms of service provider network230.

AlthoughFIGS. 5 and 6provide exemplary functional components of customer device110and agent device120, respectively, in other implementations customer device110and agent device120may include additional, fewer, or different functional components. For example, some functions of customer device110and agent device120described above may alternatively be performed by data server215.

FIG. 7is a diagram of exemplary communications among devices in a portion700of network environment200. Communications inFIG. 7may represent communications for implementing a common view for customer support of network services. As shown inFIG. 7, network portion700may include an optional chat session705between customer device110and agent device120. Chat session705may allow communication between customer105(FIG. 1) using customer device110and agent115(FIG. 1) using agent device120that may result in an eventual need to allow the agent115to view data presented on customer device. In another implementation, chat session705may be replaced with a telephone conversation between customer105and agent115.

Based on a selection from customer105(e.g., as guided by an agent via chat session705), customer device110may send a shared view request710to data server215. Shared view request710may include a signal to authorize presentation of a simulated view on agent device120. Shared view request710may also include session context information, such as a connection speed between customer device110and data server215. Shared view request710, with device/connection information, is shown as a single communication for simplicity. In another implementation, shared view request710may include multiple communication exchanges. For example, shared view request710may be responsive to a query initiated by agent device120.

Based on discussions with customer105(e.g., via chat session705or telephone), agent115may use agent device120to send a shared data request720to data server215. Shared data request720may include an identifier for customer device110(e.g., an account number or another identifier retrieved from customer105) and an identifier for agent device120to indicate data from which customer device session is to be shared with agent device120. In one implementation, shared data request720may also include device/connection information, such as a connection speed between agent device120and data server215.

Customer device110may send a data call730to data server215. Data call730may include a call for particular information to populate a web page associated with a customer campaign. For example, data call730may request account information associated with a particular service that the customer is offering via service provider network210.

Data server215may collect real-time data740from devices in public network230and service provider network210(not shown inFIG. 7). In response to data call730, data server215may provide the responsive data from real-time data740to customer device110as response data750. Similarly, based on shared data request720, data server215may provide the responsive data from real-time data740to agent device120as response data760. Response data750and response data760may include the same data from real-time data740; however the timing of presentation on each of customer device110and agent device120may vary due to differences in network connectivity. In one implementation, device/connection information from shared data request720may be provided to customer device110with response data750, and device/connection information from shared view request710may be provided to agent device720with response data760.

Customer device110may apply device and/or network correlation information to response data750. For example, customer device110may calculate a lag time between communications from data server215to customer device110and communications from data server215to agent device120. In one implementation, customer device110may apply predictive algorithms to “speed up” presentation of data on customer device110to synchronize presentation of data on customer device110and agent device120.

Additionally, or alternatively, agent device120may apply device and/or network correlation information to response data760. For example, agent device120may calculate a lag time between communications from data server215to customer device110and communications from data server215to agent device120. In one implementation, agent device120may add delays to “slow down” presentation of data on agent device120to synchronize presentation of data on customer device110and agent device120.

FIG. 8is a diagram of other exemplary communications among devices in network portion700. Communications inFIG. 8may represent communications for presenting and authorizing configuration changes to data for network services.

As part of an ongoing customer support call implementing a common view (e.g., as established in communications ofFIG. 7), an agent at agent device120may propose a change (e.g., a configuration change for the customer's campaign) and send proposed change810to data server215. Data server215may perform a validation and/or arbitration820relative to the proposed change. For example, data server215may apply proposed change810in a simulation mode to model the impact of proposed change810in service provider network210and over network230. In one implementation, proposed change810may be implemented within a restricted set of system resources, similar to a sandbox for software development, to simulate the effects of proposed change810. In another aspect, validation/arbitration820may include prioritizing and/or auctioning of network resources among multiple customers.

Data server215may provide the simulated effects of proposed change810to customer device110as simulated change830. Customer105may view the proposed change and its simulated effects on customer device110. Customer110may provide a feedback interface to approve or reject the proposed change. Assuming customer105provides user input to approve simulated change830, customer device110may send approval840to data server215to incorporate the configuration of proposed change810. Data server215may receive approval840and apply the configuration of proposed change810as an actual configuration change.

Data server215may continue to collect real-time data850from devices in public network230and service provider network210, including data as a result of the actual configuration change approved by approval840. Data server215may provide the data from real-time data850to customer device110as change data860. Similarly, data server215may provide the data from real-time data850to agent device120as response data870. As described above in connection withFIG. 7, customer device110may apply device and/or network correlation information to change data860, and agent device120may apply device and/or network correlation information to response data760, to provide a synchronized presentation on customer device110and agent device120.

AlthoughFIGS. 7 and 8are described in the context of providing a synchronized presentation of data, in other implementations the communications ofFIGS. 7 and 8may be used to provide instances of synchronized data that can be used (e.g., by customer device110or agent device120) for other purposes. In other implementations, one or both of customer device110or agent device120may be headless devices, such that customer device110or agent device120may apply synchronized data without an actual presentation on a display. Thus, one or more of customer device110or agent device120may obtain an instance of synchronized real-time data that can be used by processor320(FIG. 3) or another system without display by output device350. For example, customer device110or agent device120may include capabilities to perform an automated change negotiation without human intervention.

FIG. 9is a flow diagram that illustrates an exemplary process900for implementing common data for customer support of network services. In one implementation, process900may be implemented by data server215. In another implementation, process900may be implemented by data server215in conjunction with one or more other devices in network environment200.

Process900may include receiving, from a customer device, a request for real-time customer data for a service campaign (block910), and retrieving the real-time customer data (block920). For example, data server215may receive a request from customer device110to access service campaign data for the customer via a secure web page. Data server215may collect real-time data from devices in public network230and/or service provider network210for the service campaign running via a service provider network210.

Process900may also include sending, to a customer device, the real-time customer data for the service campaign (block930) and receiving a customer authorization to share the real-time customer data with an agent device (block940). For example, data server215may send to a customer device110the real-time customer data. In response to a prompt from an agent (e.g., via a chat session or phone call), customer device110may authorize a session to share the real-time customer data with agent device120. In one implementation, the authorization including session context information for the current session (e.g., a TCP/IP session) between customer device110and data server215. In another implementation, customer device110may provide the session context information to data server215separately from the authorization.

Process900may further include determining when there are predictive options for the real-time customer data (block950). For example, depending on the type of real-time data associated with the customer's service campaign, data server215may determine when some or all of the real-time data can be “sped up” using predictive algorithms to synchronize display timing with agent device110.

When there are predictive options for the real-time customer data (block950—YES), process900may additionally include sending, to the customer device, a feed of predictive customer data based on lag times indicated in the session context information (block960), and sending, to the agent device, a feed of the real-time customer data (block970). For example, data server215may determine that predictive algorithms may be accurately applied to data on the customer feed to synchronize display timing with agent device110. Data server215may determine a timing difference (or lag time) between the display of data on customer device110and the display of data on agent device120. The timing difference may be applied to the predictive algorithm to synchronize the display timing of customer data between customer device110and agent device120. Data server215may send a customer feed with the data based on the predictive algorithm to customer device110. Data server215may send the corresponding real-time data feed to agent device120.

When there are no predictive options for the real-time customer data (block950—NO), process900may further include sending, to the customer device, a feed of the real-time customer data (block980) and sending, to the agent device, the session context information and a feed of the real-time customer data (block990). For example, data server215may determine that no predictive algorithms can be accurately applied to data on the customer feed to synchronize display timing with agent device110. Data server215may send the real-time data feed to customer device110. Data server215may also send the real-time data feed to agent device120along with the session context information from customer device110, in order to enable agent device120to build an instance of the real-time customer data that is similar to a presentation of the real-time customer data on customer device110. In another implementation, data server215may calculate the timing difference (or lag time) between the display of data on customer device110and the display of data on agent device120and simply delay sending the data feed to agent device120by the lag time.

FIG. 10is a flow diagram that illustrates an exemplary process1000for implementing a common view for customer support of network services. In one implementation, process1000may be implemented by data server215. In another implementation, process1000may be implemented by data server215in conjunction with one or more other devices in network environment200. In process1000, assume an existing common view session between customer device110and agent device120(e.g., as established inFIG. 9) is already in progress.

As shown inFIG. 10, process1000may include receiving, from an agent device, a proposed change to configuration settings for the service campaign (block1010). For example, in conjunction with a service call from customer105, agent115may use agent device120to adjust configuration settings for a service campaign to address a question from customer105. In another implementation, the proposed changes may be initiated by an automated system associated with agent device120. The proposed changes may be provided to data server215.

Process1000may also include validating and/or arbitrating the proposed change to the configuration settings within service provider network (block1020), and generating simulated customer data based on the proposed change to the configuration settings (block1030). For example, data server215may receive the proposed changes from agent device120and may validate the proposed changes to determine, for example, if service provider network230resources and policies can support the proposed changes. Data server215may also arbitrate the proposed changes against changes from other customers of service provider network to determine if conflicts exist with other pending changes and to prioritize changes. Assuming the proposed change is allowed, data server215may generate a simulated data that incorporates the proposed changes.

Process1000may further include sending, to the customer device, a feed of the simulated customer data (block1040) and send, to agent device, the feed of the simulated customer data (block1050). For example, data server215may provide the simulated data to customer device110and agent device120. In one implementation, data server215may “speed-up” the simulated data to one of customer device110or agent device120to provide synchronized views (e.g., as described above in connection withFIG. 9). Alternatively, data server215may “slow down” the simulated data to one of customer device110or agent device120to provide synchronized views (e.g., as also described above in connection withFIG. 9).

Process1000may additionally include receiving, from customer device, approval of proposed change to the configuration settings (block1060) and applying proposed change to the configuration settings for the service campaign based on approval (block1070). For example, if customer105agrees with the proposed changes, customer105may signal through customer device110to accept the proposed change. In another implementation, the signal to accept the proposed change may be initiated by an automated system associated with customer device110. Data server215may receive the acceptance signal and may apply the changes as actual changes in service provider network210.

FIGS. 11A-11Care exemplary customer device interfaces for an exemplary use case according to an implementation.FIG. 11Dis an exemplary agent device interface corresponding to the customer device interface ofFIG. 11C. ForFIGS. 11A-11D, assume a customer is using service provider network210to manage a toll-free data campaign that supports marketing of movies and on-demand media through social media. In the toll-free data campaign mobile subscribers can access particular content (such as movie trailers) without impacting their monthly wireless data plan. In the toll-free data campaign, websites or mobile apps registered as toll-free content will be free for the consumers, and data charges can be billed directly to the sponsoring customer instead of the consumer's personal account. Links to the toll-free content can be shared, for example, through social media sites.

FIGS. 11A-11Cprovide a customer view1100(e.g., on customer device110) of real-time data1110that may be obtained from data server215. The customer view1100may be arranged, in this example, to track toll-free data usage for particular trailers leading up to a movie release date. Other information that is unrelated to the customer campaign (not shown) may be included elsewhere on a screen of customer device110.

Referring toFIG. 11A, assume the customer has a question relating to data1110and that a chat session is initiated with an agent, as shown in chat box1120. The agent may request access to the customer data (e.g., a common view) to help resolve the customer's question.

Referring toFIG. 11B, assume the customer has particularly sensitive data on the screen that the customer does not want to disclose to the agent (even though the data may already be stored within service provider network210). The customer may select a mask tool option1130from a user interface menu on customer view1100. Mask tool option1130may allow the customer to identify data fields to mask/hide from an agent during a common view. As shown inFIG. 11B, the customer may select a particular data type or field to mask using mask tool1140.

Referring toFIG. 11C, after identifying data to mask from the agent's view, the customer may select a share view option1150to initiate a synchronized common view of data1110. A shared view notification1160may be presented on customer view1100to indicate that data1110is being shown to an agent. Data fields previously selected for masking via making tool1140may be shaded or otherwise indicated via indications1170, so that the customer is aware of what data (if any) is not visible to the agent.

FIG. 11Dprovides an agent view1180(e.g., on agent device120) of real-time data1110that may be obtained from data server215. Referring toFIG. 11D, agent view1180may include agent information1182that may be relevant to the agent. Real time data1110may be the same as shown on customer view1100(FIG. 11C), but masked fields1184may be excluded. In one implementation, field headers and/or data place holders (not shown) may be used for masked data in agent view1180to maintain a similar data layout to that of customer view1100. As described above, data1110in either of customer view1100and agent view1180may be “sped up” or “slowed down” to permit a synchronized presentation on customer device110and agent device120without providing the shared screen access to the agent. One the shared data view is in place, the agent or customer may propose changes and share simulated views to resolve customer questions.

According to systems and methods described herein, a network device may send, to a customer device, real-time customer data for a service campaign running on a service provider network. The network device may receive a customer authorization to share the customer data with an agent of the service provider network. The customer authorization may include session context information related to the presentation of the customer data. The network device may determine if there are predictive options for the customer data. When there are no predictive options for the real-time customer data, the network device may send, to the customer device, a first feed of the real-time customer data and may send, to the agent device, the session context information and a second feed of the real-time customer data. In one implementation, the session context information may enable the agent device to build an instance of the customer data that is similar to a presentation on the customer device, without sharing the customer screen view. In another implementation, the session context information may enable the agent device and customer device to use synchronized real-time data for automated exchanges, such as change negotiations, with or without actual presentation of the synchronized real-time data.

The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while a series of blocks have been described with regard toFIGS. 9-10, the order of the blocks may be modified in other embodiments. Further, non-dependent blocks may be performed in parallel.

The word “exemplary” is used herein to mean “serving as an example.” Any embodiment or implementation described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or implementations.