Problems of interaction with vendors and within the "contract" chain. Analysis of current schemes: pros and cons for companies

Any complex “product” – whether it is a service or a material object – is focused on long-term satisfaction of the needs and requirements of the client. Accordingly, an integral part of working with a “product” is to obtain feedback from the consumer and maintaining the “product” in proper quality or with specified characteristics and parameters.

In the service business, the essence of which is the provision of after-sales or after-sales service, the key to success is speed and efficiency in solving customer problems. It would seem that there is something new: a lot of articles and books have been written about the organization of technical or service support. However, in b2b service there are many pitfalls that are practically not discussed, including because there are no established practical solutions for them. One of these “stones” is a complex chain of interaction, “contracts” or “partnerships” that arise as part of the solution of client applications. The more levels there are in the chain, the more difficult it is to control the final quality and speed of work, which may not affect the final user of the services in the best way.

Schemes of interaction with vendors and contractors

Currently, the interaction of the vendor, partners and customers in the field of after-sales service and service support can be divided into two schemes, except for the model in which there are no additional links between the customer and the contractor.

Scheme 1. Vendor support with partners

The scheme is used in the case of a geographically distributed network of customers. In this case, the client directly contacts the technical support of the developer / manufacturer. The vendor “closes” part of the questions at its own level, but in a situation where a “physical” presence is required, the client attracts partners to solve the application.

Vendors use a scheme with partners not only in cases where a “physical” presence is necessary. There are companies on the market whose work model provides exclusively vendor support, while the company does not have its full-time specialists. It is cheaper / easier for her to find partners who will provide this support without having direct contact with the end-user’s decision makers. Further, usually in order to control the quality of the work performed, the application is returned to the vendor company, either already decided, or to be finalized to a higher level.

Scheme 2. Network of partners with a vendor

The model is used if it is necessary to have a “local presence” (for example, to replace spare parts) or in the case of post-project support (when implementation projects are also implemented by partners, and then they are supported). Within the framework of this model, the vendor “builds” an affiliate network, end customers conclude support contracts with partners, and, as a result, clients come to partners. At the same time, within the framework of support, questions remain on the “third line” that require the involvement of a developer: fixing bugs in the system, replacing under warranty, issuing patches, etc.

The complicated scheme. Attracting contractors to resolve some issues

Both of the above models of technical and service support (to a greater extent – the second of them) are in practice “complicated” by several levels of subcontractors, sub-partners (we know about stories with 3 or even 4 levels of sub-partnership), etc. This happens, for example , in the case of a federal customer company requiring a presence in several regions or in situations where the affiliate network was originally built according to the model of exclusivity in the region.

Over time, such a partner is faced with the impossibility of independent effective customer service from all over the region, and since customers are “fixed”, they are building their own network of “sub-partners”. Attract contractors and simply to optimize costs and "redirect" applications.

Disadvantages of Existing Models

Each of the described models has its pros and cons. For example, 1 scheme allows the vendor not only to control all customer issues and guarantee a higher quality of support, but also to receive first-person information, which means developing the product and responding to customer requests more quickly and precisely. Another undoubted advantage is the ability to evaluate the quality of partners' work and quickly make changes to the interaction scheme (for example, change partners who cannot cope with support tasks).

On the other hand, such a scheme is quite expensive for the vendor, because it involves the organization of its own first line of support. The partners, realizing that the model will not be able to conduct additional sales, are trying to negotiate a more financially interesting scheme. Otherwise, the final quality suffers.

The second scheme, on the contrary, allows partners to earn more money, including upsells. In this scheme, the vendor does not have large costs for organizing technical support for its part. The flip side of the coin is that it’s difficult to control the final quality of support for end customers. In addition, in a competitive market, a partner easily drags a customer to other products. And, of course, from the point of view of the development of the “product” there is no direct feedback.

Practice shows that regardless of the model of technical support, the manufacturer is almost always “to blame” for the end customer.

Multiplying by automation

The problems that arise in both models, in reality, become much more complicated when, oddly enough, the issue of automating technical support and these very communications is connected. The fact is that the vast majority of both service companies and vendors do not use any automation systems (Help Desk or Service Desk) other than “email” or “instant messengers” (according to our statistics, based on communication with 10,000+ service companies, such ~ 90 %). And those that use some automation solutions for registration, accounting and processing applications are not integrated with each other.

