Udostępnij za pośrednictwem

Help us help you

  • Artykuł

This article outlines the key factors to consider before submitting a support ticket. While most people inherently understand this process, there can be situations where urgency for the creation of the support ticket can lead to some steps being skipped or rushed. The steps are essential as they enable our support organization, processes, and other relevant Microsoft Teams to address your request promptly.

The basics

When you submit a support ticket, the key to helping us assist you is to triage the issue beforehand. This might involve your IT department, a business super-user, or a service agreement with an implementation partner or an independent software vendor (ISV). The purpose of the triage is to ensure the following:

  • The issue wasn't resolved in a different context or in a more recent released version.
  • The issue isn't related to a known product limitation, or there's an existing workaround available.
  • The issue wasn't caused due to a user taking an invalid path through the business process.
  • The issue isn't due to custom or ISV code that can cause distraction within the support process leading to protracted diagnosis and delays to the resolution.
  • The issue isn't due to existing application programming interfaces (APIs) constraints or performance restrictions.

The request

Ensure you gather all the necessary information before opening a support ticket, and that it clearly and concisely describes the issue.

Create the support ticket under the right plan

Microsoft offers several support plan options for Dynamics. Ensure you understand the features of each support plan and select the one appropriate for your situation. If you're working with an implementation partner, they might want to open the support request using their plan.

The problem statement

Clearly articulating the problem statement in your support ticket is crucial for us to assist you effectively. This not only ensures that your ticket is directed to the right team but also helps the support engineer understand the issue more quickly. Remember, engineers take cases from various customers, so they might not always be familiar with your company-specific or industry terminologies.

The problem description

Making sure that the problem description contains all the relevant information in the first round of communication can expedite the resolution process. The description should contain the following information:

  • A clear and accurate description of the problem.
  • The steps to reproduce the problem, include the context of the situation and what happened before or after the problem.
  • Quality reproduction information should also include any unusual data, configurations, or scenarios related to the problem statement.
  • Clearly state any specific company or industry terms and provide references to external documentation relating to the terms, as needed.
  • Any custom extensions or ISV code in the area where the problem was encountered.
  • The expected outcome versus the actual outcome. This might seem like common sense in some cases, but the problem might lie in the expectation, and not in the experienced outcome. A clear description can help to catch this early.
  • Details of error messages received, and screenshots of the problem.
  • Clear and precise information about problem frequency. For example, the problem occurs only weekly, or at the same time every day, or it just appears to be random.
  • Specifics about tenant, environment, user, activity ID, batch job, and API.
  • A comprehensive description of all the triage steps undertaken by yourselves, including traces, log files, and information about whether the problem is reproducible in other environments and which ones.
  • Any additional information that might be relevant to us.

The customer impact statement

The customer impact statement is important for the support engineer and engineering teams to prioritize and properly route the ticket. If the request is urgent and/or high severity, the support engineer asks for this statement anyway. Providing the full impact statement at the beginning makes the support process more efficient, requiring less communication.