|
[Documentation Home :: This page]
|
Support Process Guide |
First analysis
The first analysis of the incident is done by the Customer Support Team assigned to the support of the live platform.
The Customer Support Team should define the supposed category of the incident :
Hardware ? If so, XandMail is not part of the support process.
Software ? If so, and the software is provided by XandMail :
Translation problem ? Check the resource files
JavaScript error ? Check the template files
Limitation problem ? Check the configuration
"Internal Server Error" page or core file in the cgi-bin directory ? Generate a truss/strace of the binary
Messages list is empty and an error is displayed ? Generate a truss/strace of the binary to confirm that the incident is on an external server + Check the external server
......
Following this first analysis, the Customer Support Team should have a clear understanding of how to describe and reproduce the incident.
Reporting the incident
Now that the Customer Support Team knows what the problem is and how to reproduce it, it can contact XandMail to report the incident.
In case of an incident, Customer shall :
Log a ticket using XandMail's How To Support Site with a precise description of the request or the encountered incident
Click on the Support Center link in the menu
Click Log Ticket
Type a clear subject
Describe the incident as clearly as possible
Choose the incident's urgency of resolution
Eventually add a small file that helps explain the incident
Click the Log Ticket button
Additionally send huge documents or screenshots by email to XandMail, indicating "ticket NNN" in the subject, where NNN is the ticket number corresponding to the incident.
Customer proposes the incident's urgency (or importance) during the ticket logging. Customer may, in addition, in case the incident is deemed urgent, call XandMail during XandMail's Business Hours to be certain that the problem description has been correctly received and is being processed.
Note : Business Hours means from 9:30 a.m. to 5:30 p.m., Monday through Thursday, and from 9:30 a.m. to 4:00 p.m. on Friday, Paris time, except for French public holidays.
Note : Incidents should only be reported if they occur on supported hardware / software. Check the Browser Support, Client platform support, Server support and Software support pages before reporting any incident.
What information should be reported ?
Date : Date when the problem was discovered if different from the report date
Reproducibility : Systematic or Intermittent
Product name : The binary's name or the product's name
Version : Binary version number (go to the cgi-bin directory and run the binary with the -i option or, for older binaries, the -v option)
Checksum : checksum value of the binary (run "cksum [binary_name]")
Platform : Platform name (sparc, linux ...) and OS version
Browser : The type and version of the browser used
Language / Charset : The language / charset used for message display and / or composition
Urgency : Correction urgency level (use the radio buttons)
Subject : Incident summary (one line)
Description : Complete description explaining how the incident occurs, how it can be reproduced (use a list of steps in the description) and what the actual and expected results are.
Attachments : Additional attachment to help reproducing and analyzing the incident (truss/strace file, MIME message, user's preferences file, configuration files, screenshots of the test steps' results in JPG format, ...) (Maximum size of attachment in the How To is 150 000 bytes - larger files should be sent by email to techsupport@xandmail.com or to your XandMail project mailbox)
Note: The incident should be described in English language.
Analyzing the incident
The new, not yet analyzed, incident tickets are managed on a first come first served basis, taking into account their urgency level.
The Support Team's intent is to rapidly manage the incident tickets, answering the information requests or requesting additional information for those incidents incorrectly described, not understood, or not reproduced.
XandMail may request the content of the configuration files, templates and logs of the incriminated version, or any other information deemed necessary in order to reproduce the encountered incident in XandMail's offices.
In the event that the incident cannot be reproduced in XandMail's offices, XandMail shall use an End User account provided by Customer on its test or live site and try to reproduce the incident on the test or live site.
XandMail may also request a full remote access to the Customer site's servers, in order to identify the encountered incident.
If the incident can be reproduced with Customer's version number (regardless of its release or build number) and cannot be reproduced with the more recent version number (regardless of its release or build number) already available to Customer as part of the Support Services Agreement (but not yet in use in Customer's site), Customer is enjoined to solve the incident by installing the more recent version. In the event that Customer does not want to upgrade to the more recent version, Customer can purchase from XandMail specific development services in order to receive a Patch Software Update for this problem.
For those incidents which are reproduced and recognized as application problems, our intent is to assign them a severity using the following definitions, and to return a message indicating the problem number in our database, its severity and final description.
Estimating the problem severity
Estimating the severity is done by XandMail's Support Personnel and is necessary since the support response will depend on that severity.
The problems covered by the Support Services Agreement can be classified under several severity definitions :
Critical Problem : means a systematically reproducible problem where a product functionality, as described in the documentation and the specifications, is not working at all and prevents the use of the product in its main functionality (for the mail application, prevents the end user from sending or receiving and reading messages; for the address book application, prevents the end user from managing his contacts; for the online storage, prevents the end user from storing files in and retrieving files from his online storage space; for the calendar application, prevents the end user from adding events and consulting the content of existing events).
Major Problem : means a systematically reproducible problem where a product functionality, as described in the documentation and the specifications, is not working at all or partially, but does not prevent the use of the product in its main functionality (for the mail application, does not prevent the end user from sending or receiving and reading messages; for the address book application, does not prevent the end user from managing his contacts; for the online storage, does not prevent the end user from storing files in and retrieving files from his online storage space; for the calendar application, does not prevent the end user from adding events and consulting the content of existing events), whether because that non-working function does not affect the main functionality or because a workaround was found.
Minor Problem : means a systematically reproducible problem where a product functionality is available and working, but not exactly as described in the documentation, or any other problem that cannot be placed in the Major or Critical categories.
Information Request : means a request for some information regarding a product (documentation, configuration help, "how to" request, ...).
Enhancement Request : means a systematically reproducible problem where a product functionality is available and working as described in the documentation and the specifications, but Customer would like it to work in a different way, or where a product functionality is not yet available and Customer would like to add it.
Examples :
1) Crash when opening a specific message
Reported by a few users only
The message in question is an information note sent by Customer to all users of the service, so all users will sooner or later have the problem
---> This is a critical problem
2) Crash when opening a specific message
Reported by a few users only
The message in question is a SPAM message
Temporary workaround exists (do not open SPAM messages !!!)
---> This is a major problem
3) Zipped Session : For big accounts, we have an ISE at the first click on "Redactar mensaje"
Does not affect all users but only some of them
Temporary workaround exists (archive the old messages in MBOX format and the problem disappears)
---> This is a major problem
4) Address book - Edit mailing list - The button has a "done" label instead of "save"
No major effect on the service to users
---> This is a minor problem
Defining the problem priority
Once the incident is correctly understood, reproduced and classified as a problem, XandMail shall assign to it a problem processing priority derived from the severity and the correction urgency proposed by Customer, using the following table :
| Urgency |
Critical |
Major |
Minor |
| High |
1 |
2 |
3 |
| Medium |
2 |
3 |
4 |
| Low |
3 |
4 |
5 |
The urgency (or importance) may vary depending on various factors, such as the number of users affected by a problem or their quality.
Examples:
1) Crash when opening a specific Newsletter message
Reported by a few users only
The message in question is a Newsletter sent by Customer to all users of the service, so all users will sooner or later have the problem
---> This is a critical and urgent problem : priority 1
2) Crash when opening a specific SPAM message
Reported by a few users only
The message in question is a SPAM message
Temporary workaround exists (do not open SPAM messages !!!)
---> This is a major problem of low urgency : priority 4
3) Crash when opening a specific SPAM message
Reported by one user only
The message in question is a SPAM message
Temporary workaround exists (do not open SPAM messages !!!)
User who reports this is the company director
---> This is a major problem of low urgency which is boosted to high urgency because of who the reporter is : priority 2
Solving the problem
Once the problem is reproduced, understood and correctly described in the Problems database,
Support changes the incident status to Waiting for Dev Fix
Support assigns the problem to the development manager
Development manager regularly builds the work schedule according to the problem priority and assigns problems to developers
Developer starts to work on the problem and marks it as Assigned
Developer marks problem as Resolved Fixed when it is fixed
When all scheduled problems are fixed, QA verifies the problem fixes (if possible) in XandMail premises
QA marks problems as Verified Fixed or as Reopened if the fix is not satisfactory
QA runs a regression plan to check that the main product features are still working fine after the problem fixes
Support prepares a delivery package for all the fixed problems and places it on the XandMail download site for Customer
Support prepares a Release Note describing the fixes and places it in the Documentation section of the How To
Support changes the incident status to Solved, which sends a notification message to Customer Support Team
In the event that Critical or Major problems cannot be corrected in XandMail's offices, and that Customer cannot provide XandMail with a full remote access to its servers, Customer and XandMail may agree upon a technician visit to Customer's site, considering that this visit is part of a technical assistance, as defined in the TECHNICAL ASSISTANCE section of the Support Services Agreement.
Delivery description
In case of a priority 1 or 2 problem, the deliveries will be :
A temporary bypass solution, if possible.
If Customer's currently installed Software release number is less than that of the coming Minor Software Update, a Patch Software Update (delivery is identical to Customer's version, plus the fix).
If Customer's currently installed Software release number is identical to that of the coming Minor Software Update and no temporary bypass solution exists, a Patch Software Update.
If Customer's currently installed Software release number is identical to that of the coming Minor Software Update and a temporary bypass solution exists, the next Minor Software Update.
In case of a priority 3, 4 or 5 problem, the deliveries will be :
A temporary bypass solution, if possible.
If Customer's currently installed Software release number is less than that of the coming Minor Software Update, a Patch Software Update (delivery is identical to Customer's version, plus the fix).
If Customer's currently installed Software release number is identical to that of the coming Minor Software Update, the next Minor Software Update.
The difference between priorities 1 and 2, and between priorities 3, 4 and 5, lies only in the differing maximum durations for each delivery. See the Support Services Agreement for those durations.
Closing the incident
Once Customer is notified of the incident's status change from Waiting for Dev Fix to Solved,
Customer Support Team retrieves the delivery and installs it on its Test platform
Customer Support Team verifies the problem fixes
Customer Support Team marks incident as Closed after successful verification of the fixes (if not verified, change the incident status back to Open)
Customer Support Team updates the live platform to reflect the same fixes verified on the Test platform
