Skip to content

Customer Support and Services Guide

Realtime Despatch Software Ltd

Document Version: 4.0.6

Document Built: 2020-10-12

This document and its content is copyright of Realtime Despatch Software Limited. All rights reserved.
You may not, except with our express written permission, distribute, publish or commercially exploit the content.
Any reproduction of part or all of the contents in any form is prohibited.

Home

Introduction

The benefit that customers get from Realtime Despatch depends as much on the quality and timeliness of the support and services we provide as on the quality of our software.

The purpose of this document is to describe the systems and processes we use to engage with our customers and provide them with the support they need.

This document is about how we support our customers. The word support is used here in the broadest sense; it covers any activity that goes beyond the provision of core software to satisfy the business needs of our customers.

These activities include:

  • technical support to address problems with a service
  • scoping solutions to bring about improvements to address specific business objectives
  • applying these solutions to customer test and live environments
  • scheduling and applying software upgrades

The support processes describe the systems we use to communicate with customers on these activities, to discuss the nature and timing of work required, and get approval for chargeable work where necessary.

It aims to provide best practice information, useful for customers in identifying the most effective way of engaging with Realtime Despatch to achieve business objectives.

This document describes the process we use to record the time spent in providing support and how we determine whether that time should be chargable.

Audience

The primary audience for this document are customers of Realtime Despatch. The document is also aimed at prospective customers seeking further information on how we work with existing customers. In addition, it serves as a reference document for the Realtime Despatch Support Team.

Overview

Issue Tracking System

The most efficient way for us to provide support services is through an issue tracking system. For this we use the open source issue tracking software, Redmine.

https://support.realtimedespatch.co.uk/

The support portal is used for support, implementation and development tickets. Every piece of work that we do is tracked on the ticketing system.

We describe the details of how the ticketing system is setup in the Redmine Portal chapter.

The time that we book against projects is done on the same system.

The implementation process for a new OrderFlow environment will identify the key individuals within the customer team who will be responsible for raising support requests. These key contacts will be provided with a username and password to access the support portal. These users should have the necessary authority to approve chargeable work undertaken by the support team.

Accessing the Ticketing System

Our customers can use the ticketing system by logging in using credentials we provide. This will normally receive a one time password which can be used to log in on a single occasion. We will set the permissions to allow appropriate access to the required projects.

We also support reply to individual tickets by email. These replies will be forwarded to the support portal and logged in the same was as other comments to the system.

Support Activities

We mentioned in the Introduction chapter that there are a wide range of activities included in the scope of the document:

Reactive Technical Support

This covers the work required in responding to problems reported or detected in customer environments. It is reactive in nature, in the sense that it is not anticipated and scheduled.

Reactive support will also involve the triage of new change requests. The outcome here will be simply be the identification that changes are required, and the next steps for specifying and delivering a solution. The necessary changes themselves will typically not be identifed at this point.

Proactive Technical Support

This covers proactive work to address or detect potential problems in customer environments.

Software Upgrades

This covers the work to schedule, coordinate and perform software upgrades to customer environments.

Project Management

Realtime Despatch support staff regularly perform project management activities. This involves coordinating the work of others - sometimes third parties - towards some system change.

Solution Design

Solution design is the work that follows once a change request has been raised. It typically involves several different types of activity:

  • requirements gathering: the starting point of any solution is a proper understanding of the nature of the problem the customer needs to solve.
  • solution identification: this involves the identification at a high level of a suitable approach to solving the problem, which will need to be agreed with the customer.
  • task identification: this involves identification of the specific tasks that need to be covered to effect the solution.
  • task estimation: this involves associating time estimates against the work that needs to be done, and producing a quote where appropriate.

Solution design may be either an implementation or development task, or not, depending on whether the solution requires development work or not.

Solution Preparation

For most non-trivial work, some up front work will be required outside of the customer environment to prepare for the delivery of the solution. This work is known as Solution Preparation.

For example, consider a solution involving the configuration of a custom process that involves non-standard state changes to orders going through the system. In this case, we would want to deploy, test and document the solution in a local Realtime Despatch environment prior to deploying it on a customer environment. Similarly, new despatch notes would typically be created and tested in a Realtime Despatch development environment prior to being placed on customer systems.

Solution Delivery

This is the final stage of implementing a solution, as it involves the application of the solution in the customer environment, together with all of the communication, coordination and testing required.

This part of implementation will be highly visible to the customer, and will typically require the direct involvement of the customer to verify parts of the solution as they are delivered.

Development

By definition, development work is not a support-related activity. However, we mention it here for the sake of completeness, as in many cases it will not be possible to implement a solution until necessary development work has been completed.

Our Commitment to Responsiveness

Probably the most important feature of any support system is responsiveness. However quickly we are able to deliver a solution to a particular problem, it is important for us to be able to provide customers with the assurance that it is being acknowledged and addressed.

Our commitment is to provide the following:

  • any new ticket raised will always be acknowledged on the same business day as it is raised. This usually takes place within minutes of the ticket being raised.
  • no ticket will ever go unanswered. If a customer comments on a ticket, we will always respond it it.
  • no ticket will get forgotten about.

