用户支持：持续生产解决方案支持

下一节介绍支持 Microsoft Power Platform 解决方案（如应用、流和聊天机器人）用户的正式和非正式方式。

此图显示了组织成功采用的通用支持和升级框架：

类型	描述
	当制作者支持他们自己的解决方案时发生自助支持（内部）事件。 解决方案的用户知道应与制作者联系来获得支持，并且 IT 或团队通常无法了解制作者提供的支持级别或类型。
	当团队成员在开发 Power Platform 解决方案过程中相互学习时，就会发生团队辅助支持（内部）事件。 团队成员成为其团队应用、流和聊天机器人的共同负责人。 共同负责人能够支持用户查询，并且可以进行小 bug 修复和更改。 虽然团队辅助支持有时以非正式方式提供，但随着您的采用和发展达到成熟阶段，将这个过程正式化是一个好主意。
	帮助中心支持（内部）将处理正式支持问题和请求。 帮助中心可以帮助解决诸如如何访问移动设备上的应用或如何请求访问后端数据源等问题。 他们会将与解决方案相关的问题重定向到支持解决方案的渠道。
	专用 Power Platform 支持（内部）涉及处理服务中心上报的复杂问题。 关键应用程序会被移交给此团队，他们能够部署 bug 修复。
	合作伙伴支持（外部）可以补充您的内部支持服务，针对关键应用程序提供支持，或者与特定部门一起针对其应用提供支持。 了解详细信息：从 Power Apps 合作伙伴那里获得专家帮助
	Microsoft 支持（外部）可用于提出与平台相关的技术问题。 根据您的支持计划，您可以获得不同的技术支持和咨询服务。 了解详情：对 Microsoft Power Platform 的支持

根据您的组织规模以及低代码和专业代码技术的现有交付方法，您可能会选择不同的方式来实现支持的正规化。 如果您的 Power Platform 采用方法在很大程度上是分散的，那么您将拥有跨组织的自主团队来交付和管理 Power Platform 解决方案。 借助此模型，也可以委派支持，团队辅助支持可能是用户和制作者的最相关服务。

如果您的 Power Platform 采用方法在很大程度上是集中的，那么您将拥有产品负责人中央团队，他们负责从组织业务部门进行部门解决方案低代码交付。 借助此模型，支持也将集中化，中央支持团队会回答查询和问题。

在大多数组织中，混合交付模式是最佳模式—即使分散的团队为其制作者提供解决方案支持，技术问题、用户查询和一级支持仍可能需要帮助中心和中央支持团队给予帮助。

定义应用程序层

当您定义支持流程和升级途径时，根据关键性对生成的解决方案进行分类很重要—这将使您能够设计出流程，以确保关键应用程序有必要的护栏来支持它们，同时不会扼杀生产力方案创新。

特征和流程	生产力	重要提示	关键
用例	可以使用现有数据的个人生产力和小型团队用例。	简单的商务应用程序或团队活动。 小型独立协作流程。	停机期间会对业务产生重大影响的复杂商业应用程序、企业范围计划或任务关键型工作负载。
复杂性	简单流程。	中等复杂度。	高复杂度。
用户群	小型用户群 – 单个用户、直接同事或小型团队。	适用于业务部门。	大型用户群或企业范围的使用。
开发生命周期	高级迭代。	开发时间通常不到三个月。	较长的开发周期。
影响	较小业务影响。	重要但不是业务关键（中等影响）。	较大业务影响。
ALM	不需要 ALM。	需要 ALM - 可以通过手动导入/导出解决方案来实现。	需要可靠的 ALM 流程 – ALM 通过 Azure DevOps 或 GitHub 管道来实现。
环境策略	解决方案内置于默认或共享生产环境中。	专用开发环境，以及共享的测试和生产环境（与其他解决方案共享 – 例如，特定于业务部门的解决方案）。 环境由业务部门（分散）或中心 IT 部门（集中）管理。	专用开发/测试/生产环境。 环境由中心 IT 部门进行管理。
制作者权限	制作者在环境中具有环境制作者安全角色。	制作者在开发环境中具有环境制作者或系统定制员安全角色，但在测试和生产环境中仅具有最终用户安全角色。 解决方案可能由测试和生产中的服务帐户或环境管理员负责。	制作者在开发环境中具有环境制作者或系统定制员安全角色，但在测试和生产环境中仅具有用户安全角色。 解决方案部署自动发生，解决方案由测试和生产中的服务主体负责。
IT 参与	反应式治理 - IT 部门可以看到正在构建的解决方案并监控使用情况。	解决方案或用户级别的 IT 部门批准。 制作者提供解决方案详细信息，如可能的解决方法和使用的数据源。	生产环境由 IT 部门进行管理。
支持模式	自助支持。	团队辅助支持。	正式支持。

在定义支持模式时，还要考虑升级路径—解决方案可能一开始只需要生产力级别的支持，但随着功能或用户群的增长，需要重要级别的支持。 确定制作者如何请求更正式的支持并将解决方案过渡到受支持的环境。

本文中更详细地描述了上面介绍的每种用户支持类型。

制作者支持（自助支持）

制作者支持是指制作者对自己的应用以及为他们自己、其团队或同事构建的流提供支持。 这意味着回答用户的查询、修复 bug 和提出更改请求。 这是一种非正式的支持方式；用户通常知道制作者是谁，并且会直接与他们联系。

重要提示

在培训新制作者的过程中，请确保制作者了解支持、升级和提升途径—被业务重要解决方案支持压得喘不过气来的制作者将无法再进行创新和创建新解决方案。 清楚地定义制作者如何将其解决方案升级到更高级别的支持，以及该支持是什么样的。

除了采用这种主动向制作者传达流程的方式之外，还要确保实施反应式治理，以识别对业务可能很重要的高度共享和高度使用的解决方案，并与制作者联系以确保这些解决方案具有必要的支持护栏。 使用租户级别的分析查找有关应用程序使用情况的更多信息，将遥测数据导出到您自己的数据存储帐户，以生成您自己的增强型报表或使用 CoE 初学者工具包作为起点。

团队辅助支持

团队辅助支持是指团队成员共同负责为其团队构建或由团队使用的应用和流，并在日常工作中帮助针对解决方案提供支持。 这意味着回答用户的查询、修复 bug 和提出更改请求。 以您的支持者身份出现的制作者往往会自愿承担这种非正式的支持角色，因为他们从内心希望提供帮助。

虽然这通常以非正式流程开始，但许多组织会将团队辅助支持正规化，以调节他们的 Power Platform 工作。 这涉及对其专用环境负责、担任环境管理员角色并在这些环境中针对解决方案提供支持的业务部门。 在较大的组织中，每个业务部门都有专门的 Power Platform 团队担任此角色。

帮助中心支持

帮助中心通常作为共享服务由 IT 部门运营。

帮助中心可以：

• 对在没有 IT 部门参与的情况下无法解决的技术问题提供支持—例如需要管理员在 Power Platform 管理中心提交支持票证的 Power Platform 服务问题。
• 回答用户和治理相关问题，例如如何请求访问应用程序或在哪里可以找到应用程序。
• 将关键应用的问题传递给正确的支持团队。

专门的 Power Platform 支持团队

当您的采用率提高以及制作者开发出对业务更重要和更关键的解决方案时，您可能需要一个专门的 Power Platform 支持团队。

此团队应包含可以对复杂问题提供支持的 Power Platform 技术专家。 应该通过支持票证按照定义的路径让此团队参与支持流程。

该团队将对部署到专用集中式支持环境的任务关键型 Power Platform 解决方案提供支持。

如果您的组织结构是分散的，您可能需要考虑使团队辅助支持正规化，以与当地区域或业务部门保持一致，让中央 Power Platform 支持团队仅帮助处理复杂的查询或中央配置，例如 DLP 策略。

一些客户选择将此级别的支持外包给合作伙伴。

由于这些 Power Platform 技术专家通常为业务用户所熟知，因此将请求作为单纯的帮助中心升级途径来管理变得难以实施。 为了鼓励使用适当渠道的习惯，该团队应重定向用户以提交服务中心票证。 它还将提高数据质量来分析服务中心请求。