It turns out a paradoxical situation: in any of the schemes it is necessary to automate the end-to-end process of processing client requests, but the customer support systems of partners, sub-partners and vendors (if they exist) are practically not interconnected (occasionally through the same email forwarding). In rare cases, partners or contractors work in the customer or vendor system. This only adds problems to both parties, because it either leads to excessive licensing, or “forces” the contractor to work in different systems of different vendors / general contractors (yes, on the market, almost any service company is a partner of several vendors or larger service companies at the same time).

The result of historically established work schemes and a single solution to the described problems in both cooperation schemes, companies inevitably face a number of costs, for example:

Applications are lost or “disappear”. Due to the lack of communication between the data on customer circulation and the data on the application in the system (excel nameplate of the partner / contractor), there is no clarity and transparency. As a result, a decrease in manageability, inflating the deadlines for solving a problem or providing an answer about its current status.
With a long chain of performers, it is difficult to assess the contribution of each of them to the solution of the problem. Often this leads to a loss of quality of service, and ultimately worsens the image of the vendor.
The opacity of the scheme and the inability to control all stages of the decision of applications leads to problems in the mutual settlements between the participants in the process.
The multi-window mode of operation (in the case when the service company is forced to work in several systems of different vendors or general contractors) increases the load on the employees of the final contractor and, as a result, leads to the loss of important information, an increase in the deadlines for completing one part of the work, and refusal to work in such models.

Way out

Undoubtedly, the integration of the Help Desk systems of all involved parties could become a way out of this situation. Integration would solve all the above problems when working in both schemes, including the complicated one. But, as we said, in practice, only a few companies use some ready-made solutions. On the other hand, there were no tools on the market that allowed for “end-to-end” integration of different systems in terms of transferring applications and working together on them due to the complexity and high cost of implementing such a scheme.

Given the avalanche-like com of similar situations that we began to face on a daily basis when developing the Help Desk system for automating all processes of after-sales and after-sales service, coupled with the number of service companies and manufacturers that have already used Okdesk in their daily work (today ~ 500 ) we offered the market a way out – ready integration between the accounts of Help Desk systems.

The solution allows you to link two or more Okdesk accounts in a couple of clicks in order to work together on the application. After that, to solve the client ticket, you can attract not only “licensed” employees, but also associated accounts (and this will not require an additional license). In practice, this in a very simplified form works as follows:

when transferring an application to an “affiliate” account, the latter creates an application related to the original application, aggregated, if necessary, information on contacts with the client, communication with a supported infrastructure item, source descriptions, files, etc .;
each participant continues to work in his application (in his own system), while public comments and files added by the executors are synchronized (internal correspondence and correspondence with the client in the original application are kept separately);
the statuses and IDs of applications are visible in each of the linked accounts (this helps to avoid the “loss” of controllability over the client’s application);
upon completion of the application in the partner account, you can evaluate the quality of the contractor / partner / vendor and continue the process of solving the application.

This unification of the interaction of contractors and contractors makes it possible not only to save on licensing, but also significantly speeds up the process of transferring applications and their decisions. This ultimately affects customer satisfaction. Moreover, the model allows you to track the application to the “general contractor” (to whom the client is contacting and who bears obligations to him) from the moment of its creation to the transmission of the finished response to the consumer, controlling the quality of execution at each stage.

And what about integration with Service Desk systems of large companies?

Ready integration between Okdesk systems is, of course, good. But what if the customer is a large company (conditional Sberbank, X5 Retail Group, etc.)? In this situation, you are forced to work in a very limited mode on the customer’s system or send you tickets by email.

Okdesk has long resolved this issue. With the vast majority of large distributed federal companies, we have ready-made template integrations that we connect or modify upon request!

From theory to real-life scenarios and practice

At the moment, a similar model is used in several industries (both in the “vendor” – “partner” version, and in the “customer” – “contractor” version): HORECA, maintenance of cash register equipment, IT outsourcing. Analysis of user reactions shows that, on average, integrated solutions can reduce the time it takes to resolve applications by up to 40%, and the number of negative reviews from customers by about 20%.

And here is how it works: