VISION: To exceed customer expectations with world-class service achieved through seamless teamwork and constant innovation.

MISSION: To develop and deploy leading edge software service processes defined and driven to exceed customer expectations.

GOALS/VALUES:

Commitment - Always do what we say we will do. Keep all commitments made to our customers.

Respect - We will respect all people we work with and will value differences in background, experience and style.

Collaboration - Working together with our customers and co-workers in DI, maintain focus on delivering quality solutions, and continually look for ways to improve our product's usability, serviceability and reliability.

For all problems we work on - Take responsibility; Demonstrate accountability; Exercise initiative; Deliver outstanding results.

Secure EMail, Inc. has built its product, Secure Email, based on the fact that when an email is sent, copies of it reside on the sending computer, every server it crossed getting to its destination and on whatever backup tapes are made of those server logs. It is certainly possible an email sent from a company in New York to its office in San Francisco could exist on two computers, sender and recipient, and on three servers in between, with backup tapes for each computer and server. Even when sender and recipient manually delete an email from their trash files, the path to the email is destroyed, but the email text exists until over-written. Electronic forensic researchers are able to analyze hard drives and locate email messages long after users think they have deleted them. Server back up tapes are archived for varying lengths of time from a year to forever, and worse, are out of the hands of the companies involved. The Internet service providers who own and archive these back up tapes have no reason to either destroy them or withhold them from legal scrutiny.

The Secure EMail system’s greatest selling point is that using the system protects a company from, a) inadvertently keeping potentially incriminating emails in its archives or having them found on other people’s computers or back up tapes, and b) spending possibly millions of dollars researching extensive email archives in response to a legal request. If there are only 120 days of email archives available, research costs will be much lower than if there were three years or eight years of emails to be sorted through. At the same time, once a court order is issued to preserve electronic documents, the Secure EMailAdministrator tool can be configured to preserve exactly which existing and future emails should be saved.

A Secure Email message is encrypted using the latest and most powerful encryption methods available before it is sent, and decrypted after it is received. Copies of the message left on sender and recipient computers, and on intermediary servers are all encoded. When the key is destroyed, the text of an email, whether found on the sender’s machine, server tapes or recipients’ machines, is an unreadable jumble of letters and numbers. See http://secureemail.cs.codebreaking (I made this URL up) for an analysis of how difficult it is to decipher even one Secure Email message.

Secure Email is an evolving product. The basic SecureEmail function is a solid piece of work and we have a few nice features. As we add features, bugs will appear. We try to catch them in testing, before release, but due to the huge variety of computers and software applications Secure Email software has to co-exist with, it is inevitable an occasional bug will pop up.

If a bug slips through our exhaustive testing process, we try to catch it early as possible via customer complaints. If it’s a non-fatal flaw, and the great bulk of users can continue to work normally, we integrate the fix into the next scheduled product release. If a bug disrupts the work of a significant number of users, we work to fix the bug and, where practicable, send out a quick fix or patch, then include the permanent fix with the next release.

The Secure Email system should be invisible or nearly invisible to users. When a user sends a Secure Email message, he or she opens a “New Message” screen, type headers and text, then hits send, just as with any email. A recipient with SecureEmail software opens an incoming Secure Email message as they would any other message.

Click on Tools, Options and the Secure Email tab to display these settings. These settings will generally be unchangeable for users, but are important for diagnosing certain problems. The server setting indicates the key server used to create Secure Email messages, the zone setting indicates the server segment each company uses, and the port setting indicates the port by which users access servers.

To reply to Secure Email messages read via a browser window, the recipient can still just click reply on the original email window, but to include text from the original message, they will have to cut and paste from the browser window to the reply email.

Clicking on this button check the Secure Email Administrator tool for updates. Typically, machines automatically refresh upon opening Outlook, so using the refresh button is not needed unless users are specifically told to refresh their settings.

The company administrator may allowed users the option of sending single Secure Email messages out with a different length of readability than the default, or to send a single message without Secure Email. These options are exercised by opening a new message, clicking on Tools, then on Secure Email Options. A drop down window appears with a set of choices. This setting is for the immediate message only and does not affect the main settings accessed via the Tools>Options menu in the main Outlook window.

The Customer Support department has developed a comprehensive list of frequently asked questions. Every DI Support Department employee should be familiar with the answers to these questions. Like the product it self, this list is evolving, so we would like to add questions as they arise--feel free to ask about anything you feel is unclear. See http://secureemail.cs.faq for the list (I just made up that URL, the list currently lives only on my computer).

The Secure Email Administrator Tool is the control panel used by a client company’s system manager to control how Secure Email messages are generated and rendered unreadable. The “Default and Arbitration Rules” are set according to company policy. “Special policies” can also be created to give certain groups greater or lesser flexibility in using Secure EMail.