In order to meet this commitment, we have developed a well defined process for managing tickets, as well as support software to assist with this task.

These are discussed in the Support Role chapter.

A note on telephone support

Some customers like to call Realtime Despatch in order to be satisfied that their problem is being addressed promptly. We like talking to our customers to help them solve problems, but find that the process works much more effectively if the call occurs after a ticket has been raised.

Support calls can be made using the dedicated support number, 01249 704585. Calls will be answered by the support team during office hours. For more details on how out of hours support calls are handled, please see Out of Hours Support.

When customers call with a problem but no ticket has been raised, we politely ask them to raise a ticket with as much relevant information as possible. This is because the information that we generally need to resolve a problem is much more easily captured using the ticketing system than over the phone. If necessary, we will call back for further clarification.

Note also that the person who initially receives a phone call will not necessarily be in a position to resolve or even triage the issue, or to deal with it as a priority. However, customers raised via the ticketing system will be addressed promptly and directed to the person in the best position to help resolve the problem.

Redmine Portal

Projects

Data on the support portal is organised by project. Each customer has visibility of the following projects:

  • a support project, which is used for support and implementation tickets
  • a development project, which is used to track development work for that customer

Customers can raise tickets in these projects, edit these tickets, and close them off when work has been completed.

In addition, each customer has read-only access to a project called 'Shared Dev', which includes development work which is potentially of interest or benefit to all Realtime Despatch customers.

The typical project structure visible to the the hypothetical customer Customer X is as follows:

Shared Dev
Customer X
>> Customer X Support
>> Customer X Dev

Note that non-development tickets, including Support and Implementation, are hosted within the Support sub-project. Development tickets - notably Bug and Enhancement tickets - are hosted within the development subproject (in this case Customer X Dev).

Users

The users who have access to the support portal will be agreed as part of the OrderFlow implementation process. The intention is to ensure that all support requests are made by key individuals who have the necessary skills and background to report issues in a way that ensures they can be dealt with effectively. The users should have the necessary authority to initiate chargeable support work.

Users will receive an automatically generated email whenever a new issue has been created or progressed within the support portal.

Issues

Issues are the most fundamental part of the Support Portal. We use the terms Issues and Tickets interchangeably, but on the support portal, the term used is issue.

All work is tracked using issues.

A typical issue includes:

  • a subject heading
  • a description of the issue, normally detailing the problem being addressed
  • further comments, effectively a written discussion between Realtime Despatch and the customer
  • a state, which gives an indication of the progress of the issue

More details on how tickets are managed and progressed through the system is found in the Issue Management chapter.

Trackers

Tickets are associated with trackers based on the nature of the issue, and the activity involved in resolving it. Understanding the trackers used for different Realtime Despatch tickets can be useful. The trackers used in are described below.

Support

This the default tracker for new tickets, and the tracker that is used for reactive support tickets.

Customers are not expected to know what tracker to use when creating a new ticket. For example, if the system is not behaving in the way that is expected, this may or may not be the result of a bug.

If some short term remedial action is required, this activity will be tracked against a support ticket.

Bug

At Realtime Despatch we are quite specific about what we consider to be a bug. This is because we do not log any billable time against bugs (see Billing and Time Booking for more detail on Realtime Despatch policy on chargeable work).

If the system is not behaving as expected, there may be multiple causes:

  • there may be a configuration error
  • there may be an issue with the environment, such as insufficient memory or disk space
  • there may be an underlying software bug

Determining the cause is a Support task which will typically require some investigation. This activity is recorded against the original support ticket. If the cause is found to be due to a software defect, a new ticket is raised with the tracker Bug. Resolution of the bug will both development work to identify and produce the necessary code changes, and in some cases Implementation work to deploy the code update (patch) to customer environments.

We discourage customers from raising tickets as bugs, as this preempts the process just described.

Enhancement

The tracker Enhancement is used for development work for new features. Tickets will get raised as Enhancements if it has been identified that development work is required in order to provide a customer solution. The process that is typically used is as follows:

The customer identifies a business requirement that is not currently being met, and raises a ticket. The OrderFlow support team will identify that a solution is required involving a change in system behaviour. In some cases it will be obvious that development work will be required. In some cases, some further investigation will be required to determine whether code changes are required or whether the solution can be provided through configuration or implementation alone.

The tracker Enhancement is only used for the development work involved, when this is required to provide a solution.

Implementation

Implementation covers work that is required to implement a solution. Unlike Support work which is reactive, Implementation work is scheduled proactively.

By definition, Implementation work does not involve code changes to the core OrderFlow software. Examples of tasks that may be covered by the Implementation tracker:

  • carrying out software upgrades
  • preparing and applying scripts and custom reports to customer environments
  • making environment changes, such as performing server migrations

Preparing and applying a full end-to-end solution may involve both development and implementation work; in this case, these will be tracked in separate tickets using separate trackers.

Other

