Set up a technical support team

  • Artigo

Your technical support team is responsible for providing technical assistance and maintenance for your Dynamics 365 solution. You should set up your technical support team during the Implement phase of your project, based on the support model that you choose. You should also consider the size, complexity, and scope of your project and the skills and resources that you need.

Support team responsibilities

Your technical support team might need to cover various areas of responsibility, such as:

  • Support for business process areas: This involves liaising with process owners, understanding the system functions, analyzing and triaging issues, communicating with users and resolving authorities, and monitoring the issue resolution process.

  • Support for technical areas: This involves managing service and system operations and updates, system monitoring and maintenance, application management, and other technical tasks.

  • Support for data quality maintenance: This involves liaising with data stewards, auditing and reporting on data quality, and making core data or configuration changes as needed.

  • Support for user proficiency in the system: This involves monitoring user proficiency, creating and conducting training, conducting change management activities, and improving user adoption.

  • New features and developments: This involves keeping track of new requirements or updates that might affect the system, assessing their impact, testing the changes, updating documentation, training users, communicating the changes, managing the release process, and refreshing the support environments.

You should define these areas in more detail to make sure that you have sufficient planning for your support model. Learn more about operational considerations of servicing your solution.

Support organization structures and roles

Your support organization structure depends on several factors, such as:

  • The type of support model that you choose (fully internal, fully external, or mixed)
  • The size and complexity of your implementation
  • The functional spread and geographical distribution of your users
  • The level of customization or integration in your solution

You can choose from different types of roles to fill your support organization structure. Some common roles are:

  • Business super users are part-time roles that serve as frontline support within each business unit. They have deeper knowledge of the system and processes and can help other users with simple questions or issues.

  • Business process experts are full-time or near-full-time roles that serve as second-line support for each business process area. They have a deep understanding of the system functions and the business priorities and can analyze and triage issues, communicate with users and resolving authorities, and monitor the issue resolution process.

  • Technical architect, also called system architect or solution architect, is a role that oversees the technical standards and architecture of the solution. They have a deep understanding of the underlying technical processes and components involved in the system functions. They also coordinate the technical tasks and duties of the support team.

  • Technical experts are roles that have expertise in technical servicing and support duties, such as managing service and system operations and updates, system monitoring and maintenance, and application management.

  • Developers are roles that are responsible for bug fixes to custom code and writing code for new custom functionality.

  • Release manager is a role that's responsible for validating and deploying releases to production. They also follow the expected standards, testing regimen, and deployment process for any fixes or changes.

  • Support manager is a role that's accountable for the support services for Dynamics 365 applications, and often for other related systems.

  • Business and IT stakeholders are roles that provide sponsorship, direction, prioritization, and decisions for the support organization. They also define fit-for-purpose processes and expectations for support.

Depending on your support model, you might have these roles filled by internal staff, external partners, or a combination of both. You might also have a Dynamics 365 Center of Excellence (CoE) that brings together specialist knowledge and resources across different business units or companies.

Microsoft offers different levels of support for your Dynamics 365 products. Learn more about servicing your solution.

Budgets, contracts, and agreements

When you introduce a new system into your enterprise architecture, you might need to make changes to your budgets and support agreements. This is because some changes might affect related systems or processes that involve different departments or other parties.

You should review your budgets and agreements based on the new system solution blueprint, enterprise architecture, and support organization. You should also map out the tasks and activities that are in scope for your support organization to the various roles and resolving authorities that are involved in the issue resolution process. This will help you avoid any gaps or conflicts in the flow.

For internal parties, you might need to define budget and resource splits and informal service delivery agreements. For partners, you might need to define formal contracts with formal SLAs. You should make sure that these agreements reflect the expected tasks and service expectations for your support organization.

Next steps

  • Review a checklist for implementing your support model
  • Read a case study to understand why you need to develop and audit your support strategy in the cloud world