Introduction

This document describes

Once the ticket is created through the Request Schema, the agent fills in the fields to determine the nature of the problem. If the cannot solve the problem by using the integration of the solution explorer, then they escalate the ticket. Establish the type of ticket you're talking about using a dynamic menu. There are buttons next some of the fields the bring up possible values that can go in the field. That means these are required fields. If nothing is available, then it is not required (or another field must be filled in first). Once you've filled in the section, press "Send" to send the information to the Knowledge Base. This brings up an application Solution Explorer which provides a variet of solutions to the particular problem. Press "Retieve", brings back the solution with an ID. Bring this information back tothe ticket in order to record Category type - Subtype coorelation between - what's the solution that best fits the problem. The poit of

Ticket Creation

The following diagram and description present how a ticket is created after a help desk caller's ID is established.

  1. A caller gives his/her Juno ID (email address) to the helpdesk. The helpdesk agent enters this information into Remedy and presses return [enter].

    Note: a member's ID is his/her Juno email address. When a non-member phones, the helpdesk agent uses the caller's last name, first name and phone number as an identifying ID.

  2. The Remedy Client sends a message to the Remedy Server in New Jersey. These deamons field all the requests coming in from all the agents.

  3. A Remedy deamon launches protocol jrp1c which looks up the user ID on the UDB.

    The UBD returns the user's Password, Account Status and Service Level. This information is stored in the Junoms database. Later, using the user ID as a handle, Remedy requests all the data received from the UDB.

    In the event that the UDB does not return any information, Remedy concludes that the caller is not a member and sends an appropriate code back the the Remedy Client.

    Note: The Remedy Client can only receive data from a relational database via Remedy servers. A program can only return a status code. As a result, there is no easy way to get data back to the Remedy Client when one of the server deamons runs a process that is not a database command. The Juno solution is to load this data into a ducktape table in the Junoms database, then grab everything on the ducktape at the end of the process and bring it back to the Remedy Client.

  4. A stored procedure in junoms (rem_User) contacts Junoprod and Portal. through a proxy table that is set up in the Juno junoms. Junoprod returns the user's phone number and birthday, Portal returns the user's credit card number, billing address and billing phone.

  5. All data is returned to the Remedy Client.

  6. The agent verifes the caller's ID, and presses submit. The ticket is created.

Ticket Modification

Once the ticket is created through the Request Schema, the agent fills in the fields to determine the nature of the problem. If the cannot solve the problem by using the integration of the solution explorer, then they escalate the ticket. Establish the type of ticket you're talking about using a dynamic menu. There are buttons next some of the fields the bring up possible values that can go in the field. That means these are required fields. If nothing is available, then it is not required (or another field must be filled in first). Once you've filled in the section, press "Send" to send the information to the Knowledge Base. This brings up an application Solution Explorer which provides a variet of solutions to the particular problem. Press "Retieve", brings back the solution with an ID. Bring this information back tothe ticket in order to record Category type - Subtype coorelation between - what's the solution that best fits the problem. The poit of Ticket Status section
Account Information section.
Technical Support Ticket:

  • Category
  • Type
  • Juno Version
  • Operating System
  • Web Browser
  • Modem Speed
  • Modem Type
  • Dial Data
  • Symptoms
  • Goals
  • Work Log
  • Call Back Time
  • Solution ID
Customer Support Ticket
  • Category
  • Type
  • Juno Version
  • Sub-Type
  • Symptoms
  • Goals
  • Work Log
  • Call Back Time
  • Solution ID

Escalation

Agents who are unable to handle a particular problem can send the ticket to another agent who does have the ability to handle the problem. This is known as escalation. (Note: this is different from the Remedy product feature also known as Escalation). There are a number of ways for an agent to escalate a ticket using Remedy. These are:

  • Change the level (Agents belong to the following levels: 1- Technical/Customer Service Representative, 2 - Product Specialist, 3 - Supervisor, 4 - Juno Customer Support Staff, 5 - Juno Management).

    Upon changing the level, the Remedy backend (found in Junoms) checks if the agent is authorized to escalate to that level. If they agent is not authorized, s/he is informed that this is not a legal escalation. If the agent is authorized, the system looks for an agent with no assigned tickets belonging to the proper group (Customer Service or Technical Support) and with the proper skills to handle the problem.

    If there are no agents without any tickets assigned to them, the system looks for an agent with the fewest assigned tickets and the proper category/skills match. In the event that there is no proper category/skills match, the problem is escalated to the agent with the fewest assigned tickets.

    An email confirming the escalation is sent to all agents involved in the escalation.

  • Handpick a person. The system allows an agent to handpick the person to whom the problem will be escalated after checking that it is a legal escalation (agents can only choose a person at a valid escalation level who belongs to the proper group ).

The following flowchart depicts the different escalation checks performed by Remedy:

User Administration

User Data Tables

All data about Remedy users (these are Call Center agents and Juno staff(primarily Member Services)) is stored in four tables. Two of these are created by Remedy itself. The other set has been developed by Juno to help meet its unique needs. Juno uses data from all of these tables to identify and store information about its Remedy users.

The two Remedy tables are:

  • User_x - This table holds all the data entered through the Remedy system. This includes, login name, password, status, entry id, group list, full name, licence type, default notify mechanism, address, creator, last modified date, and create date.

  • user_cache - This table contains a copy of the fields in User_x, with an additional field to hold the name value of the group(s) that an agent belongs to.

