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 DoksVision, taking into account the specifics of platform software. Perhaps this information will help companies that already work closely in Helpdesk, as well as those who are just planning to build a channel for communication with customers. By the way, a number of Docsvision partners have already taken advantage of our experience and implemented Helpdesk with our help.



    All companies whose business is based on the provision of various IT services strive to be customer-oriented, and DoksVision is no exception. Like many other vendors, we not only produce software ourselves, but also provide services for its technical support, we strive to provide them with high quality and on time.

    Many times I have come across the fact that companies provide different types of user support services from a technical point of view. On Habré there are several articles on this subject, and here is one more from which you will learn how this happens with us.

    Start


    The software development process (and large software in particular) can take place according to various schemes, but in the end it comes down to a few 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, the points can be supplemented, combined or removed, by touching only a few aspects, you can start a small holivar :)
    But my goal today is different.

    Simultaneous support of several versions


    The software needs to be invented, developed, tested, released into the big voyage (as we say “ship”) and start its support. Since the history of the company and Docsvision EDS began a long time ago, for 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 version of the platform has at least 2 release versions with the full name, for example, Docsvision 5.3.2529, i.e. it turns out about 10 versions at a time. About 40 more modules of the platform should be added to this . We support all this variety of products and release versions of Docsvision in work in parallel and every day.
    Some of our customers have been cooperating with us from earlier 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 for a day plays a significant role.

    early years


    From the first versions of Docsvision to this day, we have provided technical support ourselves, and the usual entry point was regular mail. Users in emails reported difficulties, attaching screenshots and logs. During the correspondence, urgent issues were resolved, a knowledge base was accumulated, and gradually with the expansion of our company and the growth in the number of customers, the number of requests from them also increased. To process them, you needed a solution (or a set of solutions) that would help to structure all the data received.
    At the source of the helpdesk process in the company to this day is a mighty “stone”, whose name is DVManagement. And now is the time to smoothly switch to what we use inside the company.

    Internal tools

    DVManagement is a server with the Docsvision platform installed, located in the bowels of our company, with which technical support engineers (and not only them) work from their workplaces. Now the latest release version of our platform is installed on the server and special “cards” are added, which we call issue. DVManagement is, in fact, our platform with the added functionality of a bug tracker and helpdesk for processing internal and external calls, which include:
    • Recording new requirements for implementing the functionality;
    • Recording errors;
    • Record of corrections (knowledge base);
    • Test cases (in small quantities);
    • To-do plans (in small numbers).

    Since the “platform” is large enough, not all departments in the company use only “our” bugtracker, part of the work is done in the Team Foundation Server repository (and earlier SourceSafe).

    TP employees work daily with Issue cards, which look something like this:



    Issue is the link between our two support tools, and also serves as an interaction between the TP-Software Engineer Engineer.

    The card has the necessary fields that must be filled (product version, name of the customer company, etc.)
    There are several tabs that contain additional information about the status of the solution to the issue and there are standard options such as:

    • Attaching files and comments (with versions);
    • Communication history engineer -> developer (a tester or analyst may also be included in this process);
    • Setting the status of "error";
    • Request for prompt correction of this error;
    • Ability to link multiple cards.

    Previously, before the introduction of external interaction tools, all correspondence with clients was transferred from mail to DVManagement. Now all this is saved and used as a large knowledge base. With the advent of external services, the process changed a bit: additional fields and options were added to the issue card. Each time the status of the issue changes, and also when any fields change, the author of this issue receives mail 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 in total there are about 60,000 objects created in the system from 2006 to 2014. I do not claim that “the more the better”, but the knowledge base is updated daily. This helps a lot, for example, when training new support staff.

    External Instruments (Full Zen)


    Along with DVManagement, we needed a tool to more conveniently capture incoming applications - and Zendesk was chosen, which we started working in 2011.



    Zendesk is delivered as a service (SaaS), in the form of a website available to both us and our customers. This is a highly accessible system (hosted on Amazon), aimed specifically at working with calls, applications or tickets, as questions are called inside Zendesk.
    DoksVision 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 service pack, create applications throughout this period (for example, within a year).

    Some key points:
    • To work, you need to create accounts for support engineers called "agents." In total, DoxVision has about three dozen such agents.
    • 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 email notification system.
    • Support for custom SLA.
    • Access control system (there are different categories of accounts - agent, end user, forum administrator, global administrator).
    • Convenient binding of end users to their companies.
    • If desired, several users from the same company can participate in correspondence in parallel.
    • Extended application statuses (except for “open”, “closed”, “resolved”) awaiting certain events from the 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.


    Example 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 into work. The entry point in this case is the support portal itself (available at the address) and email: the letter sent to a special address is immediately converted into a request - this is another feature of Zendesk.

    When creating an application in helpdesk, the user must fill out certain fields, describe the essence of the problem, and if desired, attach additional information (this may be a screenshot or some kind of log), here's what it looks like
    Application interface


    Zendesk allows you to have absolutely custom fields in the created ticket: it can be a drop-down list, a radio button, or, for example, a choice from a list of values ​​predefined by the administrator.
    All applications created in this system are processed within the specified SLA and depending on the purchased service package. By the way, the user has the ability to choose the level of criticality 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 Zendesk implementation). For example, the year 2013 is taken, which so far is “leading” in the number of applications.





    It is more interesting to observe the number of resolved applications by month. In the graph above, you can see how much was created per month, and what part of them was solved in the same month.

    Also, statistics are kept for each engineer, allowing you to collect KPI within a week. It is worth noting that the quantity does not always indicate whether the engineer worked well or poorly during the week, because, as a rule, more complex issues are resolved for a longer time.

    Features Helpdesk in the context of EDMS


    Zendesk helps us build a channel of communication with customers and customers to a new level. An application created by the user will be processed taking into account the existing SLA ( Service Level Agreement - defines the mutual responsibilities of the IT service provider and users of this service). And since we started talking about responsibility, I’ll also mention the NDA ( Non-Disclosure Agreement ): before customers who care about the confidentiality of the data transmitted to us, we commit ourselves not to transfer them to third parties. Also in Docsvision there are tools that allow you to “anonymize” user data transferred to us during the work: the TP engineer will not be able to see the personal data of users or read confidential information in client directories.

    Although according to the regulations, the TP service has an 8-hour working day, the work of engineers is structured so that the hours of all engineers are distributed and cover the maximum possible time: for example, from 8:00 to 20:00. This is because technical support assistance may be needed by customers in a different time zone.

    Depending on the time of day, 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 simultaneously working for our customers, engineers must have "at hand" all possible versions of Docsvision 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 Framework and barcode scanners (we use this too) at some point may not be enough.

    For example, it may happen that unexpected behavior is found that is stably reproduced only on physical machines (but not on virtual machines) or on devices with a touchscreen (monoblocks).

    Hotfix flexibility

    If critical errors are found in the operation of 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 to update the entire system - this is often laborious, and not everyone is ready to wait.
    Many errors, the elimination of which does not require much laboriousness, we solve with the help of operational fixes. If we are talking about a server, then just change one or two libraries, and the patch will be installed. With client jobs, it's still easier. Corrections can be obtained both on request and posted in the public domain in the form of cumulative patches.

    Emergency Technical Support

    To minimize the downtime of critical systems (document management at the enterprise is no exception), DoxVision has an emergency support service. We begin interaction with the customer as part of a faster SLA - the reaction time in such cases does not exceed 1 hour, and for the most part, engineers work online. In this case, we use all possible methods of communication with the customer (Skype, Lync, remote connections) to quickly solve problems. If necessary, the work will be carried out after hours. Thus, the time to localize the problem and release (if necessary) the fix is ​​significantly reduced.

    Technical Account Manager

    Under this name, a dedicated specialist from the technical support service works. In this case, the controllability of the interaction process between the customer and technical support is increased. The engineer is the coordinator of the application (s) from one customer, he monitors incoming applications and, if necessary, takes measures for a more effective solution. The so-called “Single window”, in which you can ask both standard and related questions. The engineer in this case appears in the form of a “universal soldier” and takes care of both technical and organizational issues (organize a conference call, provide a report on the weekly work done, etc.)

    Future plans

    In the near future, the technical support process scheme itself, most likely, will not undergo any changes, but we always strive to do everything a little better by properly arranging work within the company and inside the department.

    After each completed ticket, the user who created it is invited to evaluate the work of the engineer by clicking “I like” or “I don't like”. The rating thus formed is kept in the region of 96% -99% - it is available to everyone on a separate page (data is dynamically changing).

    According to internal regulations, every quarter we poll users (using Polldaddy) and ask you to evaluate the work on such points as the speed of response, politeness, completeness of information, time of the first reaction, etc. Collecting this data, we get a response based on which certain conclusions are drawn. One of the interesting requirements is the ability to communicate in real time with agents (Chat or Skype directly inside Zendesk), the ability to escalate the problem to a higher level, the ability to integrate with other helpdesk systems or build reports (on the part of customers).

    But, in addition to technological tools, the work of helpdesk employees can be influenced in another way: I think that some kind of Dashboard would be an excellent visual tool, allowing engineers (and managers) to track “burning” applications in real time, for example, on a TV screen in the form of visual graphs.

    There are also plans for the future - to hold daily meetings (similar to SCRUM), in which you can discuss the current work, by the way, our colleagues from the QA and Development departments have been holding such meetings for a long time.

    The helpdesk model built in our company is convenient for customers and, by the way, resonates with our partners, because each of them at a certain stage is faced with the organization of internal support. Several partner companies have already implemented similar helpdesk with the help of our experience and knowledge.

    If you are ready to share your experience, please comment - we will discuss it.

    Also popular now: