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.

Redmine Portal

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.