A number of other trackers have been set up on the Realtime Despatch Support Portal, including the ones described below.

  • Refactoring a development ticket which does not result in a functional change; instead, it involves a change in the way a feature is delivered. It may result in some risk for the customer, and require extra testing to ensure that no undesirable side effects have been introduced.
  • Tasks involve work that does not involve any development or support work, or any change to a customer environment.
  • Documentation as the name suggests involves document creation and preparation. Every ticket produced will involve some documentation. The Documentation tracker is used when the work purely involves documentation.

Milestones

New software features and bug fixes are delivered as a group within a release. The term used for releases in the support portal is Milestone.

OrderFlow milestone are named using a combination of version number and release name. For example, 3.6.7-london.

The purpose of delivering software in releases is to ensure that all of the changes being delivered can be properly tested, both by Realtime Despatch before the release is delivered, and by the customer through a User Acceptance Testing process.

As part of recent changes to the Realtime Despatch software delivery process, an email is sent to customers about two to three weeks prior to each release, detailing the main features being developed as part of that release. A subsequent email is sent when the release is ready.

Customers wishing to upgrade to the new release version, or consider upgrading to this version, can do so by raising a ticket. This will initiate a process leading to the upgrade of first the customer test environment, and potentially the customer live environment, with the new release version. The time taken to upgrade a customer environment will be chargeable, an upgrade typically takes between 30 and 45 minutes.

Issue Management

In the Redmine Support Portal chapter we introduced tickets, and went into some detail on the Trackers that are used for different types of activities (Bug, Enhancement, etc.).

In this chapter we go into more detail on how issues are progressed through the system.

We deal with the mechanics of how issues are dealt with as they are raised, the triage process.

We also describe some of the processes involved in managing different types of tickets, focusing in particular on the distinction between Problem Issues and Solution Requests. We describe as our conventions for deciding when to raise new tickets to cover different aspects of an overall task.

We also go into some detail on the use of states as an indicator for how different types of issues are being progressed.

Triage of New Issues

Triage is the first thing that happens when a new ticket is raised. An initial assessment needs to be made on the nature and the severity of the problem.

The first step is to determine whether the issue is having any immediate business impact due to impairment of existing functionality (a Problem), or whether it reflects a change requires the scoping and scheduling of the required to meet a new business requirement (a Solution Request).

These questions need to be answered in order to determine the next step for each ticket raised.

Problem Issues

If a problem is reported, the first question is to determine the severity of this impact. This will determine the priority given to the ticket.

The priority will influence the speed of response of the OrderFlow support team.

Priority Impact Target Response
Immediate System not accessible, or mission critical part of system is not usable, causing major operational impact. Immediate
Urgent A mission critical part of the system is not functioning correctly, resulting in significant operational impact. 2 hours
High A part of the system is not functioning correctly, resulting in a loss of efficiency and operational delays. Within 1 working day
Normal A part of the system is not functioning correctly, but an acceptable temporary workaround is possible at least in the short term. Scheduled Release
Low A part of the system is not functioning correctly, but with no noticeable business impact. Scheduled Release

As the name suggests, tickets that are identified as Immediate will be addressed without delay during business hours. In practice, Urgent tickets typically get actioned without delay as well, and High priority tickets will be addressed on the same day.

It is worth clarifying what we mean by Target Response in the table above. This indicates the period within which we will begin a meaningful and serious engagement with the customer towards resolving the problem.

Setting Priorities

Setting the ticket priority is normally the job of the OrderFlow support team. On occasions, the priority will be changed to reflect a revised judgment on the severity of the impact of the problem.

In some cases, the resolution will be through a single action, such as restarting a server. In other cases, the resolution will be done in stages. Here, the question we ask is as follows:

  • What can be done in the very short term to reduce the impact of the problem in the short term?
  • What needs to be done in the medium to longer term to provide a complete resolution of the issue. For example, is any development required.

Determining the answers to these questions often involves further interactions, including

  • requests for further information
  • investigation on the customer system
  • work to replicate the problem in a local development environment

Often it is possible to perform a short term tactical fix to reduce the impact of the reported problem. If further longer term fixes are required, these will be addressed through separate (possibly development) tickets as required.

Responsibilities

The responsibility of the Support Team here will be to:

  • perform the initial triage on the new ticket.
  • identify and perform the short term remedial actions that will resolve the issue or lessen its impact.
  • raise new tickets to cover any longer term fixes required to address the underlying cause of the problem, or to reduce the likelihood of it occurring.

If longer terms fixes are required, it will be the responsibility of the Development and/or Implementation Team to schedule the work required to provide these.

Trackers

The Trackers used for problem issues are as follows:

  • the ticket will initially be raised as a Support ticket.
  • any short term remedial action that is done will be recorded against the original Support ticket.
  • if during the investigation of the ticket, it is determined that there is an underlying software defect causing the issue, this will be addressed through a new Bug ticket.
  • on some occasions, additional development work will be helpful in delivering new functionality to reduce the long term impact of the problem or its frequency of occurrence. These will be handled through a new Enhancement ticket.
  • similarly, it may be possible on occasions to identify longer term non-development changes that will be helpful in managing the issue. These will be handled through separately raised Implementation tickets.
  • if a software defect is identified, but no short term remedial action is required, it may be appropriate to reclassify the original ticket as a Bug. For example, a broken link may be raised as a Support issue, but reclassified as a Bug if there is a simple workaround.

