Technician Assignment Logic in LiveTime ITSM

The logic behind Technician Assignment within LiveTime is more than the application basing the allocation on the Technician location, load or skill set, as more extensive parameters are considered when routing requests to Technicians. By understanding the variables within the assignment process, Users can configure the system to better reflect the workflow of its service support Team environment.

When a request is logged, the Team is selected based on the SLA and Workflow State of the request.

After the Team has been assigned to the request, the application:

1. Checks if the Team has escalation layers, and validates the capability of Technicians in Layer or Group associated with the request.
2. To make an assignment within the layer or group, the system checks if Technicians are assigned areas of specialty – Skills or Classifications. If so, the system matches the Classification of the request with the Classifications supported by the Technician.
3. If multiple Technicians are assigned the relevant Classification, or if specific Classifications are not assigned to the Technicians within the Team, then the system verifies if Team members have been assigned to support specific Organizational Units. If so, the application will match the Organizational Unit of the Customer to the Technician.
4. If the Team “Live Priority” feature has been enabled, the system checks for Team Technicians logged into the application. If multiple matches have been made between the Technician Skills and the request’s Classification, and the Org Unit of the Customer and Technician, the system checks for technicians logged into the application. However, if no match is made between the Skills and Organizational Unit, it will still check for the logged in User if the Live Priority Team functionality is active.
5. If there are multiple valid Technicians based on Skill, Org Unit and/or Logged In User, the application will allocate the request to a Technician with the lightest request load.

It should be noted that if the Technician Define Work Hours option has been enabled in the Admin>Setup>Privileges>User, the hours of work MUST be defined within the Super>User>Users>Schedule tab, otherwise the system will ignore the Technician Assignment logic and automatically allocate new requests to the Team Lead.

Service Manager and Workflow States

Within Service Manager the pool of Technicians that can be assigned to a request is increased by the OLA or Underpinning Contract assigned to the Workflow State of the request.

Service Manager allows Workflow States to be governed by internal or external contracts, known as OLAs or Underpinning Contracts, respectively. OLAs can be assigned to different support Teams, which means if the Team changes as a result of the Workflow State change, the request may be routed to a whole new pool of Technicians.

If the Workflow is supported by an Underpinning Contract, the request is assigned internally to the responsibility of the Service Level Manager.

Self Assign Option

The Self Assign functionality allows the application to override the business logic of request assignment. This feature enables the automatic allocation of requests to the Technician who creates the request. A Supervisor User can activate Self Assign for requests on a per Team basis, within the Team Information screen.

Request Queues

That about covers the automated routing of requests, but support Teams who prefer to create a queue or holding bay for newly created requests, are also catered for within the system.

Queues are activated on a per Team basis. This means, where one support Team may use the automated routing process, another can create a holding bay. The holding bay allows Technicians to choose their jobs from the Queue, as opposed to having requests automatically assigned by the system.

The Administrator User can activate the Request Queue feature in the application Setup. The Supervisor User then enables the option within the Team Information screen, as required. New requests assigned to a Team with this preference enabled, are assigned to the System User. To access requests held in the Queue, Technicians use the Request Queue Filter within the Home Tab.

The request can then be re-assigned to a specific Technician within the Summary Tab of the request.

Exchange Email Integration

Microsoft Exchange is a popular group messaging and collaboration system. It provides users with email, contact management, calendaring and scheduling. As part of LiveTime’s commitment to enterprise integration, this article guides users through the integration of LiveTime with Microsoft Exchange email server for complete closed loop email management.

The following guide is based upon integration with Exchange 2003 or later and demonstrates how to enable IMAP or POP3 for access by LiveTime for auto request creation from users. Please note that MSExchange 2007 has known problems with supporting the IMAP protocol, and so is not recommended for users of that version.

Creating the Inbox

Load up the Exchange Management Console and Select Recipient Configuration and Click ‘New Mailbox…’ from the Actions list as shown below.

For User Information, enter the following details and click ‘Next >’:

Check the Organizational unit is correct.

First Name:
Support
Last name:
Inbox
Name:
Support Inbox (this may automatically be populated)
User logon name (User Principal Name):
support

Select the appropriate domain from the drop down if multiple domains are in use.

User logon name (pre-Windows 2000):
support (this should be automatically populated)
Enter a suitable password and confirm it.
Ensure ‘User must change password at next logon’ is unchecked.

On the Next screen leave the Alias as support and select a Mailbox database. Click ‘Next >’. On the next screen Click ‘New >’ and then Finish on the final screen to complete the task.

Configuring POP3/IMAP4 access

In the Exchange Management Console, select Recipient Configuration and then right click on the Support Inbox and select Properties.

Disable access that is not required as this will help to prevent accidental access to the mailbox, since we only want LiveTime to access this mailbox. If messages are accessed elsewhere, they may be flagged as read and then not retrieved by LiveTime.

In this example both POP3 and IMAP4 have been left enabled.

In the Exchange Management Console, select the Server Configuration > Client Access option on the left, then right click on IMAP4 or POP3, depending on which of these types of connections you wish to use, and select Properties. The example screenshots show this for IMAP4 but the layout of the screens are the same.

Under the Authentication tab, ensure ‘Plain text logon (Basic authentication). No TLS connection is required for the client to authenticate to the server’ is selected.

Run %SystemRoot%\system32\services.msc to bring up the Services MMC. Ensure that Exchange IMAP4 and/or Exchange POP3 have been started and are set to Automatic Startup.

Configuring LiveTime

You can now edit the settings in the LiveTime email Setup. Please take note to use the full email address in the User Name fields. For the sending server, ensure Authentication is set to ‘Login’.

When logging in to Exchange you need to use a username that’s more than your simple login name. For example, if your email address is “J.User@server.com”, your Windows NT login name is “juser”, your NT domain name is “dom”, and your Exchange mailbox name is “Joe User”, then you would need to use a username of “dom\juser\J.User” when logging in using LiveTime.

Troubleshooting

If you are experiencing connection errors you can telnet to the Exchange Server. To test if the IMAP4 port is available, use the command:

telnet exchange.server.com 143

You can use port 993 if using IMAPS and other appropriate reports for other protocols (POP3 110, POP3S 995)

If you are successful you will see a similar result such as:

OK The Microsoft Exchange IMAP4 service is ready.

You can then check the login credentials by entering the following command “? LOGIN” followed by the email address and password.

To test if the SMTP port is available, use the following command:

telnet exchange.server.com 25

If you are successful you will see somethign like:

220 LTTestSVR01.uk.livetime.com Microsoft ESMTP Mail Service ready at ...