任何复杂的“产品”（无论是服务还是物质对象）都致力于长期满足客户的需求。 因此，使用“产品”的必不可少的部分是从消费者那里获得反馈，并将“产品”保持在适当的质量或具有指定的特征和参数。
在服务业务中，本质是提供服务或售后服务，成功的关键是解决客户问题的速度和效率。 似乎有些新鲜事物：已经撰写了许多有关技术或服务支持组织的文章和书籍。 但是，在B2B服务中，实际上没有讨论很多陷阱，包括因为没有针对它们的既定实用解决方案。 这些“石头”之一是作为客户应用程序解决方案一部分而出现的复杂的交互链，“合同”或“伙伴关系”。 链中的级别越高，控制最终质量和工作速度就越困难，这可能不会以最佳方式影响服务的最终用户。
与供应商和承包商的互动计划
当前，在售后服务和服务支持领域中，供应商，合作伙伴和客户之间的交互可以分为两种方案，除了在客户和承包商之间没有其他链接的模型之外。
方案1.供应商与合作伙伴的支持该方案用于客户的地理分布网络。 在这种情况下，客户可以直接与开发人员/制造商的技术支持或服务台联系。 供应商在其自己的级别上“关闭”部分问题，但是在需要“实际”存在的情况下，客户会吸引合作伙伴来解决该应用程序。
供应商不仅在需要“实际”存在的情况下与合作伙伴一起使用该计划。 市场上有些公司的工作模式仅提供供应商支持，而该公司没有专职专家。 寻找合作伙伴而无需直接与最终客户的决策者直接联系便会提供这种支持的成本更低/更容易。 此外，通常为了控制所执行工作的质量，将应用程序退回给已决定或定稿到更高级别的卖方公司。
方案2.合作伙伴与供应商的网络如果有必要在本地（例如，更换备件）或在项目后支持（当实施项目也由合作伙伴实施，然后得到支持）时使用该模型。 在此模型的框架内，供应商“建立”了一个会员网络，最终客户与合作伙伴签订了支持合同，结果，客户请求被发送到其
服务台系统中的合作伙伴。 同时，在支持框架内，问题仍然存在于“第三条线”上，需要开发人员参与：修复系统中的错误，在保修期内更换，发行补丁等。
复杂的方案。 吸引承包商解决一些问题在实践中，以上两种技术和服务支持模型（在更大程度上是其中的第二种）实际上都被多个级别的分包商，子伙伴（我们知道具有3个或什至4个级别的子伙伴关系的故事）“复杂化”。例如，发生这种情况，如果联邦客户公司要求在多个地区都设有办事处，或者在最初根据该地区的专有性模型建立会员网络的情况下。
随着时间的流逝，这样的合作伙伴将无法独立有效地为来自整个地区的客户提供服务，并且由于客户是“固定的”，因此他们正在建立自己的“子伙伴”网络。 吸引承包商，只是简单地优化成本和“重定向”应用程序。
现有模型的缺点
每个描述的模型都有其优点和缺点。 例如，一种方案不仅允许卖方控制所有客户问题并保证更高的支持质量，而且还可以接收第一人称信息，这意味着开发产品并更快，更准确地响应客户的要求。 另一个毋庸置疑的优势是能够评估合作伙伴的工作质量并快速更改交互方案（例如，无法应对支持任务的变更合作伙伴）。
另一方面，这种方案对于供应商来说是相当昂贵的，因为它涉及通过Service Desk系统进行自动化方面的组织自己的第一线支持和大量许可证。 合作伙伴意识到该模型将无法进行额外的销售，因此他们正在尝试谈判一种更具财务意义的方案。 否则，最终质量会受到影响。
相反，第二种方案允许合作伙伴赚更多钱，包括追加销售。 在此方案中，卖方在组织技术支持方面并没有多大成本。 不利的一面是，很难控制对最终客户的最终支持质量。 此外，在竞争激烈的市场中，合作伙伴可以轻松地将客户吸引到其他产品上。 并且，当然，从“产品”开发的角度来看，没有直接的反馈。
实践表明，不管技术支持的模式如何，制造商几乎总是对最终客户“负责”。
通过自动化或Service Desk系统在哪里进行乘法
奇怪的是，当自动化技术支持的问题与这些通信联系在一起时，两种模型中出现的问题变得更加复杂。 事实是，除了“电子邮件”或“即时通讯程序”（根据我们的统计，基于与10,000多家服务公司的通信，例如90左右）之外，绝大多数服务公司和供应商都没有使用任何自动化系统（帮助台或服务台） ％）。 那些使用某些自动化解决方案进行注册，记帐和处理应用程序的应用程序不会相互集成。
这是一个自相矛盾的情况：在任何方案中，都必须自动化处理客户端应用程序的端到端过程，但是合作伙伴，子合作伙伴和供应商的客户支持系统（如果存在的话）实际上是不互连的（有时通过相同的电子邮件转发）。 在极少数情况下，合作伙伴或承包商在客户或供应商系统中工作。 这只会给双方增加麻烦，因为它要么导致过多的许可，要么“迫使”承包商在不同供应商/总承包商的不同系统中工作（是的，在市场上，几乎任何服务公司都是多个供应商或较大服务公司的合作伙伴）。
历史悠久的工作计划的结果以及两种合作计划中所描述问题的单一解决方案的结果，公司不可避免地要面对许多成本，例如：
- 应用程序丢失或“消失”。 由于客户流通数据和应用程序数据之间缺乏通信，因此系统（Excel合作伙伴/承包商标牌）缺乏可见性和透明度。 结果，可管理性下降，解决问题的最后期限膨胀或提供有关其当前状态的答案。
- 在执行者众多的情况下，很难评估他们每个人对解决问题的贡献。 通常，这会导致服务质量下降，结果使供应商的形象恶化。
- 该方案的不透明性以及无法控制应用程序解决方案的所有阶段，导致流程参与者之间的相互解决问题。
- 多窗口操作模式（在服务公司被迫在不同供应商或总承包商的多个系统中工作的情况下）增加了最终承包商的员工的负担，结果导致重要信息的丢失，部分工作期限的增加以及拒绝从事此类工作型号。
摆脱困境的方法
无疑，所有相关方的服务台系统的集成都可以成为摆脱这种情况的一种方法。 当在两种方案中工作时，集成将解决所有上述问题，包括复杂的问题。 但是，正如我们所说，实际上，只有少数公司使用一些现成的解决方案。 另一方面，由于实施这种方案的复杂性和成本，市场上没有工具允许在传输应用程序以及在它们之间进行协作方面对不同系统进行“端到端”集成。
考虑到类似情况的类似雪崩般的情况，我们在开发用于自动执行所有售后和售后服务流程的
帮助台系统时，每天都会遇到类似的情况，以及已经在日常工作中使用Okdesk的服务公司和制造商的数量（今天〜500 ），我们为市场提供了一条出路-帮助台系统之间的现成集成。
该解决方案允许您单击几次以链接两个或多个Okdesk帐户，以便在应用程序上一起工作。 之后，要解决客户票证，您不仅可以吸引“有执照的”员工，而且可以吸引关联的帐户（并且不需要额外的执照）。 在实践中，它的简化形式如下：
- 在将应用程序转移到“关联”帐户时，后者会创建与原始应用程序相关的应用程序，并在必要时汇总与客户的联系信息，与支持的基础架构项目的通信，初始描述，文件等信息；
- 每个参与者继续在其应用程序中（在其自己的系统中）工作，同时同步执行者添加的公共评论和文件（内部通信和与原始应用程序中的客户的通信分开保存）；
- 在每个链接的帐户中都可以看到应用程序的状态和ID（这有助于避免对客户端应用程序的可控制性“损失”）；
- 在合作伙伴帐户中完成应用程序后，您可以评估承包商/合作伙伴/供应商的质量并继续解决应用程序的过程。
承包商与承包商之间互动的统一，不仅可以节省许可，而且可以显着加快应用程序及其解决方案的转移过程。 这最终会影响客户满意度。 此外，该模型允许您从创建之时到最终的响应传达给消费者之前，将应用程序跟踪到“总承包商”（客户正在与之联系并由谁承担责任），从而控制每个阶段的执行质量。
与大型公司的Service Desk系统集成又如何呢？
Okdesk系统之间的现成集成当然是好的。 但是，如果客户是大公司（有条件的Sberbank，X5 Retail Group等），该怎么办？ 在这种情况下，您不得不在客户系统上以非常有限的模式工作，或者通过电子邮件向您发送故障单。
Okdesk早就解决了这个问题。 与绝大多数大型的分布式联邦公司一样，我们拥有现成的模板集成，可以根据要求连接或修改！
从理论到现实情景和实践
目前，在多个行业（“供应商”-“合作伙伴”版本以及“客户”-“承包商”版本）都使用了类似的模型：HORECA，收银机设备维护，IT外包。 对用户反应的分析表明，集成解决方案平均可将解决应用程序所需的时间减少多达40％，并将来自客户的负面评论数量减少约20％。
这是它的工作方式：
使用不同的服务台系统时，您如何与承包商，客户和合作伙伴进行互动？