The key to these rules is that the Tracker used should reflect the nature and timing of the work being delivered. We should never end up, for example, with short term remedial actions being tracked in the same ticket as the longer term resolutions, or with support or implementation work being tracked in the same ticket as the development work.

Best practices in raising new issues

In order to get the speediest, most helpful and most cost effective response from Realtime Despatch, we recommend the following when raising tickets.

If a problem is being reported, please:

  • use specific examples of where you expect a problem.
  • if the system is not behaving correctly, try to describe how you think this is occurring. Detail on what you expect to happen versus what is actually happening is very useful.
  • ensure that you mention which environment this is is occurring (test, live, etc.).
  • give us an indication of how severely this is impacting your operations. What the consequences of each occurrence, and what are you doing to work around the problem?
  • add links to the tickets where possible.

If any of this information is missing when the ticket is first raised, we may ask for it which may result in a delay in resolving the issue.

For solution requests (see below), please try to:

  • make it clear that you are requesting a change rather than reporting an issue on an existing customer environment.
  • give clear information on the business problem you are trying to solve.
  • focus on the requirement rather than on the solution.
  • give some indication of how urgently the change is required, so that we can prioritise it appropriately.

Solution Requests

Unlike problems, solution requests don't typically require an immediate response. However, we will always acknowledge the receipt of a change request on the same business day, usually giving an indication of when the next action is likely to take place.

The first meaningful engagement after a change request is raised will be towards get a very high level understanding of the required change and the possible scope involved. Initial questions to answer here are:

  • what is the essence of the problem being addressed?
  • do we need input from the Development Team to determine whether the problem will require code changes?
  • how much design work will be required to fully understand the problem and present a solution?

The solution request will be received initially by the support team. The first response will often involve further questions to the customer to validate or clarify their understanding of the requirement.

In very simple cases it will be possible to deliver the solution as part of the Support Function. For example, this may be possible for simple custom reports. As a rule, if the solution is likely to involve comfortably less than two hours of testing and implementation time, then it might be carried out by the support team.

For any more substantial change, the next step after initial clarification of the requirement will to be to schedule time to:

  • scope the requirement in more detail
  • present and agree on a candidate solution
  • identify the tasks involved in delivering the solution
  • provide an estimate for the time required to perform these tasks

Responsibilities

The Support Team's responsibility for Solution Requests will be to:

  • obtain clarification on the requirement that needs to be addressed.
  • in very simple cases, to implement the solution as part of the Support Function. Otherwise,
  • hand the ticket over to the Development or Implementation Team for a solution design.

Trackers

The approach to the use of Trackers is similar in essence to that used for Problem Issues.

  • the ticket will initially be raised as a Support ticket.
  • if the solution can be delivered as part of the support function, it will remain a Support ticket.
  • if the solution does not require any development (code changes), then the original ticket will be reclassified as an Implementation ticket.
  • if the solution does require development work, then one of the following can happen:

  • if the solution involves a significant amount of implementation work and but little development, then the the original ticket will be reclassified as an Implementation ticket, and a new Enhancement will be raised.

  • if the solution is primarily a development solution, that is, requiring a substantial amount of development but only a small amount of implementation, then the the original ticket will be reclassified as an an Enhancement. If any subsequent work is required to deliver the solution, a new Implementation ticket will be raised to cover the subsequent implementation work that will follow.

Milestones

Milestones are used to control the timing of the delivery of all work that needs to be scheduled; this includes both development and implementation work.

The use of milestones depends entirely on whether development work is required to deliver a solution.

Milestone Usage when Development Work is Required

Development work needs to be added to a release milestone. If implementation work is required, it will only be possible to deliver this implementation work into the customer environment after the development release has been release has been prepared and the associated upgrade performed on the customer environment.

For these cases, the following will apply:

  • the development ticket will be associated with a numbered release milestone (e.g. 3.6.7-london)
  • the implementation ticket will be associated with the same release milestone

On some occasions, if the development change is small and simple, it may be possible to back port the development change to an earlier release. Once the associated patch has been delivered and deployed, the constraint on the development milestone requirement can be removed.

Milestone Usage when No Development Work Required

If no development work required, then the Implementation ticket will not need to be associated with any development milestone, as the timing for this implementation work is not constrained by the delivery of development changes.

The issue Next Action Date field is used to actively track implementation work that is currently being addressed, or is scheduled for further work on a particular date in the short term.

Other implementation work that is not yet scheduled, can be added to one of two non-development milestones:

For solutions which can be addressed as part of the Support Function as Support tickets, there is no need to set a milestone. Instead, the Next Action Date action date is used to manage the timing of delivery of these tickets.

Non-release Milestone

It has been mentioned earlier that Support tickets are tracked through the Next Action Date mechanism, and that development tickets are tracked using a development release milestone.

Another category of tickets are Implementation tickets that may involve a substantial amount of work (several hours or more), but don't require any development work. It doesn't make sense for these tickets to be tracked within a development release milestone.

These tickets are instead placed in one of two special milestones:

  • Current Non-release Milestone: this contains a list of substantial tickets for which work is required in the short term, but hasn't necessarily be scheduled using the Next Action Date mechanism.
  • Deferred Non-release Milestone: this includes implementation tickets for which work is required in the more medium term, but still need to be visible for scheduling or planning purposes.

Issue States

Exactly what happens to a ticket over the course of its lifetime depends on the type of ticket involved. The state provides a good indicator of what is happening to a particular issue at any point in time.

Support

The Support tracker is the default tracker that is used for all tickets. Both Problem reports as well as Solution Requests are received initially as Support tickets. The states used for Support issues are as follows:

Name Description
New The default state for new tickets
Further Info Requested Used when further information is required or will be helpful to understand a reported problem.
Investigating The state used by Realtime Despatch when actively investigating an issue.
In Progress This is a post-triage state which indicates that Realtime Despatch is currently carrying out work to achieve a resolution to a ticket.
Customer to Verify This is the state that typically follows the handover of work from Realtime Despatch to the customer. If verification fails or further work needs to be done, the ticket can move back to 'In Progress'.
Closed This indicates that a ticket is no longer active, and that the problem has been resolved.

The workflow is shown graphically in the diagram below.

Support Workflow

Implementation

Implementation is the other main tracker used for tickets that do not require development work.

The main states used for this tracker are.

Name Description
Pending Work on the implementation ticket is not yet active, and is waiting to begin.
Further Info Requested Used when further information is required or will be helpful to get a better initial understanding of a solution requirement.
Investigating The state doing the initial scoping work. If more detailed scoping work is required, then approval for this is sought.
Design Approval Requested An optional state for more involved implementation work, where specific design time needs to be approved to scope and estimate a solution.
Awaiting Estimate An implementation ticket will tend to be in this state during the design phase, during which time the scoping, solution design and time estimation will occur.
Approved Once scoping and estimation is complete, a ticket will be submitted for approval for the main body of the implementation work.
In Progress Work is currently under way to prepare the solution.
Customer to Verify The solution has been delivered, and the ticket is now with the customer for approval. This state is also used when a part of the solution has been delivered, and verification is sought on specific work covered so far.

Note that some of the above steps will be bypassed for smaller tickets. For example, design approval will only be requested if the design time is expected to take two hours or more. Similarly, approval for the main implementation work will only be sought if this work is expected to exceed two hours of effort.

The implementation workflow is shown graphically in the diagram below.

Implementation Workflow

Bugs

The workflow for development tickets such as bugs and enhancements is a little more complicated, as a number of the states used are internal to the development process.

Some of the main states in use for Bugs are listed below:

Name Description
Investigating This state is used when a bug is suspected, but has not yet been reproduced.
Accepted The bug has been accepted, but work on resolving the issue has not yet started.
In Progress Work is currently under way to resolve the issue.
Customer to Verify This state is sometimes used if further verification from the customer is required in order to determine that the bug has been resolved.
Fixed when Deployed Indicates that the bug has been fixed, and that this fix will be applied at the point where the software release containing the bug has been deployed

Note that the development work required to fix a bug will normally need to take place against a software release milestones.

Enhancements

Most of the states used for the Implementation tracker, including all of the states listed above, are used for Enhancements. A number of additional states are used for enhancements.

As with Bugs, the Fixed When Deployed state is used to indicate that the feature covered by the enhancement will be present and available for use at the point when the software release containing the enhancement is deployed.

Customer Acceptance Testing

On completion of work on any non-development ticket, Realtime Despatch will move the ticket to the state Customer to Verify. Non-development work will be implemented on an existing test or live release, so it is important that the change is brought explicitly to the customer's attention to allow for verification that the change has worked as expected and not introduced any further issues.

For development work, the Customer to Verify state is used, but a little bit more sparingly. It tends to be used only when specific verification is required against a piece of development work to ensure that the change it has introduced has had the desired effect.

However, it would not be realistic to expect customers to verify the behaviour of every single change that has been introduced with each release. Instead, we recommend that with each release, that the customer performs a full regression test of the main processes in a test environment prior to scheduling an upgrade to a live platform.

For many tickets we consider it appropriate to point out areas where we think extra testing may be required following the inclusion of a ticket in a release. Here, we identify such tickets with an entry in the Customer Testing Notes field.

In addition, the release information we include in customer upgrade tickets specifically aim to identify the following:

  • High Risk Changes: where substantial or fundamental changes to the way a part of the system works have been introduced, extra testing may be recommended in affected areas, even when no obvious functional changes have been introduced.
  • Backward Incompatible Changes: this occurs when changes are introduced that may prevent custom reports or scripts from working as before. In this case, the release information will include details on the affected change and the likely impact.

We plan in the coming months to introduce support for generating customer release notes to coincide with upgrades, which will be helpful in making this information more visible.

Next Action Date

An important feature of support system are mechanisms to ensure that issues that have been raised don't get 'lost' or 'forgotten about'.

The Next Action Date field is used to indicate that date at which the next action is scheduled to occur on a ticket. When that date arrives, it will be the responsibility of the issue's Assignee to ensure that some action is taken on the ticket. The use of the Next Action Date does not mandate what this action is. In some cases, the issue will be resolved on that day. In other cases, some steps will be taken towards the resolution of that issue. On other occasions, there won't be the opportunity or the time to take further steps on the current day, at which point it will be responsibility of the assignee to set a new Next Action Date for that ticket.

Tickets which have a Next Action Date set for the current date or some date in the past will be visible to the Support User, who will if necessary remind the assignee of this responsibility.

The importance of the Next Action Date is in ensuring that current or outstanding work remains visible to customers as well as the Realtime Despatch Support Team.

A Next Action Date will be set automatically for all new tickets, so unsetting this date will require an explicit choice on the part of the user.

The Next Action Date is mainly useful for non-development tickets (including Support or Implementation tickets). For development tickets (including Bugs and Enhancements) that are assosciated with a release Milestone, the progress of that work is tracked within the development release.

The Realtime Despatch Support Role

The Support Role is a dedicated role created by Realtime Despatch to ensure that support systems are properly monitored during working hours, in order for us to meet our commitment to responsiveness.

At least one member of the Realtime Despatch will be performing the Support Role during working hours. The member of the support team performing this role is known as the Support User.

The purpose of the Support Role is to ensure that the team as a whole can react quickly to customer demands, without requiring each member of the team to actively monitor the support systems. We use our in house configuration management and monitoring system, RemoteMan, to assist us in performing this role.

An example screenshot from the RemoteMan issue monitoring page is shown below.

Remoteman

This screen gives the Support User an instant overview of how we are doing on support. It allows the user Support user to identify whether there are:

  • alerts on possible system or environment issues
  • new tickets on the system that have not yet been acknowledged
  • customer comments on tickets which have not yet been answered
  • whether there are tickets that require follow up or are overdue

Each of these is discussed in more detail below.

Alerts

RemoteMan works together with OrderFlow to monitor OrderFlow environments and system health.

Alerts will be triggered when one of the following happens:

  • a customer system monitoring heartbeat message has failed, indicating that the system is not responding, unavailable, or inaccessible.
  • a system alarm has been raised on a customer environment. This might arise, for example, if an unusual event has occurred on that environment that might result in some data inconsistency
  • an environment indicator has exceeded its configured threshold value.

An example of an alert is shown below.

Alert

Examples of environment indicators are:

  • file system usage
  • system memory usage
  • Java Virtual Machine (JVM) memory usage
  • CPU utilisation percentage

On detecting an alert, the Support User will acknowledge receipt of the alert and investigate the cause. If the alert turns out to be a false alarm (caused for example by a temporary network outage or scheduled downtime) then the alert can be closed.

If necessary, the Support User will raise a new issue on the Support Portal to track any further actions that may be required.

New Tickets

The status 'New' is the default status for all issues raised on the Support Portal. When a new issue is raised, this becomes visible almost immediately on the RemoteMan monitoring screen.

The responsibility of the Support user is to triage the new issue. As described in Issue Management Section, the triage process involves identifying the type and severity of the issue, and determining the priority for any subsequent action.

At the very least, the new issue will be acknowledged so that the customer has confirmation that the it has been received. In addition, a Next Action Date will be set against the ticket to ensure that it remains visible on the 'stack' of outstanding work.

Unanswered Tickets

At Realtime Despatch we never leave issues unanswered. One of the main jobs of the Support User is to answer customer tickets. In some cases, the Support User will personally take steps to address and resolve tickets.

In other cases, the customer response that has been received is part of an ongoing conversation between that customer and a particular Realtime Despatch team member, in which case it will be more appropriate for that team member to continue the conversation. The Support User's job at this point is to identify this situation and alert the team member to the presence of a customer comment that is awaiting response.

Actionable Tickets

Actionable tickets are tickets for which the Next Action Date is either today or in the past (i.e. late).

The RemoteMan issue monitoring screen will indicate the number of actionable tickets, displaying these more prominently (with a yellow rather than green background) if there are:

  • any late actionable tickets, or
  • more than ten tickets are actionable on the current day

The Support User's responsibility is to ensure that the Next Action Date on issues is set appropriately, and if necessary, to prompt the issue's Assignee to take appropriate action or reset the Next Action Date.

Tickets Requiring Followup

The count of actionable tickets described above include only tickets that are assigned to members of the Realtime Despatch Support Team. Tickets assigned to customers are not included.

As part of the support process, Realtime Despatch will often seek further responses from customers on particular tickets, for example for additional information or for approval for chargeable work. In these cases, the normal process will be to add an appropriate comment, assign the ticket to the customer, and change the state of the ticket (for example to 'Further Info Requested' or 'Awaiting Approval').

