Support Ticket Guidelines

Overview

These guidelines enable the effective investigation and resolution of support tickets.

Anyone who creates support tickets for McLaren Applied products in Zendesk must follow the guidelines.

Zendesk can be used for reporting issues and queries with:

• ATLAS 10 onwards
• System Monitor
• ATLAS Data Server
• vTAG Server
• ECU Bridge

Guidelines

Descriptive titles

Please ensure that the title of a ticket includes a brief description of the context in which an issue was encountered. This enables tickets to be referenced easily and provides context to the support engineers investigating an issue.

Some examples to inspire:

• “CRASH \\ Crash while changing to distance mode in Waveform Display”
• “FEATURE \\ Compare laps between sessions on waveform display”
• “QUESTION \\ Does ADS support multisession streaming?”
• “FAULT \\ Function results not populating correctly in waveform display”

Affected users

Please provide an indication of how many users are affected by the issue, the role(s) of the users and what the issue is preventing so triaging has an appreciation of the impact and the ticket is effectively prioritised.

Occurrence

Please provide an indication of how frequently the issue occurs to help prioritize the issue.

Helpful information

Information that provides context, the IT environment and steps to reproduce help to efficiently diagnose and address and/or assess requests.

Please include steps to reproduce an issue that is considered to be a fault (defect/bug). Tickets raised as faults without steps to reproduce are naturally going to take longer to address and likely to be lower in priority and will either require follow-up to reproduce the issue or, when prioritised, engineers will have to investigate first before reproducing. If an issue is not easily reproduced, please do include that as information on the ticket.

Please also include information on the steps taken to resolve the issue, even if those steps were unsuccessful.  A positive approach is developing a full understanding of both the steps that managed to resolve the issue, even if temporary in nature or as a workaround, as well as those that were not so successful in this respect.

In general, please do consider all information as good information, but please keep it factual. For example, including a video showing the issue or indicate your availability and willingness to participate in an online meeting to demonstrate the issue.

Crash Reports & Logs

Please attach all crash reports and relevant logs to the ticket, whether they are generated by one or multiple users. Having multiple crash reports & logs provides a better picture of the issue and helps investigation and resolution of these issues.

Logs

Default file paths for log files are shown below. If these have been user-configured, then Tools > 'Show Log Folder' will open the associated log file folder.

ATLAS 10 logs are found in: C:\Users\[your.user]\Documents\McLaren Applied Technologies\ATLAS 10\Logs

System Monitor logs are found in: C:\Users\[your.user]\Documents\McLaren Electronic Systems\System Monitor 8\Log\

ATLAS Data Server logs are found in: C:\Users\[your.user]\Documents\McLaren Electronic Systems\ATLAS 9\log

vTAG Server logs are found in: C:\Users\[your.user]\Documents\McLaren Electronic Systems\ATLAS 9\log

Crash Reports

Crash reports for ATLAS 10 are auto-generated in the event of a crash of the application. Crash reports are are a .zip file found by default in:

C:\Users\[your.user]\Documents\McLaren Applied Technologies\ATLAS 10\Crash Reports

In order to collect a large amount of information about ATLAS, crash reports can be manually triggered by the user from the ATLAS 10 tool-tray icon > Save Report

Example ticket

An example of an efficiently solvable ticket would be the following:

Ticket Severity Metrics

Zendesk is configured with two metrics to assess severity of tickets, User/Operational Impact and Occurrence/Reproducibility.  When raising an issue, these should be completed according to the definitions below. This aids the triage and prioritisation of issue resolutions.

User/Operational Impact (public)

1. Low– Nice to haves, minor errors, non-functional error
2. Medium– UX/Workflow inconvenience, inability to use minor/ancillary functionality in ideal configuration
3. High– Hang of seconds, partial data loss, incorrect results, minor functionality absent, minor component damage, inability to use major/core functionality in ideal configuration
4. Critical– Crash, total data loss, hang of minutes, essential major functionality absent, car stopper, major component damage, safety issue 

Occurrence/Reproducibility (public)

1. Once– affected single user, happened once, not reliably reproducible
2. Rare– affects few users, error in rarely used functionality
3. Common– affects many users, error in everyday functionality
4. Persistent– affects all users, every usage, clear steps to reproduce

The defaults are Low and Once. 

Our Field Application Engineers can provide guidance on rating and classification.  Severity scores are assessed when tickets are triaged so it is possible the ratings will be modified after submission if they do not meet the relevant criteria.