By way of these policies, the administrator implements her or his company’s desires in terms of how long an Secureg Email message exists in readable form, which groups of people can send messages without using Secure Email when they want to, and which groups of people can control how long their SecureEmail messages last.

For instance, it is possible for a company administrator to set the rules so that that every email sent out on the company email system will be sent as a Secure Email message, regardless of the senders desire, and that every Secure Email message will become unreadable after 90 days (or 5 minutes, or 120 days—there are a number of choices).

It is also possible for the administrator to set up special policies allowing different groups to send emails which are not Secure Email messages, or to allow certain senders to set their own length-of-readability for all their own Secure Email messages or on a message-by-message basis.

As an example, software developers often communicate with each other dozens of times per day via user groups, and many developers prefer to use a mail reader appropriate for Unix or Linux, thus incompatible with our current product. Since typically, the discussions carried on in these user groups are of a technical nature, company executives may feel they pose little legal risk to the company and may be of use far beyond the 120-day readability assigned to other departments’ mail. For these reasons, the company administrator may decide to allow developers and other technical groups to decide when they will or will not send Secure Email messages.

One critical aspect of the Secure Email Administrator Tool is the subpoena function. This function is used when a company using the Secure Email system is served with legal documents to produce old email messages and to preserve new messages as they are created. The Secure Email Administrator Tool allows the company administrator to set date parameters to preserve existing Secure Email messages from becoming unreadable, and to keep new Secure Email messages available for the legal processes. The system can be set up in such a way that specific users’ email is preserved, while Secure EMail messages not covered by the legal demand will continue to become unreadable as scheduled.

There are a number of features under development and as features are added and bugs removed, the product number undergoes changes to help track which version of the Secure Email software users have installed. The numbering system works as follows: The whole product is named Secure Email 2.1, and the client portion is currently numbered 1.5, with the end user software gaining a new point each time it is updated for release. Thus the current release will is titled 2.1.1.5, the next update will be 2.1.1.6, and so on.

Anyone without Secure Email software who receives a Secure Email message can still read it via a browser window. The recipient will receive an email informing them they have received a Secure Email; message and to click on the icon within the notification. A web browser window will open displaying the sender’s message.

Anyone with Secure EMail software can open a Secure EMail message like any other email message, but they cannot SEND a Secure EMail message until they have registered with the server.

The DI Internal TS department will follow traditional lines of organization with first line and second line technical support. For the time being, calls requiring third line support should probably be handled by current DI developers.

In addition to handling incoming support calls and emails, the TS department will supply technicians to large-scale installations via our sales department and partner organizations (Ernst and Young and Compaq come to mind as examples).

The first line support personnel will handle calls from end users whose needs can be handled via same-call advice and trouble shooting, and who can be serviced via return calls after some research. Primary responsibilities include collecting basic data from callers to be used by second- and third-line support reps; should the need arise, making the first response to incoming email customer complaints regardless of level of service needed to resolve the complaint; tracking open complaints as assigned AND AS NEEDED by the support department in general.

Second line support reps will be responsible for helping customers with issues requiring a high degree of technical knowledge and helping system administrators who are installing, modifying or changing tool settings for Secure Email. In addition, second line reps should be trained to help with technical questions dealing with the DI key servers located on customer premises.

Technical Support reps will travel to customer locations to assist with large installs and to train company personnel in procedures to use Secure Email effectively.

They will be knowledgeable about all aspects of Secure Email, from assisting with end-user software use to setting up keyservers on-site. These positions will be critical to convincing client system administrators they will receive a high level of support from DI. TSRs may be required to stay on location for several days while installing servers and downloading software is in process. TSRs will also work closely with DI’s partners to integrate DE with existing and new mail systems. ,

A critical element in developing a referential database will be to train all users of whatever software we purchase to use the same phrase to describe the same thing. Since we’ll be inserting solutions to problems in our knowledge database, we will establish a dynamic glossary of phrases to be used to describe problems, making searches more effective. Some of this phrasing can be determined from current usage, but other phrasing will evolve as we determine what incidents will be listed in the data base.

As a developing product it is important that customer feedback be classified properly upon receipt, analyzed for patterns, and channeled through the marketing and engineering departments for modification in the end product. It is critical for all TSRs to report trends as fast as possible to both departments for damage control and product improvement. In addition, as receivers of information, TSRs will attempt to elicit comments on which current features are of the greatest value and which potential features are most desirable to client companies.

The TS department will initially maintain live support between 6 a.m. and 6 p.m. PST, with on-call personnel at all three levels available 24x7. As DI rolls out world wide, the TS department will very likely advance to 24-hour live support. Every effort will be made to accommodate special scheduling needs, but flexibility in scheduling and on-call duties will be required of all department members.

