The specifics of the technical support of the modular system
Hello!
My name is Alex, I am a technical support engineer. Today I’ll talk about how Helpdesk is built in DoxVision, taking into account the specifics of the platform software. Perhaps this information will help companies that are already working closely in the Helpdesk, as well as those who are just planning to build a channel of communication with customers. By the way, a number of Docsvision partners have already taken advantage of our experience and implemented the Helpdesk with our help.
All companies whose business is based on the provision of certain IT-services tend to be customer-oriented, and DoxVision is no exception. Like many other vendors, we not only produce the software ourselves, but also provide technical support services, we strive to provide them with high quality and timely.
')
Many times I have come across the fact that in companies they provide customer support services from a technical point of view. On Habré there are several articles on this topic, and here is another one from which you will learn how it happens with us.
The software development process (and large software in particular) can be carried out according to various schemes, but in the end it all comes down to several key points and tools that can be used:
• Development environment;
• Version control system;
• Task tracker;
• Automated and manual testing systems;
• Bug tracker;
• Helpdesk.
Of course, items can be supplemented, merged or removed too much, affecting only a few aspects, you can start a small holivar :)
But my goal today is different.
Software needs to be invented, developed, tested, released into a large voyage (as we say “ship”) and start supporting it. Since the history of the company and the Docsvision EDS began a long time ago, then in 2014 we have several versions of our platform in support:
Each platform version has at least 2 release versions with a full name, for example, Docsvision 5.3.2529, i.e. about 10 versions at the same time turn out. To this should be added about 40 more modules of the platform. We support all this variety of products and release versions of Docsvision in work in parallel and every day.
Some of our clients have been working with us since early versions. The electronic document management system at the enterprise implies a long-term partnership with the software vendor, and technical support for organizations in which the flow of incoming and outgoing documents does not stop even for a day, plays a significant role.
From the first versions of Docsvision to this day, we ourselves provided technical support, and the starting point of entry was regular mail. Users in the letters reported difficulties, attaching screenshots and logs. During the correspondence, urgent issues were resolved, the knowledge base was accumulated, and gradually with the expansion of our company and the growing number of clients, the number of requests from them grew. To process them, a solution (or a set of solutions) was needed, which would help to structure all the data obtained.
At the beginnings of the helpdesk process in the company, to this day stands the mighty “stone”, whose name is DVManagement. And now is the time to move smoothly to what we use within the company.
DVManagement is a server with an installed Docsvision platform, located in the depths of our company, with which technical support engineers (and not only them) work with their jobs. Now the server has the latest release version of our platform and added special “cards”, which we call issue. DVManagement is, in fact, our platform with the added functionality of bugtracker and helpdesk for handling internal and external calls, which include:
• Record new requirements for the implementation of the functional;
• Record errors;
• Record fixes (knowledge base);
• Test cases (in small quantities);
• To-do plans (in small quantities).
Since the “platform” is quite large, not all divisions in the company use only “our” bug tracker, some of the work is being done in the Team Foundation Server repository (and previously SourceSafe).
TP employees work daily with Issue cards, which look like this:
Issue is a link between our two support tools, and also serves for interaction of the type “Engineer TP-Software Developer”.
The card has the necessary fields that must be filled out (product version, the name of the company-customer, etc.)
There are several tabs that contain additional information about the status of the issue and present such standard options as:
• Attaching files and comments (with versions);
• Communication history engineer -> developer (a tester or analyst can also be included in this process);
• Set the status of "error";
• Request prompt correction of this error;
• Ability to link multiple cards.
Previously, prior to the introduction of external interaction tools, all correspondence with customers was transferred from mail to DVManagement. Now it is all saved and used as a great knowledge base. With the advent of external services, the process was slightly modified: additional fields and options were added to the issue card. Each time the issue status changes, as well as any fields change, the author of this issue receives email notifications of the changes made. In other words, nothing will go unnoticed.
Currently, the system already has about 7000 created issue, used by technical support staff, and all in all about 60,000 objects created during the period from 2006 to 2014. I do not claim that “the more the better”, but the knowledge base is updated daily. This is very helpful, for example, when training new support staff.
Along with DVManagement, we needed a tool that would allow us to more conveniently record incoming requests - and Zendesk was chosen, and we started working in 2011.
Zendesk is delivered as a service (SaaS), in the form of a site that is accessible to both us and our customers. This is a high-availability system (hosted on Amazon), aimed specifically at handling calls, requests, or “tickets,” as the questions within Zendesk are called.
DoxVision has its own technical support portal, which is available for review even without registration. And registered users can write to us on the forum, and, with a paid update package, create applications during this entire period (for example, during the year).
Some key points:
• To work, you need to create accounts for support engineers called “agents”. There are about three dozen such agents in DoxVision.
• There is an extensive system of forums in which customers can ask questions and receive answers from support engineers, as well as communicate with each other - a typical example of a development forum (registration is required). In total, we have more than a dozen such sections.
• Enhanced event notification system.
• Support for customizable SLA.
• Access control system (there are different categories of user accounts - agent, end user, forum administrator, global administrator).
• Convenient linking of end users to their companies.
• If desired, several users from the same company can participate in correspondence in parallel.
• Extended application status (except “open”, “closed”, “resolved”), awaiting certain events from outside.
• A system of macros and triggers (example: distribution of an application for a more “free engineer”).
• Advanced reports on many events.
• Mobile applications for all platforms (now we can respond to requests from anywhere).
• Integration with social networks.
sample mobile application for windows phone 8
Below is a screenshot of the support agent interface:
Users registered on the portal can create applications that will be automatically taken to work. The entry point in this case is the support portal itself (available at the address) and e-mail: the letter sent to a special address is immediately converted into an application - this is another feature of Zendesk.
When creating an application in the helpdesk, the user must fill in certain fields, describe the essence of the problem, and, if desired, attach additional information (this could be a screenshot or some kind of log), this is how it looks
Zendesk allows you to have absolutely customizable fields in the created ticket: it can be a drop-down list, a radio button, or, for example, a choice from the list of values set by the administrator.
All applications created in this system are processed within the specified SLA and depending on the purchased package of services. By the way, the user can select the level of criticality by himself.
If we talk about the dynamics of the number of requests, then it can be seen in the pictures below (recall, 2011 is the year of introduction of Zendesk). For example, taken in 2013, which is still in the lead in the number of applications.
It is more interesting to observe the number of solved applications by months. On the graph above you can see how many were created per month, and what part of them was solved in the same month.
Also, for each engineer, statistics are kept, allowing you to collect KPIs within a week. It is worth noting that the number does not always indicate whether the engineer worked well or poorly during the week, because, as a rule, more complex issues are solved for a longer time.
Zendesk helps us build a channel of communication with customers and customers at a new level. The application created by the user will be processed taking into account the existing SLA ( Service Level Agreement - defines the mutual responsibility of the IT service provider and users of this service). And, as soon as we are talking about responsibility, I will mention the NDA ( Non-Disclosure Agreement ): we are committed to customers who are concerned about the confidentiality of the data transmitted to us, not to transfer them to third parties. Also in Docsvision there are tools that allow you to “de-personalize” user data transmitted to us in the course of work: a TP engineer will not be able to see personal data of users or read confidential information in client’s directories.
Although, according to the regulations, the TP service has an 8-hour working day, the work of engineers is structured in such a way that the watches of all engineers are distributed and cover the maximum possible time: for example, from 8:00 to 20:00. This is because technical assistance may be needed by customers in a different time zone.
Depending on the time of day, the activity also changes:
As you can see, the peak falls in the middle of the working day. Work is in full swing.
Due to the large number of Docsvision versions working for our customers at the same time, engineers should have at hand all possible Docsvision versions and combinations of installed modules. For such cases we use about 40 virtual machines. We use the hypervisor on VmWare technology.
But often even a large “zoo” of all versions of Windows, all Net Frameworks and barcode scanners (which we also use) may not be enough at some point.
For example, it may happen that an unexpected behavior will be found that is consistently reproduced only on physical machines (and not on virtual machines) or on touchscreen devices (monoblocks).
In case of finding critical errors in the system, in some cases our partners (and users) do not have the opportunity to wait for the release of a new version of the product or update the entire system - it is often time consuming, and not everyone is ready to wait.
Many errors, the elimination of which does not require much complexity, we solve with the help of operational fixes. If we are talking about a server, then it is enough to change one or two libraries, and the patch will be installed. Client jobs are still easier. Corrections can be obtained as on request, and placed in the public domain in the form of cumulative patches.
To minimize the downtime of critical systems (the workflow at the enterprise is not an exception), there is an emergency support service in DoxVision. We begin to interact with the customer as part of a faster SLA - the response time in such cases does not exceed 1 hour, and for the most part the engineers work online. In this case, we use all possible ways to communicate with the customer (Skype, Lync, remote connections) to quickly solve problems. If necessary, work will be carried out during off-hours. Thus, the time to localize the problem and release (if necessary) corrections is significantly reduced.
Under this name is a dedicated specialist from the technical support service. In this case, the controllability of the interaction process between the customer and technical support is enhanced. The engineer is the coordinator of the application (s) from one customer, he monitors the incoming applications and, if necessary, takes measures to more effectively address. There is a so-called. “Single window” in which you can ask both standard and related questions. The engineer in this case is represented as a “universal soldier” and takes on both technical and organizational issues (to arrange a conference call, provide a report on the weekly work done, etc.)
In the near future, the very scheme of the process of technical support, most likely, will not undergo any changes, but we always strive to do everything a little better by arranging work within the company and within the department.
After each executed ticket, the user who created it is offered to evaluate the work of the engineer by clicking "I like" or "I do not like". The rating thus formed is kept at around 96% -99% - it is available to everyone on a separate page (the data is dynamically changing).
According to internal regulations, every quarter we survey users (using Polldaddy ) and ask to evaluate the work on such items as response speed, politeness, completeness of information, first reaction time, etc. By collecting these data, we get a response, on the basis of which certain conclusions are drawn. One of the interesting requirements is the ability to communicate in real time with agents (Chat or Skype right inside Zendesk), the ability to escalate the problem to a higher level, the ability to integrate with other helpdesk systems or generate reports (from customers).
But, besides technological tools, helpdesk employees can be influenced in a different way: I think that a kind of Dashboard would be an excellent visual tool, allowing engineers (and managers) to track last minute applications in real time, for example, on a TV screen in the form of visual graphs.
Future plans also include holding daily meetings (similar to SCRUM) in which current work can be discussed, by the way, our colleagues from QA and Development have such meetings for a long time.
The helpdesk model, built in our company, is convenient for clients and, by the way, finds a response from our partners, because each of them at a certain stage is faced with the issue of organizing internal support. Several partner companies have already implemented such helpdesk with the help of our experience and knowledge.
If you are ready to share your experience, please in the comments - we will discuss.
My name is Alex, I am a technical support engineer. Today I’ll talk about how Helpdesk is built in DoxVision, taking into account the specifics of the platform software. Perhaps this information will help companies that are already working closely in the Helpdesk, as well as those who are just planning to build a channel of communication with customers. By the way, a number of Docsvision partners have already taken advantage of our experience and implemented the Helpdesk with our help.
All companies whose business is based on the provision of certain IT-services tend to be customer-oriented, and DoxVision is no exception. Like many other vendors, we not only produce the software ourselves, but also provide technical support services, we strive to provide them with high quality and timely.
')
Many times I have come across the fact that in companies they provide customer support services from a technical point of view. On Habré there are several articles on this topic, and here is another one from which you will learn how it happens with us.
Start
The software development process (and large software in particular) can be carried out according to various schemes, but in the end it all comes down to several key points and tools that can be used:
• Development environment;
• Version control system;
• Task tracker;
• Automated and manual testing systems;
• Bug tracker;
• Helpdesk.
Of course, items can be supplemented, merged or removed too much, affecting only a few aspects, you can start a small holivar :)
But my goal today is different.
Simultaneous support for multiple versions
Software needs to be invented, developed, tested, released into a large voyage (as we say “ship”) and start supporting it. Since the history of the company and the Docsvision EDS began a long time ago, then in 2014 we have several versions of our platform in support:
- Docsvision 4.5
- Docsvision 5.0
- Docsvision 5.1
- Docsvision 5.2
- Docsvision 5.3
- Docsvision 5.X
Each platform version has at least 2 release versions with a full name, for example, Docsvision 5.3.2529, i.e. about 10 versions at the same time turn out. To this should be added about 40 more modules of the platform. We support all this variety of products and release versions of Docsvision in work in parallel and every day.
Some of our clients have been working with us since early versions. The electronic document management system at the enterprise implies a long-term partnership with the software vendor, and technical support for organizations in which the flow of incoming and outgoing documents does not stop even for a day, plays a significant role.
early years
From the first versions of Docsvision to this day, we ourselves provided technical support, and the starting point of entry was regular mail. Users in the letters reported difficulties, attaching screenshots and logs. During the correspondence, urgent issues were resolved, the knowledge base was accumulated, and gradually with the expansion of our company and the growing number of clients, the number of requests from them grew. To process them, a solution (or a set of solutions) was needed, which would help to structure all the data obtained.
At the beginnings of the helpdesk process in the company, to this day stands the mighty “stone”, whose name is DVManagement. And now is the time to move smoothly to what we use within the company.
Internal tools
DVManagement is a server with an installed Docsvision platform, located in the depths of our company, with which technical support engineers (and not only them) work with their jobs. Now the server has the latest release version of our platform and added special “cards”, which we call issue. DVManagement is, in fact, our platform with the added functionality of bugtracker and helpdesk for handling internal and external calls, which include:
• Record new requirements for the implementation of the functional;
• Record errors;
• Record fixes (knowledge base);
• Test cases (in small quantities);
• To-do plans (in small quantities).
Since the “platform” is quite large, not all divisions in the company use only “our” bug tracker, some of the work is being done in the Team Foundation Server repository (and previously SourceSafe).
TP employees work daily with Issue cards, which look like this:
Issue is a link between our two support tools, and also serves for interaction of the type “Engineer TP-Software Developer”.
The card has the necessary fields that must be filled out (product version, the name of the company-customer, etc.)
There are several tabs that contain additional information about the status of the issue and present such standard options as:
• Attaching files and comments (with versions);
• Communication history engineer -> developer (a tester or analyst can also be included in this process);
• Set the status of "error";
• Request prompt correction of this error;
• Ability to link multiple cards.
Previously, prior to the introduction of external interaction tools, all correspondence with customers was transferred from mail to DVManagement. Now it is all saved and used as a great knowledge base. With the advent of external services, the process was slightly modified: additional fields and options were added to the issue card. Each time the issue status changes, as well as any fields change, the author of this issue receives email notifications of the changes made. In other words, nothing will go unnoticed.
Currently, the system already has about 7000 created issue, used by technical support staff, and all in all about 60,000 objects created during the period from 2006 to 2014. I do not claim that “the more the better”, but the knowledge base is updated daily. This is very helpful, for example, when training new support staff.
External tools (Full Zen)
Along with DVManagement, we needed a tool that would allow us to more conveniently record incoming requests - and Zendesk was chosen, and we started working in 2011.
Zendesk is delivered as a service (SaaS), in the form of a site that is accessible to both us and our customers. This is a high-availability system (hosted on Amazon), aimed specifically at handling calls, requests, or “tickets,” as the questions within Zendesk are called.
DoxVision has its own technical support portal, which is available for review even without registration. And registered users can write to us on the forum, and, with a paid update package, create applications during this entire period (for example, during the year).
Some key points:
• To work, you need to create accounts for support engineers called “agents”. There are about three dozen such agents in DoxVision.
• There is an extensive system of forums in which customers can ask questions and receive answers from support engineers, as well as communicate with each other - a typical example of a development forum (registration is required). In total, we have more than a dozen such sections.
• Enhanced event notification system.
• Support for customizable SLA.
• Access control system (there are different categories of user accounts - agent, end user, forum administrator, global administrator).
• Convenient linking of end users to their companies.
• If desired, several users from the same company can participate in correspondence in parallel.
• Extended application status (except “open”, “closed”, “resolved”), awaiting certain events from outside.
• A system of macros and triggers (example: distribution of an application for a more “free engineer”).
• Advanced reports on many events.
• Mobile applications for all platforms (now we can respond to requests from anywhere).
• Integration with social networks.
sample mobile application for windows phone 8
Below is a screenshot of the support agent interface:
Users registered on the portal can create applications that will be automatically taken to work. The entry point in this case is the support portal itself (available at the address) and e-mail: the letter sent to a special address is immediately converted into an application - this is another feature of Zendesk.
When creating an application in the helpdesk, the user must fill in certain fields, describe the essence of the problem, and, if desired, attach additional information (this could be a screenshot or some kind of log), this is how it looks
Application Interface
Zendesk allows you to have absolutely customizable fields in the created ticket: it can be a drop-down list, a radio button, or, for example, a choice from the list of values set by the administrator.
All applications created in this system are processed within the specified SLA and depending on the purchased package of services. By the way, the user can select the level of criticality by himself.
If we talk about the dynamics of the number of requests, then it can be seen in the pictures below (recall, 2011 is the year of introduction of Zendesk). For example, taken in 2013, which is still in the lead in the number of applications.
It is more interesting to observe the number of solved applications by months. On the graph above you can see how many were created per month, and what part of them was solved in the same month.
Also, for each engineer, statistics are kept, allowing you to collect KPIs within a week. It is worth noting that the number does not always indicate whether the engineer worked well or poorly during the week, because, as a rule, more complex issues are solved for a longer time.
Features Helpdesk in the context of EDS
Zendesk helps us build a channel of communication with customers and customers at a new level. The application created by the user will be processed taking into account the existing SLA ( Service Level Agreement - defines the mutual responsibility of the IT service provider and users of this service). And, as soon as we are talking about responsibility, I will mention the NDA ( Non-Disclosure Agreement ): we are committed to customers who are concerned about the confidentiality of the data transmitted to us, not to transfer them to third parties. Also in Docsvision there are tools that allow you to “de-personalize” user data transmitted to us in the course of work: a TP engineer will not be able to see personal data of users or read confidential information in client’s directories.
Although, according to the regulations, the TP service has an 8-hour working day, the work of engineers is structured in such a way that the watches of all engineers are distributed and cover the maximum possible time: for example, from 8:00 to 20:00. This is because technical assistance may be needed by customers in a different time zone.
Depending on the time of day, the activity also changes:
As you can see, the peak falls in the middle of the working day. Work is in full swing.
Due to the large number of Docsvision versions working for our customers at the same time, engineers should have at hand all possible Docsvision versions and combinations of installed modules. For such cases we use about 40 virtual machines. We use the hypervisor on VmWare technology.
But often even a large “zoo” of all versions of Windows, all Net Frameworks and barcode scanners (which we also use) may not be enough at some point.
For example, it may happen that an unexpected behavior will be found that is consistently reproduced only on physical machines (and not on virtual machines) or on touchscreen devices (monoblocks).
Flexibility hot fixes
In case of finding critical errors in the system, in some cases our partners (and users) do not have the opportunity to wait for the release of a new version of the product or update the entire system - it is often time consuming, and not everyone is ready to wait.
Many errors, the elimination of which does not require much complexity, we solve with the help of operational fixes. If we are talking about a server, then it is enough to change one or two libraries, and the patch will be installed. Client jobs are still easier. Corrections can be obtained as on request, and placed in the public domain in the form of cumulative patches.
Emergency technical support
To minimize the downtime of critical systems (the workflow at the enterprise is not an exception), there is an emergency support service in DoxVision. We begin to interact with the customer as part of a faster SLA - the response time in such cases does not exceed 1 hour, and for the most part the engineers work online. In this case, we use all possible ways to communicate with the customer (Skype, Lync, remote connections) to quickly solve problems. If necessary, work will be carried out during off-hours. Thus, the time to localize the problem and release (if necessary) corrections is significantly reduced.
Technical Account Manager
Under this name is a dedicated specialist from the technical support service. In this case, the controllability of the interaction process between the customer and technical support is enhanced. The engineer is the coordinator of the application (s) from one customer, he monitors the incoming applications and, if necessary, takes measures to more effectively address. There is a so-called. “Single window” in which you can ask both standard and related questions. The engineer in this case is represented as a “universal soldier” and takes on both technical and organizational issues (to arrange a conference call, provide a report on the weekly work done, etc.)
Future plans
In the near future, the very scheme of the process of technical support, most likely, will not undergo any changes, but we always strive to do everything a little better by arranging work within the company and within the department.
After each executed ticket, the user who created it is offered to evaluate the work of the engineer by clicking "I like" or "I do not like". The rating thus formed is kept at around 96% -99% - it is available to everyone on a separate page (the data is dynamically changing).
According to internal regulations, every quarter we survey users (using Polldaddy ) and ask to evaluate the work on such items as response speed, politeness, completeness of information, first reaction time, etc. By collecting these data, we get a response, on the basis of which certain conclusions are drawn. One of the interesting requirements is the ability to communicate in real time with agents (Chat or Skype right inside Zendesk), the ability to escalate the problem to a higher level, the ability to integrate with other helpdesk systems or generate reports (from customers).
But, besides technological tools, helpdesk employees can be influenced in a different way: I think that a kind of Dashboard would be an excellent visual tool, allowing engineers (and managers) to track last minute applications in real time, for example, on a TV screen in the form of visual graphs.
Future plans also include holding daily meetings (similar to SCRUM) in which current work can be discussed, by the way, our colleagues from QA and Development have such meetings for a long time.
The helpdesk model, built in our company, is convenient for clients and, by the way, finds a response from our partners, because each of them at a certain stage is faced with the issue of organizing internal support. Several partner companies have already implemented such helpdesk with the help of our experience and knowledge.
If you are ready to share your experience, please in the comments - we will discuss.
Source: https://habr.com/ru/post/237937/
All Articles