合作伙伴支持

许多客户在采用 Power Platform 时选择与合作伙伴合作，包括支持。 这可以包括为制作者提供发展协助、帮助建立 CoE 和技术支持程序，以及为您的服务中心和制作者提供培训，以及对关键应用的 24/7 技术支持。

Microsoft 支持部门

Microsoft 支持用于提出与平台相关的技术问题。 根据您的支持计划，您可以获得不同的技术支持和咨询服务。

小费

在提交支持票证之前，还要检查 Power Apps 支持、Power Automate 支持和 Power Virtual Agents 支持 ，以解决广泛影响所有客户的高优先级问题。

注意事项和关键措施

注意事项和为改进自我支持和团队辅助支持解决方案而可以采取的关键措施：

• 认可和鼓励制作者。
• 确保制作者了解升级流程，以便将他们的解决方案升级到更正式的支持渠道。
• 为制作者提供办公时间、导师机会和培训课程，以继续提高他们的技能。
• 提供升级途径供陷入困境的制作者与 Power Platform 技术专家联系。
• 创建适用于制作者的模板组件，以纳入其应用中，例如供用户与帮助中心联系的窗体。
• 根据工作量和需要特定业务领域支持的解决方案数量，评估正规化团队辅助支持。

注意事项和为改进内部帮助中心支持而可以采取的关键措施：

• 确定帮助中心将处理的 Power Platform 主题的初始范围。
• 评估帮助中心处理支持的就绪程度。
• 根据就绪情况差距，为帮助中心工作人员安排更多培训。
• 确定帮助中心无法直接处理的请求的升级路径。
• 更新帮助中心的已知 Power Platform 主题的知识库。 确保有人负责定期更新知识库，以随着时间的推移反映新功能和增强功能。 通过订阅 Power Apps 博客、Power Automate 博客和 Power Virtual Agents 博客 RSS 源来了解最新信息。
• 确保建立良好的问题跟踪系统。 它通常是一个可以管理优先级的票证系统。
• 决定是否有人随时待命处理与 Power Platform 相关的任何问题。 如果适用，请明确对 24/7 支持的期望。
• 确定将存在哪些 SLA，并明确传达对响应和解决方案的期望。
• 做好快速解决特定常见问题的准备。 例如，应快速处理使用新连接器的请求。 支持响应速度慢可能会导致用户找不到解决方法。
• 确保您的帮助中心具有一个安全角色，以允许他们向 Microsoft 提交支持票证。 确定服务中心或专门的支持团队是否会对这些问题进行分类。

注意事项和为改进内部 Power Platform 专属支持而可以采取的关键措施：

• 清楚地确定服务中心职责的终点，以及专门的支持职责的起点。
• 确保 Power Platform 专属支持团队有直接升级途径来联系 Microsoft 365 和 Azure 的全局管理员。 当出现超出 Power Platform 范围的广泛问题时，这一点至关重要。 此类问题可能与 Power Platform 解决方案中使用的用户帐户和权限、网络配置或数据源有关。
• 创建从专门的支持团队到服务中心的反馈循环，以便可以更新 IT 知识库。 目标是让主帮助中心为将来处理更多问题做好更充足的准备。
• 创建从服务中心到专属支持团队的反馈循环。 当支持人员发现冗余或效率低下时，他们可以将该信息传达给专属支持团队，后者可能会选择更改或改进内部流程。 示例：如果帮助中心忙于为制作者创建和配置新的 Power Platform 环境，则专属团队可能会考虑使用 CoE 初学者工具包中的环境请求管理组件来自动执行此流程。
• 创建从对自己的解决方案提供支持的个人到专属支持团队的升级途径，以便他们能够在遇到自己无法解决的问题时畅通无阻。
• 创建从对其解决方案提供支持的个人和团队到专属支持团队的移交路径，以便关键应用程序可以过渡。
• 确定将解决方案转交给专属团队的总体策略—随着重要和关键解决方案数量的增加，您是会增加专属支持团队的人员，还是依赖业务部门为其领域的支持团队配备人员？