The Tickets Requiring Followup view provides a mechanism to identify tickets for which a further response from a customer is still outstanding.

The normal procedure will be as follows:

  • when updating the ticket and assigning it to the customer, the Next Action Date is set to the current date.
  • after seven days, the ticket appears in the list of Tickets Requiring Followup.
  • the Support User will reprompt the customer for a response, again setting the Next Action Date to the current date.

This process may be repeated a couple of times if necessary. If no response from the customer is forthcoming, the Support User will at this point take an action that stop the ticket from appearing in the Tickets Requiring Followup list, either by asking for the issue to be closed, or simply unsetting the Next Action Date.

In the latter case, the customer will still be free to respond to the ticket at a suitable moment, but won't receive further prompting to do so.

Billing and Time Booking

Overview

Support and implementation services for customers are a big part of what we do, and we do need to charge for these services. Our policy for billing for work is governed by two principles: that it must be fair, and that it must be transparent.

In this chapter we describe the conditions under which work will be chargeable, and when charges will not apply. We also cover the mechanisms we have in place for obtaining approval for chargeable work. Finally, we describe how we book and invoice for time spent to ensure that the billing is transparent.

When is Work Chargeable?

Our approach to charging for work aims to reflect the degree to which our services add business value beyond that covered through the hosting and/or software licensing arrangements alone.

Customers should not be left that the feeling that they are 'paying twice' for services being offered; when they are charged for support and services, they should also have the sense that value is being provided in exchange.

Support

Support requests can be raised to cover all sorts of situations, many of which will result in chargeable work being carried out.

There are two notable situations in which support work will not be chargeable.

Software Bugs

If a problem is reported and this turns out to be due to a defect in the core software, then the support work undertaken to investigate and resolve the bug will not be billable.

The one exception is when the bug occurs in a part of the system developed as a bespoke feature for the customer concerned, and when the development of this feature was charged to the customer on a time spent rather than fixed price basis.

Note that support work done to address problems caused by the way the system has been configured is typically chargeable. Examples of this include problematic custom scripts and reports, and workflow configurations.

General Enquiries

We normally do not charge for general questions about how parts of the system work and can be used. However, questions that relate to the specifics of how features have been applied or could be applied for a particular customer's business requirements will typically lead to chargeable work.

Project Management

For some projects Realtime Despatch will charge for project management services.

Two scenarios where this is likely to occur are if Realtime Despatch is undertaking work to:

  • coordinate or manage the activities of third parties.
  • manage internally the delivery of a potentially complex program of work for a specific customer over a period.

Solution Requests

This type of work involves the request for configuration changes or new features to address specific problems.

We encourage our customers to be creative and proactive in exploring ways to use the software more effectively. Accordingly, we usually don't charge for answering general questions about how features could be applied.

We also very welcome feedback and feature suggestions that could be beneficial for the product and its users, so we won't charge for these kinds of interactions.

However, we do typically charge for detailed or specific responses to individual customer requirements, or for work undertaken to obtain a better understanding of these requirements. The design work that precedes the provision of a solution or development feature will typically be chargeable.

Bug Fixes

As with support, Realtime Despatch does not charge customers for fixes to defects in the core software product.

When the fix needs to be applied to a bespoke feature developed for that customer, for which the development was not charged on a fixed price basis, the bug fix may be chargeable.

Feature Development

Feature requests that we receive from customers normally fall into two categories:

  • customer-specific bespoke developments
  • roadmap features (that would reasonably be expected to be useful for multiple customers)

Customer-specific bespoke developments will typically be chargeable.

For roadmap feature requests, the situation is a little more complicated. If the customer wishes to expedite the feature, then some charges will be applied for a commitment to deliver that feature by a specified date. The customer will not be charged the development cost for features that are developed simply as part of the OrderFlow Roadmap, where no commitment is provided for the timing of the delivery of these features.

Fixed Price vs Time Spent Development

When quoting for chargeable development work, we usually give customers an estimate of the work on a time spent basis. We can also provide a fixed cost quote if requested.

We encourage customers requiring greater flexibility to allow us to bill on a time spent basis. Fixed cost development is more suitable for customers who have a more formal approach to the approval of chargeable work.

In both cases, Realtime Despatch will typically do chargeable design work to identify the development tasks and costs involved.

Realtime Despatch typically does not provide implementation work on a fixed price basis as the scope of the work often varies in ways that are outside of our control.

Project management and support work is always charged on a time spent basis.

Time Spent Development

If development is done on a time spent basis, the costs applied may vary from the original estimate. If the work is done more quickly than expected, the benefit is passed on to the customer. However, the customer also takes on the risk of receiving additional charges in the event of unexpected overruns. As described below, Realtime Despatch will inform the customer if it becomes clear that this is likely to happen.

If bugs are identified in work that was originally done on a time spent basis, any work done to resolve the bug will be chargeable if the bug is identified within ninety days of the functionality being used in a live environment.
If bugs are identified after the first ninety days, the work will not be charged.

