Providing relevant feedback

This guide presents condensed information relevant for obtaining adequate and efficient support after an issue has been encountered in IMS.

Summary and key takeaway

1. The Feedback Tool should be used to request support under usual operating conditions. Why?

2. For emergencies and emergencies alone (i.e. IMS not accessible for some reason) the user should contact support via email.

3. Only one issue should be reported per ticket. Why?

4. Steps, URLs, list of IMS entity Names, screenshots and information on expectations and the outcome should be provided. Why?

5. English, please! Why?

Examples of thoughtful feedback

1. Schedule COR00794382 shows up as being in Draft Status on the Equipment grid, even if the Schedule details show that the Schedule is Final Approved.

2. RBI analysis import crashes prior to step 3 of the import process. I have attached the import file that caused the crash. There are several sheets, I was trying to import the sheet Data1.

3. When I generate the Schedule scope (R065) report on Equipment 70-PSV-043-31001170170 with options as provided on the screenshot the process will hang and the report won’t generate even after half an hour.

4. I have assigned the INSP GENERAL role to user account AMERICAS\rob.robson and the user still cannot edit Equipment details.

Describing the issue

• Support requires a specific case to start working with. A URL, the Name or a list of Names of IMS entities (ECH, Equipment, Floc, Schedules, etc.) in question should be provided.

• Terminology that is relevan in IMS should be used at all times.

• Steps describing what has been clicked and the sequence of actions that led to unexpected behavior should be provided.

• Typically, about three steps are sufficient to clearly explain the issue.

• The expected outcome can be described, and doing so can be quite helpful in more complex situations.

• More information can be sent in via screenshots, presentations, word files or videos.

Take Note

When a crash occurs, a window will be shown with a Less/More button on the right-hand side. Please click More before you take the screenshot, as Support needs the time code shown so that the error can be found in the logs.

Providing extra information

Any related files should be attached and submitted via the Feedback Tool. Support will welcome all the extra information that can be provided. Examples of expected files:

• IMS import files (excel) are essential when reporting import-related issues.

• Screenshots showcasing the reported issue. Screenshots can be taken with any of the several readily available tools. How?

• Composite issue description built in Word, PowerPoint or Excel documents.

• PDF reports as examples of files showing an issue.

• Files that cannot be attached IMS.

• Relevant email communication.

• Specific external documents (RPs, manuals) used as a reference when reporting business logic-related issues.

• Video files containing screen recordings. If submitting a video file showcasing the issue, please provide a brief (up to 1 minute) screen recording demonstrating the issue. How?

Usual pitfalls when requesting support

• Referring to all, any, or other such general terms when describing an issue is not helpful.

• Stating that something "doesn’t work" is not sufficiently descriptive.

• Support is not allowed to change user data in live production environments, so it should not be assumed that support will click around and change random data trying to find a fault with the system.

• Acronyms that are not relevant to IMS functionality should not be used without describing what the acronym stands for.

• The user should not endeavor to provide all cases of IMS entities (ECH, Equipment, Floc, etc.) that are exhibiting a certain problem. One specific example is sufficient.

• When reporting an issue with an IMS entity (ECH, Equipment, Floc …) the user should not proceed to delete the entity before anyone from support has had the chance to investigate the issue.

• Instead of providing screenshots of data, actual data should be provided.

Examples of pitfalls

• If an issue is reported for another account, it should be made clear to which account the report is referring to.

• When reporting an issue that occurred while editing an IMS entity (ECH, Equipment, Floc, etc.) information on what was edited should be provided so that support may attempt to reproduce.

• The import file must always be provided when reporting import-related issues. If the import file has multiple sheets, support will not know which sheet was selected when importing. If the import file does not use standard column names, support will not know which columns are being mapped to which columns during step 3 of the import process.

The user is not expected to troubleshoot the issue on their own

• Sometimes the users will engage in challenging troubleshooting sessions and will only opt to report the issue after getting tired.

• In such scenarios, issues reported can be several steps removed from the issue that was encountered initially.

• Tending to issues with appropriate priority requires working on an issue that may be blocking the user instead of working on resolving an issue with a workaround.

Submitting feedback through the Feedback Tool

• To access the Feedback tool, please click the green Feedback icon on the left of the screen after loggin into IMS.

• Under the usual operating conditions, feedback should always be submitted through the Feedback Tool as available in IMS.

• Sending emails to the support inbox is meant only for emergencies, in which case the email subject should contain something to the effect of “IMS not accessible” or “IMS Feedback tool not working”.

Single issue per ticket

• Focusing on one issue per ticket enables support to reduce clutter and keep working on resolving the reported issue.

• Keeping with a single issue per ticket enables easier communication with the reporting user.

Submitting relevant information

• Tickets submitted via the Feedback Tool will always contain more information than emails

• The Feedback Tool will submit some “hidden” information regarding the user's environment and is designed as a form that is meant to guide the user toward providing essential information.

• The form is designed to help both the user and the support workers.

• Tickets are assigned to a single responsible individual, while emails are usually sent to many people. With tickets, there is less doubt regarding who is expected to work on resolving the issue.

Tickets created through the Feedback tool contain additional information

• Site name and version

• IMS account username

• Browser version

• IMS URL for the page from which the Feedback was submitted

Support efficiency and optimal repsonse times

• Requesting support efficiently will allow support to correctly assign priorities and perform accurate triage.

• Efficient work allows a lessening of administrative workload, allowing support to work on resolving the reported issue.

• When trying to guess what the reported issue is, there is a substantial potential for misunderstanding.

Officially supported language

• The feedback must be submitted in English, as that is the official language spoken by all employees on Support.

• The proficiency of the user in the English language is of less importance.

• Submitting legible feedback is important, which usually means that before submitting, the user should read the feedback and check for spelling and continuity issues.

• If the submission is not understandable to the user, it will probably not be understandable to the support worker, either.