DI provides what will eventually grow to be a universal service, and we ultimately expect to service millions of customers around the world. It is essential we treat each user as our most important client. To this end, technical support representatives are expected to cheerful in the face of frustration, attentive in the face of a heavy workload and professional in adversarial situations. Simply put, we must be the best support organization our clients will ever deal with.

There are two sides to the Customer Data issue. The first is data gathered from DI internal sources. The second side concerns gathering data from customers.

Having up-to-date accurate information on which companies are new, which are experiencing problems, which are using tried-and-true versions and which have new release versions of Secure Email is critical to proper technical support. A large number of our users will be non-technical types. Administrative, clerical, sales and marketing personnel comprise the bulk of most company’s workforce, and are also the groups most likely to need technical assistance. Our ability to stay a step ahead of user needs allows us to give better service with a minimum of time wasted while the user clicks around searching for details on what DE software their company is using.

Gathering data from customers will be a high priority for two obvious reasons: a) to ensure we provide proper solutions and b) to provide our marketing department with grist for its mill. To that end, all fields in our Support database should be filled out as completely and accurately as possible. It is no good assuming user Z has version 123 just because users A through Y have it. We expect to deploy several versions of Secure Email between April and August of 2000, meaning that we will have to support each version with each client. Ideally, we will update clients with new software as it comes out, but given that this is a vacation period it is inevitable some will miss the company-wide rollout.

Escalation of calls to a higher handling priority, second line of technical assistance or manager intervention should be handled with dispatch.

Upgrading calls to priority one or critical level should be made when the problem is occurring at the decision-maker level, when a work stoppage is occurring or when a company is in a critical rollout phase.

One of the primary functions of first line assistance is to assess the degree of technical knowledge needed to solve whatever problem is being dealt with. As TSRs become more experienced, when to upgrade to second line reps will be come apparent. Since there will naturally be fewer second line reps, problems should be upgraded to them only when necessary, but it will be our policy in the beginning to upgrade when in doubt. This will allow us to achieve the highest possible level of service to the customer, as well as to orient all TSRs, first and second line, to the spectrum incoming problems and degree of technical help required to solve each incident.

As time goes on, first line reps will become more familiar with common problems, thus able to handle the issues without upgrading. In addition, as the customer base grows, second line reps will be needed to handle server and large scale deployment issues, which will require substantially more time than single-user calls.

Anyone with customer support experience knows a percentage of callers will not be pleased with their initial contact. Typically, this occurs when an immediate solution is unavailable for the caller’s problem and when the caller feels as though they a) have enough clout to force the issue or b) they feel they are not receiving the proper care, or c) both.

Quite often a simple change of personnel will satisfy an irate customer, if the second TSR handles the call efficiently and professionally. When a caller becomes irate, for any reason, they should be offered the option of speaking to a supervisor. There are two problems to avoid while handing off a caller: leaving the customer with the feeling that they are causing a problem, and leaving them with the impression they are being passed off because the rep doesn’t want to deal with them. Before handing off an irate caller, the original TSR should make an effort to convey a sense of concern for the caller’s issues and a desire to make the caller happy.

(Waiting for software)

Metrics are under consideration and, to a degree, will be based on the capabilities of the ACD and problem management systems we buy. The following list covers accepted baseline measurements we’ll use to determine our success.

Service-related measurements should determine responsiveness by TSRs, problem resolution time, technical knowledge of representatives, concern shown towards customers, and overall customer satisfaction.

Draft outline of methods used to determine Technical Support department effectiveness

• Customer satisfaction quotient extracted during customer contact calls and emails.
• Product-related measurements such as ease of use and (other questions Engineering might like to add).

• Responsiveness by telephone: measured by length of time callers wait on hold and by the number of callers “dropped” (those who hang up before being helped).
• Responsiveness to Support email inquiries: measured by time lapse between receiving the message and first response, then by the length of time to final resolution.

• Number of problems vs. number of calls needed to resolve the same problem.
• Number of calls from any given company vs. number of installs to determine who needs more training or is having systemic difficulties with the install.
• Call volumes - by time of day to assist in TSR scheduling, provide data to engineering on server load issues and gather general demographic/use information for marketing.

• Fix Cycle measurement: based on the length of time from when a complaint is received to the point when we have supplied a user-satisfactory fix.
• Quality Measurement based on the number of fixes provided, or problem tickets opened, against a specific release (Engineering--any other measurements you can think of?)
• Targets of opportunity: close analysis of data (feedback) as it comes in to determine additional measurements we can use to improve service in problem areas.
• Request a call back if the customer would like to further discuss issues (proposal on routing of these call backs to come).
• Comment Section for direct, casual feedback from users to help determine ground-level perception of out product.

Results should allow TS management to measure the quality, speed and effectiveness of support. Results will allow managers to determine in which areas clients need additional training during deployment, in which areas TSRs need additional training, suggestions for improving the product, peak call times, degree of product use, customer perception of value of product and provide other marketing data.

To be added as developed.