NAME

CustomerSLA - extend SLAs by associations with customer companies

SYNOPSIS

This OTRS package adds the capability to associate SLAs with customer companies and automatically maintain service<-->customer user associations through them.

DESCRIPTION

To our understanding of ITIL, the SLA sits in between the customer and the service--no ticket for a service without a corresponding SLA that governs it.

The OTRS model already includes the association between the SLA and the service, but otherwise associates services directly to individual customer users. A commercial extension from OTRS.com (http://www.otrs.com/solutions/subscriptions/feature-add-ons/) is available to associate services with customers (i.e. the company/department/project/whatever the customer user belongs to), but still leaves the SLA disconnected from any customer.

With the popular CustomerIDs hack described in the OTRS admin manual, customer users already have the possibility to be in more than one "company". Applying the same approach to SLAs with a CustomerIDs SLA preference, the missing association can be established with almost no coding (just a bit on the presentation layer for rendering the associations to companies as a table, similar to associated services). Using this information, the customer user <--> service associations can be rebuild as follows: A service will be associated to a customer user when one of the customer IDs of the SLA matches one of the customer ID/IDs of the customer user. Note that this is a simple token match; there is no need that the referenced customer ID actually exist as a company.

When creating a ticket, SLAs are filtered according by associated (and already selected) service. With a small extension to Ticket.pm, SLAs can additionally be filtered by those that apply to the (already selected) customer user or that are not restricted by customer ID at all.

When a service has been made available through more than one SLA, it is up to the user through which SLA he/she wants to raise a ticket against it. An optional event handler can update the customer ID on the ticket itself to reflect the company/department/project for which the ticket applies, which can be useful for charging appropriately.

POST-INSTALLATION TASKS AND CONFIGURATION

CAUTION: Deploying this package requires advanced OTRS configuration and administration skills!

Extension of Customer User for Multiple IDs

See the section Customer with multiple IDs (Company tickets) in the OTRS Admin manual.

Ticket.pm Patch

The"weakest" part of this package is a patching to the (existing) Ticket.pm module with Ticket.pm.CustomerSLA.patch to restrict the SLAs that can be selected in a ticket to those that are applicable for the given customer user. All logic has been factored out into a separate module; the patch just inserts the minimum (module load + function call) to remain as portable across versions as possible.

  cd $OTRSHOME/Kernel/System
  patch < Ticket.pm.CustomerSLA.patch 
  # patching file Ticket.pm
  # Hunk #1 succeeded at 2609 (offset -23 lines).
  # Hunk #2 succeeded at 2637 (offset -23 lines).

Configure "Replacement" SLA modules through SysConfig

In Sysconfig, disable the "standard" SLA modules in group ITSM Core.

Frontend::Agent::ModuleRegistration:

disable Frontend::Module###AgentITSMSLA
disable Frontend::Module###AgentITSMSLAZoom

Frontend::Admin::ModuleRegistration:

disable Frontend::Module###AdminSLA

SLA-based updating of customer ID in ticket

To enable/disable the event handler which updates the ticket's customer ID from the SLA, use SysConfig, group Ticket, Ticket::EventModulePost###CustomerSLA (enabled by default).

Periodic Update of Service<-->Customer User Associations

Update of these associations based on SLAs currently needs to be performed in batch by running $OTRSHOME/bin/otrs.RebuildServiceAssocs.pl periodically (e.g. once a day). See embedded usage information in the script for options.

Optional Extension of Customer Company for "Contact" Field

As delivered, the package makes use of an optional CustomerCompanyContact field when rendering the associations between an SLA and customer companies. Providing this field is very much like the customization for the CustomerIDs in the customer user object.

Create a new row in the database:

  mysql> ALTER TABLE customer_company ADD contact VARCHAR (200);

Define the mapping in Config.pm (copied from Defaults.pm, 1 line added):

  # Override only the field mapping for CustomerCompany, leave rest at default
  $Self->{CustomerCompany}->{Map} = [
     # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly
     [ 'CustomerID',                 'CustomerID',   'customer_id',  0, 1, 'var', '', 0 ],
     [ 'CustomerCompanyName',        'Company/Project', 'name',              1, 1, 'var', '', 0 ],
     [ 'CustomerCompanyStreet',      'Street',       'street',       1, 0, 'var', '', 0 ],
     [ 'CustomerCompanyZIP',         'Zip',          'zip',          1, 0, 'var', '', 0 ],
     [ 'CustomerCompanyCity',        'City',         'city',         1, 0, 'var', '', 0 ],
     [ 'CustomerCompanyCountry',     'Country',      'country',      1, 0, 'var', '', 0 ],
     [ 'CustomerCompanyURL',         'URL', 'url', 1, 0, 'var', '$Data{"CustomerCompanyURL"}', 0 ],
     [ 'CustomerCompanyContact',     'Contact Email', 'contact',     1, 0, 'var', '', 0 ],   # (added)
     [ 'CustomerCompanyComment',     'Comment',      'comments',     1, 0, 'var', '', 0 ],
     [ 'ValidID',                    'Valid',        'valid_id',     0, 1, 'int', '', 0 ],
  ];

USAGE EXAMPLE

In our organization, we have services grouped into SLAs by target groups: Services that apply to everyone in the organization (e.g. internet, email, office), to specific departments (e.g. HR, sales/marketing, technical), or to specific projects (special tools, etc.).

When updating the customer users from data of the HR system by a nightly batch job, each customer user entry also gets a list of generated customer IDs based on departments.

The "OTRS admin role" then assigns SLAs to organization/s, departments, or projects. Subsequently, all customer user <--> service associations are maintained automatically by periodic execution of the rebuild script provided as part of this package.

KNOWN PROBLEMS

There is currently no support for printing associations between SLAs and customers.

There is no assistance for entering customer IDs, so data entry is to some extent prone to typing mistakes.

POSSIBLE FUTURE ENHANCEMENTS

Without committing to anything on this list, the following features seem worthwhile to be followed up.

Printing of SLAs
Propagation of a "charge code" to a ticket freetext field; useful together with time-tracking package.

TERMS AND CONDITIONS

AUTHOR

dietmar.berg@thalesgroup.com

OPAR - OPM Package ARchive

CustomerSLA