ArsDigita Archives
 
 
   
 
spacer

Customer Service Module Design

by Sarah Ewen

I. Essentials

II. Introduction

What the Customer Service Module is For

The customer service module has been designed to provide support to customer service representatives, whose responsibility it is to deal with customers who raise issues or problems, and help to resolve them. It will ensure that your customers are not deserted. Using the customer service module prevents a customer's request for information or help from ending up `lost in the system' or neglected.

To achieve this, it provides two main services:

  • It enables customer service representatives to give prompt, personal responses to customer inquiries, thus improving customer satisfaction, loyalty and retention.

  • All interactions are logged, thus patterns in customer feedback can be seen, and decisions on how to improve the service can be made accordingly.

What It Isn't For

This module has not been designed to monitor customer activity on your web site. If you want to know which areas of your site are not being visited, or which areas of your site are more popular, you should use Clickstreaming.

Another thing it doesn't do is calculate who your most valuable customers are. This is provided by the Customer Relations Management module, which allows you to define user states (e.g. `good customer', 'community participant but non purchaser') to represent your customers. It is very useful for dealing with your customers in bulk. This module is aimed at individual customer care and follow-up, when customers want to talk to you.

III. Historical Considerations

Like the ecommerce module, this was developed based on a combination of client specifications and experience gained when running client sites.

The module was written to work in tandem with the Ecommerce Module, and so was designed with dealing with customers on an ecommerce site in mind. However, it is a very useful module in its own right, and has been used in web sites (such as away.com) completely independently of ecommerce.

Even on a non-ecommerce site customers may have inquiries about how to use the site, or wish to request new features. Looking after the people who use your site is important on any web site.

IV. Competitive Analysis

Most web site packages are more likely to provide easy integration into call center software, which tends to be highly proprietary. The ACS customer service module offers the advantage of being very able to recognize your users, as there is a good chance that they will have registered with you to take advantage of all the online community services that your site has to offer through the rest of the ArsDigita Community System.

Rather than having to rely on more third party closed-source software, using the ACS customer service module provides a stable customer service support package which, as it is open source, can be customized any which way you want, if you have specific needs.

Additionally, the reporting functionality of the ACS customer service module can act as a much more powerful analytical tool, as the module can take advantage of seamless integration into the rest of your site and return additional information about your users, such as their recent postings in discussion forums, the last three items they purchased, or when they first visited a new area of your web site.

Together with the CRM module and the ecommerce module, the ACS compares very favorably with any large software package, only it offers the extra reassurance of the reliability, maintainability and extendibility that only an open source system can offer.

V. Design Decisions: How Things Work

Issues and Interactions

An issue is created when a customer contacts a customer service representative about something, or vice versa. Every time a customer service representative contacts a customer, or vice versa, an interaction has taken place. It may take many interactions before a customer is happy that their issue has been worked out.

Tracking issues and interactions individually is a good idea. It gives the site owner knowledge about how long it takes for a customer service representative to be able to help a customer through their problem, and which of those problems prove to need the most interaction. Because the rep also logs the information that they required to resolve the problem, it also provides some feedback about what kind of information needs to become more accessible to the site users.

Interactions are automatically recorded whenever an email is sent to customers; however, when the customer contacts a representative, the interaction has to be logged by the representative.

Issues have two states:

  1. Open (unresolved)
  2. Closed (resolved)

Customer service representatives mark issues as closed either when they record the last interaction in the issue, or at a later date, by editing the issue. An issue can be re-opened if it was accidentally closed before resolution took place.

Not all users who contact a representative will have registered with the site. Every time an action takes place, the representative must enter as much information about the user as possible so that they can be recognized if they have been profiled in the customer service module before. Users who have registered with the site are identified by their user_id. Users who have not registered are profiled using other attributes such as:

  • Email address
  • Name
  • Zip code
  • Whatever the customer service rep can find out about them (other_id_info)

Because customer service reps will spend pretty much all of their time logging records of interactions with users that have just taken place, it is important to make this process efficient and as painless as possible. This is the idea behind using picklists. Customer service reps pick out the issue / information / method of communication out of a drop down list, which saves them a lot of typing and tedium.

Similarly, reps will spend the rest of their time patiently writing out emails to the customers. A large number of these will have a common theme, or include company-endorsed phrasing, mottos, and statements. Hence the canned response. It makes better sense than using templates because, if an interaction is addressing two issues, the rep may want to make use of two separate phrases concerned with different matters. Inserting a canned response instead of selecting one template makes this possible.

VI. The Data Model

Integration with the Ecommerce Module

Due to the customer service module's past link to the ecommerce module, the data model is defined in the same file as the ecommerce module (ecommerce.sql). It doesn't rely on any of the ecommerce tables, however; the only references to the ecommerce module are the columns order_id and gift_certificate_id in the ec_customer_service_issues table. These should reference the ec_orders and ec_gift_certificates tables respectively. You can drop these references if you don't want to load the ecommerce module.