Fixed Cost Development

For fixed price development, Realtime Despatch takes on the risk of a cost overrun by ensuring that work is delivered within an agreed budget.

We typically go through a more detailed design process for fixed price development work to ensure that the precise scope of the work required is fully understood and agreed beforehand.

Fixed cost development is normally charged on the basis of the estimated work involved, but with an additional 20% contingency charge to cover the risk of a cost overrun.

If bugs are identified in work done on a fixed cost basis, work done to resolve the bug will not be chargeable.

Obtaining Approval

Part of our commitment to transparency involves ensuring that we have approval from the customer for any chargeable work that is undertaken, so that the customer does not get any unpleasant surprises when receiving invoices.

For this we make sure to establish who has authority to approve chargeable work, and to ennsure that approval for chargeable work is obtained at the appropriate points.

Customer 'Approver' Role

At a very early stage in our interaction with a customer we will determine which users within the customer's organisation are entitled to provided approval for chargeable work.

The Two Hour Rule

Any request to the customer for approval for chargeable work will involve some project management overhead, and delay. For this reason, within the early stages of the implementation we normally suggest that we apply a two hour rule to new support requests

If chargeable work is expected to take two hours or less, it will be undertaken without specific approval being requested for the work involved.

The two hour figure may seem arbitrary - it can be changed on request - but in our view this time threshold does allow Realtime Despatch to be responsive while still giving the customer the control over approval of larger pieces of work.

For support requests, design and development work that is expected to exceed two hours, an estimate will be provided, and specific approval will be requested before the work is undertaken.

Ticket Management

When using the ticketing system, Realtime Despatch will use ticketing states to indicate that approval is being requested for work.

  • Design Approval Requested: if significant design work is required to arrive at an estimate for quoted work, Realtime Despatch will assign the ticket to the customer Approver with an appropriate comment, and move the ticket to the 'Design Approval Requested' state. The design work will only begin once the customer has given approval for this work, normally via a comment on the ticket.
  • Awaiting Approval: this state is used to indicate that approval is requested for development or implementation work. Once again, no work will start until the customer has given approval, at which time the state of the ticket is changed to 'Approved'.

Approval for Additional Work

When work is done on a time spent basis, and the amount of time taken is likely to exceed the original estimate provided, Realtime Despatch will notify the customer of this development. We'll also provide an estimate and request approval for the additional work involved, where possible identifying the cause(s) of the overrun.

In these case, the issue will be moved to the 'Awaiting Approval' state, and no further work will be done until the work is authorised by the appropriate contact within the customer organisation.

Time Booking

Realtime Despatch's system for time booking helps to ensure that charges to customers are applied in a transparent way.

All chargeable work is backed by individual time booking entries that are provided to the customer as part of the monthly invoice.

Each time entry has the following information:

  • the ticket against which the time is being booked
  • the type of activity (e.g. support, development, implementation, project management)
  • a comment describing the activity covered by the time booking

All non-billable time spent on customer tickets is also recorded, and provided with the invoice, although in this case for information purposes only.

Detailed reports of time booking for the current month are available with the upport portal.

Out of Hours Support

Some of our customers have expressed an interest in being able to access our support services outside of UK office hours. The need for this doesn't arise often but it's reassuring to know the option is available. With this in mind we also have an Extended Support window for high priority issues that have a significant impact on our customers' business.

Out of hours support can be obtained by calling the dedicated support number 01249 704585.

Calls to this number will be answered by the support team directly during office hours, but will now also be answered by a call handling service at all other times.

The Extended Support times for which it is possible to access support from a member of the Realtime Despatch technical support staff are shown below.

Week days

Times Support Cover
07:00 to 09:00 Extended Support
09:00 to 17:30 Standard Support
17:30 to 21:30 Extended Support

Weekends and National Holidays

Times Support Cover
09:00 to 17:30 Extended Support

Customers can raise support tickets outside of office hours in the normal way. If one of our customer's nominated contacts calls the support number with a business critical issue during the 'Extended Support' window, they will also have the option of requesting that our support team be contacted to progress the ticket.

If you raise a ticket out of office hours, but choose not to initiate a support request through the dedicated support number, the ticket will be progressed in the normal way during office hours.

A Note on Charges

Note that any chargeable work that is initiated through the out of hours support process will be billed at 1.5 times our standard rate. A minimum of one hour of support time will be booked each time this service is used.

Callers will be reminded of this and will be asked whether they want to initiate an out of hours support request on this basis.

We cannot guarantee that we will always be able to provide immediate response through this service. As a result we are not imposing any standing charge for this service. However we do aim to respond within 30 minutes of having been contacted.

How to Enroll

If you are not currently using this service, but would like to be able to take advantage of it in the future, please contact us to let us know which of the users below should be authorised to initiate an out of hours support request.

Scheduled out of hours support

The same Extended Support arrangements will be used for upgrades and other configuration work that is scheduled outside of normal business hours. As with unscheduled support, this work will be billed at 1.5 times our standard rate, with a minimum time booking of one hour.