The two Juno tables are:

  • USER_GROUP_LEVEL - This table contains each agent/user's user name, group number (701 (technical support), 702 (customer service), 703 (Juno internal), 1(administration)), skill level (1-5), whether or not s/he can take phone calls, whether or not s/he can get email, whether or not s/he can receive escalations. These fields are labeled User Name, Group Number, Skill Level, Phone, Email, Get tickets, Office).

    User-skill - This table contains the user name, and skills (what skills they have).

Table Updates

Juno has created proprietary tools for creating and updating the data in these tables. The tools are available in two different interfaces:

  1. Intranet-based
  2. Interactive
    • addUser - to add a user to the Juno data tables.
    • modUser - to modify a user on the Juno data tables.
    • delUser - to delete a user from the Juno data tables.
    • massAddUser - to add a number of users to the Juno data tables at a single time.
    • massModUser - to modify a number of users on the Juno data tables at a single time.
    • vrfystats - to view the statistics for a particular user.
All of these tools run off a common module called User-admin.pm.

The following diagram provides a visual representation of the Juno User Administration System.

CSR (Customer Service Representative) Signup

Overview

CSR Signup takes place when a potential Juno Member contacts a CSR in order to signup for Juno service through an 1-800 phone number. In return for providing his/her billing and shipping information, the Juno customer receives a Juno installation disk with a unique activation code already burned on.

Two benefits of this procedure are:

1) It simplifies the signon process by providing Juno with user information that would otherwise be entered during installation.

2) The activation code can be used to measure various user demographics if the disk is used to signup other users.

The CSR Graphical User Interface

This is the screen the Customer Service Representative works with while speaking with a Juno customer.

Field Description
MPV Marketing Plan Vector. Lists the different plans available to the caller. The CSR selects the desired plan from a drop down menu. Required.
Billing Information - to whom the bill will be sent.
First Name The customer's first name. Required.
Middle Initial The customer's middle initial. Optional.
Last Name The customer's last name. Required.
Address 1 The customer's street address. Required.
Address 2 Additional address information (ex: apartment number). Optional.
Shipping Information - where the disk will be shipped.
First Name The customer's first name. Required.
Middle Initial The customer's middle initial. Optional.
Last Name The customer's last name. Required
Address 1 The address to which billing information will be sent. Required.
Address 2 Additional address information (ex: apartment number). Optional.

Once the CSR presses "Submit" after entering the information, the system checks to see that all fields are properly filled in. The CSR receives a message if there are any errors. If everything is okay, the system generates an activation code which is then planted on the disk before it is sent to the user.

Searching Fields

In the event that a user calls back, the CSR can bring up that user's information by typing the user's data in a valid search field and pressing return. Valid search fields are:

  • Activity Code
  • Credit Card
  • Day Phone
  • Evening Phone

Pressing the "Search" button initiates a search on all fields with data in them and brings up the record with that exact data in it (as if an "AND" operation had been run on all the fields with data).

The Process

This is what happens from the time the customer's call comes in to the time the disk goes out:

  1. The customer's call comes in. The CSR enters the caller's personal data and presses submit.

  2. Remedy puts all fields with input data in a Sybase table located in Junoms. Within this table, the data is placed in a single row identified by a unique number.

  3. The Remedy deamons invoke the csrSignup process. As part of the invocation process, the deamons pass along the unique number (ID) which identifies the row in the table where the data is stored.

    csrSignup takes this ID, goes to the table, selects everything in the row and stores them in csrSignup's global variables.

    csrSignup checks that the values of all the variables are non-null and valid.

    Specific checks performed by csrSignup include: no missing fields, phone numbers are entirely numeric, the credit card is valid, FUSA checks, the credit card expiration date is valid.

  4. If any of the data is found to be incorrect: A) Remedy is notified. B) All entries in the table are deleted. C) CSR tries to get the proper information (Go to 1).

  5. If the data is found correct: A) csrSignup invokes an Oracle procedure which, B) generates a unique ID number for the particular MPV function (this is the next sequential number for the MPV).

  6. Using this ID, a function is called with generates an activation code.

  7. All the user information, including the activation code is inserted into tables in the Portal billing system. The tables are named:

    juno_t
    juno_acode_info_t
    juno_acode_cc_t
    juno_acode_nameinfo_t
    juno_acode_phones_t

  8. The associate row in the Junoms table is deleted.

  9. The activiation code is sent back to Remedy and the CSR alerts the user to expect the installational disk in a couple of days.

Archiving

Overview

Every time an agent opens a ticket s/he uses the GUI to create an entry in the Request Schema. The entry has attributes such as category type, sub-type, work log, solution, and current assignee that the agent modifies. Remedy takes the schema and maps it to a variety of tables in the database.

Eventually, the tables grow so large they become cumbersome. New ticket creation and ticket searches are slowed.

This problem is solved by archiving tickets over 60 days old.

The rest of this section describes the archiving process.

Archiving Issues

Implementation

Remedy calls an API to generate a Request ID the first time a ticket is created. The entry (the Request ID along with the data collected by the agent) is placed in the Request schema. Since Remedy manages the database for its users, the backend T & H table handling is hidden.

Problems arise because Juno would like to use the same Request ID as a lookup key for archived data.

Since it would be impossible to keep the Request ID unchanged if Remedy were to handle the archive process (Remedy would automatically generate a new Request ID while archiving the data), Juno must manually insert the archived data into the T and H tables - all the while remaining careful to touch everything that Remedy would have touched.