Significant Tables

  • ec_user_identification stores the profiles that are created for both registered and unregistered users. A user that already has a profile, but isn't recognized, will have a new profile created for them. Note the field other_id_info for storing miscellaneous information about them that the customer service rep manages to scavenge about them.
  • ec_customer_serv_interactions stores each and every interaction between a customer service rep and a customer.
  • The view ec_customer_service_reps is updated to keep track of all those users in the users table of the ACS who are customer service representatives. Theoretically, someone could be both a customer and a customer service rep.
  • ec_issue_type_map keeps track of which category an issue belongs to. If an issue doesn't have a category, it is mapped to the `uncategorized' issue.
  • ec_customer_service_actions is important because of the field follow_up_required. If the issue will require more activity on the part of the customer services department, this is where the details of the work required will be stored.
  • ec_picklist_items stores all the items that are available in the representative's picklists.
  • ec_canned_responses keeps hold of all the canned responses the customer service reps can choose to insert into their emails. The one_line field is the description that is displayed in the picklist that the rep sees at the bottom of the web page.

VII. Transactions

Simple issues

If a customer service rep sends out an email to a customer, an interaction has occurred and must be logged. This is an example of a simple issue which can be opened, logged and closed all in one atomic transaction (there is a procedure for this: ec_customer_service_simple_issue).

More complex issues

If a customer raises an issue, several rows may be inserted into ec_customer_serv_interactions before the issue is closed and close_date can be set.

Most transactions in this module are straightforward. The important thing to note here is that all interactions with customers are logged and associated with issues.

VIII. API

The following procedures are available in /tcl/ecommerce-customer-service.tcl:
Function Name
Returns the email address to use as the `from' field in emails. ec_customer_service_email_address
Returns the email address of the customer service center, and a url for them (to be used at the end of customer service emails). ec_customer_service_signature
Creates an issue, interaction, action - and closes the issue immediately. ec_customer_service_simple_issue
Finds all the issues that have been raised/discussed by one customer. ec_all_cs_issues_by_one_user

IX. User Interface

Most of the significant user interface issues have already been discussed as features within the rest of this document.

The picklist management tool and the canned responses were both developed to improve the quality of the interface for the customer service rep to save them time and effort.

The customer service reports and statistics page offer links to all the reports that can be generated by the customer service module, but more importantly displays key statistics, so that customer service representatives can instantly see if there is a particular report that would be interesting to view due to recent activity. This extra information makes it much easier to determine which reports are worth reading whilst not interfering with the purpose of the index page.

X. Configuration Parameters

The customer service parameters are defined in the ecommerce section of /web/yourserver/parameters/yourserver.ini.([ns/server/atst_sarah/acs/ecommerce])

Set CustomerServiceEmailAddress to the email address that the emails from customer service representatives should come from.

Other things to configure

There are three utilities which the customer service module requires in order to operate:

  • Qmail must be installed in order to be able to send emails to customers
  • The spell checker tool must be installed.
  • The zip codes table.
    The location of the customer is determined using zip codes. Either find a copy of the zip_codes table to import (ArsDigitans know where to find it but unfortunately we can't redistribute it because it's licensed), or delete the little bit of code that uses it.

XI. Acceptance Tests

  • Go to https://yourserver/admin/ecommerce/customer-service/ -- or http:// instead of https:// if you don't have SSL -- and add an interaction (if you get an error on interaction-add-2, that may mean the zip_codes table hasn't been loaded). Use the email address of an existing user. All the other information can be garbage. Return to the main customer service admin page and find the issue you just created (look under Customer Service Issues). When you're viewing the issue, click Send Email at the top. Try sending email.
    • Possible problem #1: spell checker doesn't exist.
      Solution: install spell checker (tools module).
    • Possible problem #2: can't send email.
      Solution: install qmail on your machine.

XII. Future Improvements/Areas of Likely Change

The reporting and statistics pages could be made much more powerful by taking advantage of the potential wealth of information that the ACS can build up about individual users as they interact with different areas of the site. At present, this is not taken advantage of.

This module could also potentially be integrated into the CRM module, as they offer two different kinds of functionality in a related area.

XIII. Authors

The customer service module was designed and implemented by Eve Andersson.

The original documentation was also written by Eve; it has been updated, reformatted and brutally embellished by Sarah Ewen.

XIV. Revision History

Document Revision # Action Taken, Notes When? By Whom?
0.1 Creation, based on /arsdigita/doc/ecommerce-customer-service and /arsdigita/doc/ecommerce-operation 10/12/2000 Sarah Ewen
0.2 Reviewed after receiving comments from Eve Andersson 10/16/2000 Sarah Ewen

acs-docs@arsdigita.com
spacer