Brief description of the course
Companies of any size and level of development are constantly faced with the fact that users cannot continue their work due to failures of the IT infrastructure. User requests are often misclassified or even lost altogether. The user has to remember in what specific situation and to whom he should contact. The IT service does not always fulfill user requests quickly, in a timely manner, and with the required level of quality. All these problems complicate the life of any IT manager, and often it is by the presence or absence of such situations that the work of the IT service as a whole is assessed.
To resolve these issues, it is necessary to create an effective user support service and correctly describe all the necessary technical and organizational documentation.
During the course, students will study in detail the incident and problem management processes, gain an understanding of related processes: event management, requests and access, on the basis of which a user support service is created - the company's single point of contact, and will become familiar with methods of training and managing personnel.
A distinctive feature of the course is the creation of a package of necessary documentation that will describe the activities of the service and thereby significantly reduce the costs of consulting services.
Learning Objectives
- obtaining unique practical experience in creating a set of documentation, including process regulations necessary to describe user support activities;
- in-depth study of the main user support processes - incident management and problem management in order to create a Single Point of Contact (SPOC);
- studying the principles of building and organizing the work of the Service Desk: organization, functions performed, methods of competent personnel selection;
- familiarity with methods and approaches for planning and setting up processes in order to ensure their effectiveness, rationality and consistency, resulting in an increase in the quality of services provided by the IT department;
- a brief introduction to related processes: event management, request management, access management.
- managers and employees tasked with planning and implementing a technical support service;
- employees and managers of user support services, such as Service Desk, Help Desk, Hot Line, Call Center;
- employees involved in technical support for users;
- heads of departments that are consumers of IT services.
As a result of the training, students
- will gain unique practical experience in creating a set of documentation to describe the user support process using the example of incident management;
- will acquire the necessary knowledge to build a technical support service;
- develop an understanding of the principles of IT infrastructure management in order to provide user support;
- will receive practical skills in building a user support service Service Desk;
- will receive the necessary knowledge on planning, setting up and implementing the process;
- will acquire the necessary knowledge to manage the Problem Management process;
- will become familiar with processes such as: event management, request management, access control.
Required level of knowledge
- It is recommended to take the course “ITIL ® Foundation v3. Basic course";
- Experience working in an IT department is desirable, in particular, in one of the processes covered in the training or in a technical support service.
Materials provided
Students are provided with materials developed by the Megapolis Profi company based on original ITIL books, provided for in the course program. Upon completion of the course, students are issued a certificate.
Duration and conditions of training
Course duration is 16 academic hours (2 days). The course price includes lunch and two coffee breaks during each day of training.
Coaches
The courses are taught by EXIN and APMG certified teachers. Teachers have extensive practical experience in implementing ITIL ® processes in companies of various sizes.
Course program “Organizing a user support service: creating documentation and service structure.”
Part 1. Theory
. Introductory part of the course
o Course objectives
o Lesson plan and assignment of working groups
. Standards and methodologies used to create a single point of contact
o ISO 9001 and ISO 20000
o ITIL® and MOF
. Selection of process description methods
o Variety of possible options for describing processes
o Most commonly used methods and tools
. Considering interconnected processes in support
o Roles and tasks of event, request and access management processes
o Inputs-outputs and interaction with other processes
. Incident management - as the basis for building a single point of contact
o Basic principles and concepts of incident management.
o Portfolio of services
o Service Desk is the most important function for working with users
o User support process diagram
o Main activities
o Possible implementation problems
o Roles and responsibilities in the process
o Process optimization
. Problem management
o Purpose and objectives of problem management
o Basic definitions
o Process diagram - reactive and proactive approach
o Difficulties in implementation
o Benefits from organizing the process
Part 2. Workshop
. Case study
o Company research
o Identification of problem areas
o Drawing up a diagram of the interaction of processes and activities within
. Compiling a list of required documents
o Process Policy
o Process regulations
o Work instructions
o et al.
. Documentation development
o Structure of each document
o Basic elements within each document
o Creation of ready-made documents according to the conditions of the case
. The final part of the course
*ITIL ® is a Registered Trade Mark of AXELOS Limited.
People exchange sharp words
- said Loki, - but these words weigh nothing.
A person has a lot of them in his mouth.
"Empire V", V. Pelevin.
The first line of defense on the business battlefield is technical support service. The support is the first to meet adverts, the first to absorb the flow of indignation when failures occur, weeds out people who are not good for the business and, solving 90% of the problems of partners and clients, brings to the management only a concentrate of the most important things that require their direct participation.
Who works in support services? What should support be like? How to be a good “supporter”? You will learn about this in this article.
The first half of the article is intended for those who want to organize a support service for their Internet business. The second is for those who want to find a job in support.
This article will not create your technical support service for you. And it won’t provide you with work in support. But there is more than enough food for thought in it.
So make yourself comfortable and let’s get started.
How to select technical support employees
It doesn’t matter what kind of project you are managing, be it a design studio or - your users (advertisers, clients) will most often communicate with the support service and, most likely, only with it. It is the support that determines what first impression your project will make and how it will be treated in the future. Therefore, this part of your business should be no weaker than all the others.
Many project managers don't bother creating a help desk and don't want to hire a dedicated person to do the job. Perhaps they are right. If the project does not involve a large number of participants and is well automated, then it probably does not need a separate support service.
But this happens extremely rarely and, more often than not, the owner himself has to perform the functions of support. Do you have enough time and patience to do this job? Will this approach pay off in the future?
Most likely, attentive attitude towards partners, prompt resolution of their problems, competent communication with experienced advertisers, advice to beginners and time savings for the project manager will more than pay for the supporter’s modest rate. Do not underestimate the face of your project, even if these are just words in the ICQ client window.
- Do not hire so-called “schoolchildren” for technical support(young men and women with unformed psyches, communication skills and a sense of responsibility. There are still others. It’s better not to deal with these at all.).
Poorly paid “school kids” in the support service are the most common mistake. The person on the team must have sufficient qualifications, because nothing spoils the impression of a company more than illiterate technical support. Or inadequate. The support has access to confidential information and constantly communicates with your partners and clients, on whom the fate of the project depends. Therefore, by skimping on professionalism, you risk not only your reputation, but also the fate of the entire project. - Adequate person.
Pleasant to communicate with, sympathetic, with competent language, clearly expressing his thoughts - these are the necessary characteristics for a good user support worker. - The technical support employee must be an experienced professional.
Being able to speak politely, smile and check boxes in the admin panel is not all that is needed from a support employee. He must be a professional who is familiar with the entire business of the company and is familiar with at least the basics of all the nuances of the industry. If you have an affiliate program, then the support employee must be an experienced webmaster. If you sell a software product, the support service must be technically competent. - Do not hire unknown people for technical support.
The support team has access to confidential information, sometimes even to accounts in . Therefore, check how well-known your candidate for the position of “supporter” is in the community. Does he communicate in and what reviews does he have? Recommendations from famous people will also not be superfluous. - A bad reputation of a technical support employee is the key to the failure of the entire company..
If you find an excellent professional in technical support, but he has somehow tarnished his reputation in the past, then it is better not to cooperate with him. Such a support service can discredit the entire project, even if its owners are famous and respected people. - A customer service representative must be available.
If the support desk is staffed by one person, he or she must be able to be available at least 12 hours a day. Or better yet, 14-18 hours (with a not too heavy load). If the workload is heavy, it is necessary to organize shift shifts. But the main thing is that the support service should be available most of the day. Users should not “catch” it. Well, for example, for technical support 24/7 (24 hours 7 days a week) has long been an accepted standard. - Some self-employment is no problem.
Don't stop your tech support employee from working a little for himself. If he V free time develops a couple or writes, then this will not interfere with working in the support service. But it will keep him in good professional shape and help him financially. - Don't impersonate support staff.
As surveys have shown, it is more convenient to communicate with a support employee if he has a normal name (nickname). That is, the ICQ nickname “John Smith” is much better than Support Unit 1.” - An interview never hurts.
Talk carefully with the candidate for the technical support position. Give test task. For example, if he needs to support advertisers, you can show him any sales page and ask him to give some recommendations on improving productivity and increasing sales. Based on his reaction and results, you will immediately understand the level of his knowledge.
Now let's talk about what qualities are needed in order to get a job as a user technical support employee.
What do you need to work in technical support?
With a stable salary, work in a strong team with famous people- these are the bonuses of working in the support service. True, a lot will also be required from you: attentiveness, pedantry, good knowledge professional field, patience and much more. I present the main points below:
- Professionalism.
The idea that any beginner can handle the responsibilities of a support worker is a deep misconception. You must be confident that you can answer almost any question in the required area. And if not, then why are you here? It is impossible to know everything, but you must be fluent in the issues of our industry and have practical skills. This is why technical support is needed to help in word and deed with the problems that arise for people working with your project. And this requires knowledge and experience. - 12 hours a day - minimum.
Customer support should be available most of the day. She is truly valuable when you can turn to her for help at any convenient time. Therefore, you must be able to be online for at least 12 hours. Or better yet, 16. Of course, sitting still all the time is unrealistic, so figure out a way to do other things and be online at the same time. You can carry a smartphone with you. You can simply turn up the volume when doing household chores, and run to your workplace when you hear the familiar “knock-knock”. Be prepared to get up in the middle of the night too. Who has it easy now? - 90% of problems are your task.
Technical support should and can solve 90% of the problems that arise for advertisers. This is so because 90% of calls to the support service are related to simple problems that are resolved immediately on the spot. Be prepared for the fact that you will not only chat on ICQ, but also actually help people in a variety of situations, difficult and not so difficult. Transfer an unresolved issue to other authorities (administrator, management) only when you are sure that there is no way to solve this problem on your own. - Never be rude.
You will be rude, rude and even insulted. A wide variety of people live here, and not all of them are distinguished by intelligence. No matter in what tone or content the question is asked, you must always remain extremely polite. You were sent - answer: “Thank you for paying attention to me.” - Never ignore.
Never, never ignore messages! The support worker is required to respond to all requests, be it ICQ, e-mail, tickets or telephone. It doesn’t matter whether the problem in this message seems important to you or not, because for an advert, any problem he has is extremely important. It definitely needs to be resolved and, if possible, quickly. Moreover, more often than not, the lower the price of the issue, the greater the likelihood of a scandal. So, for example, when payments are delayed, partners who have barely made the minimum wage worry many times more than large advertisers. For newbies, their first $50 makes a huge difference. Don't let them start a fight somewhere on the forum. - Be careful and flexible.
Technical support is the face of the company. Therefore, communication with her should leave a pleasant impression. Be polite, attentive and always try to adapt to the person who contacts you. If they address you as “you”, say “you”, if they “poke”, carry on the conversation in a friendly manner. - Take the initiative.
It's good when people feel your presence. If the issue has been resolved, knock and let us know. If the problem cannot be resolved yet, say that there is a delay, but they are working hard on a solution. But don’t overdo it, don’t knock on everyone and tell them “about the weather.” Nobody likes a bore. - Customer service worker shown public life
Chat on forums. An additional signature will have a positive impact on the development of the project and the mood of the employer, just like your virtual presence next to the people with whom you work. - Continuous learning.
The support team must always be aware of all changes in the industry. Otherwise, very soon your knowledge will lose relevance and you will not be able to do your job efficiently. Has there been any new script? Read about him, look at his work, etc. Has a new competitor emerged? Browse its websites, analyze its advantages, identify its disadvantages, etc. - Keep your mouth shut.
Technical support is trusted with confidential information. So don't talk too much! Even in secret to friends. Turnover, number of advertisers, hidden statistics parameters - anything can play into the hands of competitors, and ruin your business reputation forever. Professionalism also means correct behavior. - Don't allow negativity on forums.
The absence of negative reviews on the forums is a good job of technical support. Never bring it to public proceedings, even if you are 200% right in the dispute. As one of the classics of marketing said, “no one has ever won an argument with a client.” I would add that in a dispute with an advocate, too. - Instructions are not everything.
There is no such thing as perfect advice or instructions. And these are no exception either. Always be adequate and soberly assess the current situation. Remember that the technical support service works with real people. Try to understand them and put yourself in their position. - You are a team member.
Never forget that you work in a team and must protect its interests. There is no need to publicly complain about your management and admire your competitors, even if they are objectively better. The opinion of a technical support employee is always visible. And they listen to him. - Work on two fronts.
The two fronts are the project participants (advertisers, clients) and its organizers (owners). The support service should not only help advertisers resolve their issues, but also, among other things, defend them before the project management: for example, reduce the minimum payment, if asked, raise the percentage, seek the allocation of additional promotional packages, etc. Remember, your task is to make the work of your partners as convenient as possible.
At the same time, the support person is an important team member who works to indirectly increase the overall profitability of the project. This means that we need to ensure an increase in turnover and try to reduce costs. Learn to maintain a balance - do not indulge too greedy and capricious advertisers, so that the project does not go into the red because of this. But don’t forget to provide comfortable working conditions for sane partners.
Contrary to what many people think, working in a support service is not empty chatter on ICQ for those who don’t know anything else. The community’s opinion of the project depends on the quality of this service’s work, which ultimately affects whether advertisers will remain and continue to work with it. The number of clients and much more also greatly depends on technical support. Good customer support will not solve all the problems that arise along the thorny path of business. But it can reduce their number many times!
A high-quality technical support service consists of high-class specialists who are subject to serious demands. Their work is responsible and not at all easy. The demand for this specialty is not falling, and salaries are only growing. Become good professionals in your field, and many famous teams will be glad to see you among their ranks.
I write the text in real time, i.e. behind this word, I don’t even know what the next word will be. :)
In this case, you need to start with the foundation and with an understanding of the problem... and also identify the target audience: these are internal IT services and organizations providing professional services in the IT field... giants like Megafon or Iota most likely need solutions of full-fledged contact centers, which goes beyond the boundaries of my picture of the world and therefore is absent from this article...
C1.1. Problems and deviations in typical situations
- There is no understanding between the IT service and the organization's management. Which leads to conflicts, which are then expressed in the form of jokes ala “I am Dartagnan, and the management is...”. Although in most situations the reality is the opposite.
- Users are shocked
- forced to spend their time making sure everything works for them
- It’s not uncommon to receive rudeness instead of help
- There is no trust in the IT service, because the same basic questions need to be repeated and reminded, because... they are forgotten or forgotten;
- you can completely forget about wishes for development... only what IT specialists want is done, and not what users or the organization need;
- The service is a mess
- Few or virtually none of the specialists understand what is the result of their work;
- The concept of leading specialists and managers is confused, or rather, leading specialists are appointed managers
- The workload of specialists is a big question, and its fairness even more so.
- People's energy is scattered in different directions, as a result there is fatigue, but no noticeable results.
- High organizational costs
- The same process failures are repeated many times, but few people care
- Downtime in processes also occurs, but this is also quickly forgotten and repeated with enviable regularity.
- And last but most important... Without process management, specialists think that IT is somehow tied to computers, and instead of developing IT, they deal with computer technology.
C1.2. Desired situation
- The customer is always right. The organization, the organization's management and its employees are clients of the IT service.
- The key to the client's heart is facts and figures that show dynamics and allow you to make forecasts to make decisions.
- All people, white and black, make decisions the same way (with the exception of clinical deviations in the development of the mind and being locked in a madhouse). The only difference is in the initial information. The ability to select the right information is the basis of success and understanding.
- Gathering the necessary information is one of the results of properly organizing support.
- Need to gain user trust
- They must be sure that having communicated their thought once, it will be written down, considered, and there will be an answer or decision. And not ignoring or “I forgot.”
- The first phrase of a person who has achieved Buddhahood: I am you. If you see a stupid person in front of you... think about it. This is not a joke.
- It all starts with recording requests, but then the lists (databases, registries, directories) expand with the development of the entire system.
- Order is a delicate matter
- The result of the IT service is the availability of the necessary information to employees and the absence of downtime in their activities. But these are just words. This is difficult to understand and understanding only comes after using an IT management system for some time.
- Justice is a complicated thing. There is a separate article for its understanding and it
- Who's at the helm of IT? Manager or specialist? There is a very simple test: do you register user requests? If yes, then there is either a leader or a promising person at the helm, if not, this leader needs to be kicked out, or demoted to a specialist, even a leading one.
- Any action must have priority... and those actions that have the greatest impact in terms of the organization's goals must be performed first. Achieving this is not easy, but it is possible.
- We cut costs
- We minimize downtime at any cost, bloody nose, because... any downtime is not just “we’ll fix it now,” it’s consequences that can’t always be tracked, a decrease in reputation, loss of customers, etc.
- Failures need to be recorded, the causes traced, the causes eliminated - repeated failure is a disgrace to the jungle.
- Well, having completed these 4 points, you come to the understanding that IT is IT, and they are already hundreds of thousands of years old... and computers are computers, they are only about 50 years old and now they are used more often than the walls of caves only because a little - a little more efficient and nothing more :)
C2. Peculiarities
- The key factor to success is the registration of all user requests. Key word in this sentence: everyone. If you start slacking and skipping requests, get out, you are not a leader.
- When you achieve registration of all requests, the system will begin to develop... bottlenecks immediately become noticeable:
- no process instructions or instructions are crooked - a lot of questions
- no employee training - many questions
- equipment or programs are poorly configured or poorly selected - many failures
- specialists do just about anything, but not what is needed for the organization, and therefore for management.
- if you do a project poorly, then the dynamics of circulation jumps... projects need to be planned better...
- Well, in general, the picture becomes clear and many ideas immediately appear in my head on how to improve the situation...
- A very important element of the system is the CMDB or CBD - configuration database or service objects:
- All objects that fall under the sphere of influence of IT are indicated here in order to track the actions that are performed on them.
- Frequency of failures by program... what causes failures more often in 1C BP 8 or 1C BP 7.7? As a consequence, which one causes more costs?
- What changes and who made them in the programs? Which ones? Is it time to upgrade to a new version? Which changes are worth repeating and which are not? How much is this in terms of finance? Here the answers are in years.
- Someone is trying to shove mice and network cards here... this is a personal matter for everyone and everyone goes crazy in their own way... but my experience shows that such detailing brings a lot of expense and is of little use, and in fact it is monkey work.
- Basically, if you are responsible for IT, then it is enough to keep records in the context of programs, databases, system modules, and computers can finally be written down as Computers, even without detailing by office, not to mention detailing by components)
- And if you are also responsible for quality (this is ISO 9000), then here you can add a list of all the instructions and regulations governing and normalizing the procedures of employees. In this case, the leadership will begin to pray for you and light candles in churches for your health. This is not counting other bonuses and social packages))
C3. Solutions options
- Let's first consider the characteristics that ensure IT quality
- Basic, mandatory ones that need to be completed first
- Recording requests, reception dates, completion dates, you can also record the result
- Regular (daily, weekly, monthly) monitoring of indicators, load, performance, dynamics...
- Additional, convenient, improving, can be performed secondarily
- Recording changes, projects, service objects for additional analysis sections
- Maintaining a history of communication based on requests, automatically sending notifications by email to those who applied.
- Basic, mandatory ones that need to be completed first
- Tools
- 1C ITILium
- Pros
- The basic requirements are met here
- Software can be changed
- You can find a pirate
- There is a setting for automatic notifications about creation
- Strong reporting
- Cons
- It’s difficult to keep a correspondence history; there are no notifications about comments by email or the ability to respond by letter
- Web muzzle is heavy
- Recommendations
- For cash-strapped pirates
- For those whose policy is tied to 1C
- For those who like to tinker with programs and love 1C
- The price is about 50 thousand rubles. for software, services are added according to taste.
- Notes
- I like it because this was my first system on which I built IT management
- Pros
- eStreamDesk is one of the most effective solutions
- Pros
- web-oriented and SaS model, i.e. access from anywhere and no need to worry about it with proper installation and technical support
- integrated with Google Apps
- there is Russian language
- there is a constructor for auto-messages both when adding and closing requests, and about correspondence during decisions;
- it’s realistic to use even the free option
- Cons
- crooked code, glitches and plush interface
- missing CMDB
- weak reporting
- Recommendations
- for small projects, where there are financial problems
- and if there is no legal relationship, because applicants cannot specify their organization
- Price from 0 to see website. Services here, if needed, are at a minimum because... basic functionality.
- Notes
- If they could polish up the code, make the reporting more flexible and be able to maintain a user base across organizations - that would be cool.
- Pros
- Mojo HD
- Pros
- the same as point 2, but a more pleasant, streamlined interface and Russification is a little more complicated
- reporting is good
- flexible designer of notifications about changes, comments...
- ability to respond to email
- maintaining a user database by organization
- Cons
- There is no Russian language, but the entire interface can be rewritten even in crude language
- the prices are relatively steep, it’s not realistic to use the free option
- Recommendations
- for sustainable projects, with stable finances
- for those who need to manage clientele by organization
- Notes
- prices are a little lower and can be considered an ideal system for internal services and professional business
- Pros
- DIRECTUM
- Pros
- There is a dedicated IT.Now module but with an underarm design. Violation of principle C1.1. clause 5. Something like 1C ITILium, but less flexible and worse.
- Cons
- Same as 1C ITILium
- There is no dedicated and well-thought-out module for ISO 20000. 1C ITILIUM covers the possibilities in years.
- Recommendations
- You can write your own module... which is justified in difficult situations... for example, in government administration and government services, where practice has not yet been developed, but integration with large paper document flow is needed.
- Notes
- DIRECTUM good system EDI, and building ITSM on its basis is justified only if everything else is built on this system. as has already been said, for example, in government administration.
- Pros
- 1C ITIL something from Rarus
- Pros
- this is 1C
- Cons
- the program itself was written by those who are completely subservient to the stereotype from C1.1. clause 5. is focused on accounting for mice and microcircuits, instead of monitoring characteristics by process.
- Recommendations
- For those who do not have the strength to break their stereotypes and, instead of IT, want to continue working with computers and programs.
- Notes
- Rarus themselves need to straighten out their technical support. then offer solutions to others.
- subjectively, I almost vomited while studying this program.
- Pros
- HP, IBM and others like them
- large and complex, most likely aimed at large volumes of requests.
- may be of interest to such monsters as Megafon or Beeline, where there are crowds of users.
- I heard that Gazprom people are buying such solutions. Probably the kickbacks there are delicious.
- Naumen ServiceDesk box
- I haven’t seen it, but I feel it’s interesting.
- Naumen ServiceDesk SaS
- They promise to release it soon.
- Considering Naumen’s experience, the solution should be interesting.
- If they choose pricing policy like Megaplan, I’ll probably even try to love them.
- I really hope that this will turn out to be an analogue of Mojo HD (item 3), but with a pricing policy like Megaplan.
- 1C ITILium
C4. Resume
- Whoever owns the information owns the world. This is not a joke. Netocracy is already here.
- But to own information, you need to manage IT. And not just twist computers with a screwdriver and program solitaire games in 1C.
- You can ask questions in the comments... I’ll even try to answer them.
- Everything that is written here is an empirical reflection of subjective thoughts... whoever finds it useful is welcome, whoever thinks otherwise is your right.
C5. Request
- Who knows what other IT management tools? I'm especially interested in the SaS category and the ability to automatically send notifications to users by email...
- Well, in general, I will be grateful for additions, comments, criticism... maybe I’m wrong somewhere or my information is already outdated?
C6. Copyrights
- Our groups on Infostart (abandoned, though, because I’ve moved away from 1C a little now, I’m working on a few other projects)
- Instructions and regulations for 1C Enterprise
- 1C Enterprise implementation technology
- Promised link to project management
Video help
This video describes the following information:
— General information about the project;
— Registration procedure in the network of Orthodox sites Prihod.ru;
— Authorization in the network of Orthodox sites Prihod.ru;
— How to create your first website on the Internet;
— Filling out the site registration form;
— Basic information about website templates.
If you have already created a site, then hover over “My Sites” in the lower left corner and select “Add Site” from the drop-down menu.
To create a website you need to fill out a special form. It is in this form that data is collected for the catalog of churches and the global map of Orthodox churches, and the position of the organization in the church hierarchy is established.
You can edit the entered data in the site console in the “Registration” section.
Site registration form
When filling out the fields on the left, a hint for filling out this field appears in a black window. If you entered incorrect data, a notification about this will also be displayed in red.
Help tab. On the “Help” tab, you are offered a link to a video that explains how to fill out the fields when registering. If you are unable to view it, you can use these instructions.
Also on the “Help” tab you will be asked to select the primary language of the site.
To proceed to registration, click the “Next” button.
First step. At the first step of registration, you need to provide general information about the site.
First, select a country; this determines what domain your site will be on. Each site on Prihod.ru is given a third-level domain name. For Ukraine this is the domain church.ua, for all other countries - cerkov.ru or for Orthodox organizations pravorg.ru. In the future you will be able to.
Please note that our project only creates official websites of churches, monasteries, deaneries, dioceses and organizations attached to them. Sites created on the independent initiative of users without the blessing of the abbot are not published in the network of Orthodox sites Prihod.ru.
Site name (domain) - enter the name that your site will have. Click the "Check" button to see if this domain is available for registration.
If you do not plan to use it as your main one and you have your own domain that you will link, or are creating a test site, do not take good domains (for example, pokrov), leave them to those users who will use these names as their main ones.
Pay attention! Sites related to Ukrainian Orthodox Church , must necessarily have domain name on church.ua(for example, vashHram.church.ua).
So, you will get a domain name like domain.cerkov.ru, domain.pravorg.ru or domain.church.ua.
We do not recommend indicating the full name of the temple (Local Orthodox religious organization ‘Parish of the temple of such and such’), because The name turns out to be very long, which confuses unenlightened lay people. It’s better to indicate it like this: ‘Temple Life-Giving Trinity, Dobroye village.
Second step. On the second step
A website template is a template website that has a specific set of sections and settings. The use of templates does not in any way limit the possibilities for creating websites, but it makes it easier to start working on a project, saves time, offers well-developed information structures for websites, and contains recommendations and examples for content that can be changed and supplemented at your discretion. If you want to create everything yourself from scratch, you can choose the first template - it contains only one page.
Below each template is brief description its features. The default template is installed .
You cannot change the template while you are working on the site., but you can simply delete unnecessary pages, categories and posts or add new ones. The most drastic option is to completely delete the site and create it again.
How to customize themes, work with website content, configure side columns and menus is described in detail in the section, there select the desired section in the right column.
Third step. In the third step, you need to fill out information about the temple or organization whose website you are creating.
In general, technical support is the pain and tears of the web development market. The most tearful complaints we receive are requests to take away some project for completion.
The demand for technical support is now many times greater than the supply. In the near future it will only grow, because... many companies will cut the bones and keep their projects more or less alive, without launching work in new areas.
Many people declare technical support. Only a few can do it systematically and profitably. This text is more for studios (so they can improve their processes or tell them how to improve ours). But it will also be useful for those who are really interested in figuring out whether there is life after the release. We spent dozens of hours discussing and arguing within the studio to decide that our process should look something like this. And although we can quite flexibly customize some aspects of technical support (for example, work in the customer’s favorite task tracker), the framework that we came up with, it seems to me, is quite good.
Internal kitchen
I’ll make a reservation that I’ll talk about technical support only from a programming point of view. Design, creativity and content are also important, but organizing them is much easier (according to approximately the same scheme).We carry out our projects using the flexible Scrum methodology. This means that during the work process the client does not have to adhere to a thick and tedious technical specification, but can add/remove/change any wishes right along the way. Pros: flexibility and focus on the constant development of the project right away. Disadvantages - constantly outdated documentation.
Thundercloud: old and new projects.
A TEAM of developers works on each project. This is important because once the project is launched, at least two or three people are involved in the code and can maintain it. In practice, this is much better than if the entire development was done by one “irreplaceable” genius.
Two things also help combat indispensability: strict coding standards and regular code reviews, which we conduct on our projects.
I don’t really like temporarily connecting additional programmers who did not participate in the project to support: there is a high risk of starting a progressive poisoning of the project. This phenomenon is a manifestation of the human factor and seems to be largely due to the Russian mentality. The desire to create with large strokes, and not painstakingly complete the details.
The new developer’s reluctance to get into someone else’s code and his understanding that he is working on the project temporarily leads to crutches being stuck into the code. After appearing in the code critical mass crutches, even the team that originally developed the project begins to consider the code to be foreign and solves problems with the help of new crutches. After a while, no one wants to work on the project and everyone whines that it’s shitty code. It is possible to stop poisoning, but it is quite expensive: deep code reviews and refactorings are often required. Sometimes two or three times in a row. In general, I consider adding new people for support to be justified only in three cases:
- I need to introduce a new person to the project so that he will continue to work on it on an ongoing basis.
- For the development of beginners under the supervision of a curator.
- Very, very rarely (and at the risk of getting minuses in karma for this), but still: as a measure for educating an overly ambitious developer with the makings of a gourmet. I mean those rare people who, in response to any task, begin to rant that they are not interested in it, all technologies are crap, all other people’s code is generally crap, and even his own, which he wrote a week ago, is also outdated. He may well get himself projects for the next 2-3 months (or until he calms down or until it becomes clear that we won’t work together) for technical support only (this while his colleagues receive new, interesting projects).
During breaks between sprints (for example, when there is intensive testing and the project cannot be worked on), we can provide more technical support, if appropriate. In the morning hours, we try not to interrupt developers (unless absolutely necessary). This is because it is important for developers to work in a flow and avoid distractions and switching as much as possible. Reducing entropy. In addition, this allows the developer not to focus only on the support of the old (many do not like it, but here I am harsh: any project that is more or less successful will definitely ask for development), but also try something new (new technologies) on new projects.
So, we squeeze small and urgent tasks into these two hours a day, from 16 to 18 (well, actually, taking into account teamwork, it can be 4 or 6 hours, depending on whether the tasks are parallel). We launch large tasks that can be done in a relaxed mode in sprints (minimum 40 hours), during main hours. Working in sprints costs the client less (in terms of cost per hour) than emergency and urgent tasks that need to be done yesterday.
In most cases, the same manager who worked on the project is responsible for communication with the client on technical support. Unfortunately, this is not always rational from the point of view of using the expensive time of managers (expensive - not only in terms of costs, but in the sense of TOC: managers very often become the bottlenecks of the system, and an hour of downtime in a bottleneck is equal to an hour of downtime of the entire system).
If there is an excessive load on the manager due to technical support (we call this “rainbow tears”) and the losses incurred by transferring the project to another manager will fundamentally pay off, in this case I can change the manager. In many ways, supported projects go to the younger generation to develop their own strengths and recruit a client base. It is extremely rare that we change a manager if some kind of conflict with a client arises on a project and we need to start the relationship from scratch.
Again, in very rare cases of lack of managerial time, the programmer works directly with the client’s formulations. However, we try to minimize such communications, because... unclear wording makes programmers extremely nervous, and programmers’ answers to clients’ questions without preliminary proofreading can confuse the client outright.
What would you ideally like from us?
- Receive proactive proposals to improve the project.
- Set the task in any way, even in the craziest formulation. Understanding at a glance. Thinking through the “obvious.” Analysis of the possible consequences of implementing the requested. Warnings about possible negative consequences and suggesting more rational approaches. Sometimes - shut up with your wise analytics and do as they say, because it takes a long time to explain why.
- Set a task through any convenient channel (Skype, phone, WhatsApp, SMS). Any time of the day or night.
- Accurate estimates.
- Responsibility for what has been done.
- Efficiency.
- Well, whatever is not expensive.
Proactive proposals to improve the project
Here I must tell you what projects we receive support for. There are only three types:- Free technical support for our projects.
These are all projects at the commissioning stage and during the warranty period. This is fixed by agreement. Commissioning support (when the project manager is at a hot start and is ready to answer any question that arises from the client), as a rule, is three months. Warranty period (usually a year) - during the year we are ready to correct any hidden defects found by the client that were not discovered when the project was launched. The fundamental differences between the first and second are that during commissioning the project is in the manager’s “RAM” and many issues are resolved easier and faster. During the warranty period, we fix only obvious bugs for free. In controversial cases, we reserve the right to have the client explain to us why this is a bug. If diagnostics take time and in fact the bug turns out not to be a bug, we also reserve the right to bill for the time spent on diagnostics. Formally, this is fair, but we resort to such measures in isolated cases, because... this creates an inevitable conflict situation. - Development of projects developed by us.
Projects that have been implemented in our company often remain with us for many years. They develop and evolve. We usually add new features in sprints (from 40 hours). It is more convenient and cheaper for us to do one large block of work than 100,500 small, urgent tasks: the manager’s time is saved, there is less risk of making mistakes, significantly less control is required, and the process goes more smoothly. However, the client should not accumulate urgent and small tasks when LIT (this is bad for his health). Therefore, such tasks can also be developed, but with a premium for urgency. - Projects that we did not do.
We very rarely take on third-party projects for support. Many small projects do not correspond to the global goals and ideology of our company. Living off support IMHO is a more stable, but boring business. There is no drive or tension, or something. Therefore, we take on third-party projects extremely rarely and reluctantly. The criteria here are (listed in order of priority):
- the project must be (or could potentially become) No. 1 or No. 2 in its niche. Or we should like him.
- The project code must be literate.
- There is a sufficient amount of tasks for the project.
- the client adequately understands our principles and limitations of technical support and fundamentally agrees with them.
So, about proactivity.
For projects in the active support phase, the project manager should take a proactive position. He is motivated to receive % from projects. We systematically go through projects for which there is no work several times a year and try to wake them up. This is a good practice that bears fruit. As a rule, the account manager wakes up sleeping clients. It is not always necessary to wake up a sleeping client :)
Set the task in any way, even in the craziest formulation
This is an important point regarding responsibility. Responsibility is a double-edged sword. There are several principles here that we agree on with the client. As a rule, the client will not argue with the principles themselves (they are understandable and logical), but will try to find a loophole between the principles. The project manager, by the way, too.
In total, we reserve the right to clarify and reformulate the client’s statements into clearer ones. Clarify and add details. And even dissuade the client from certain tasks (if, in our opinion, they will make the project worse). However, the client is responsible for the final wording. The formulations that we have fixed one by one will be sent for development. And our tester will check them against them. And we will hand over the task based on them.
I want to set tasks through any convenient channel (Skype, phone, WhatsApp, SMS). Any time of the day or night
Yes, but no. An understandable desire, blind indulgence of which will create chaos, panic and confusion in the studio and make any technical support project unprofitable. To handle this, the project manager needs to do nothing, but be on alert all the time. And this is economically inexpedient and morally difficult. For all technical support projects we provide unified system storing client tasks. Taskmanager. There they are clarified, assessed and statuses are assigned. What kind of system it will be technically is not so important (operational work can be organized in Google Docs and in the Bitrix portal). The very first thing that is required for the manager and the client to get used to it is to persistently but politely teach the client how to write and respond to task manager. It is clear that in some cases the client will still write on Skype, call on the phone or write 50 letters within an hour. The manager’s task here is to politely ask to assign tasks to the task manager. You can even refer to the fact that the task will be lost on Skype, please put it in the task manager. At first, this may irritate the client, but over time, the advantages of this approach will become clear to him.However, discussing tasks, especially large ones, is ineffective in a tracker. Skype, telephone with mandatory recording of conversation results into specific tasks. Usually our project manager summarizes the conversation. The client’s task is to check and approve the correctness of the wording and give the go-ahead for work.
It is clear that there are situations when everything has fallen and you need to call and urgently resolve the issue. For example, we had a case when an online shoe store, at the time of a currency panic, began to receive 100 orders per hour, and the client urgently needed to stop sales, because... Logistics couldn't cope. It is clear that in cases of force majeure, we will drop everything and solve the problem over the phone. Even on weekends and after hours. But we cannot afford to create a universal panic over every little thing. Almost all clients understand this if it is explained to them.
Accurate estimates
For most technical support projects, payment is based on actual time spent. The manager’s task is to give preliminary estimates of labor intensity and find out from the client whether we are completing the tasks or not. If we begin to deviate from the estimate (for example, we found some feature of the project that does not allow us to complete the work on time), the manager’s responsibility is to warn the client, report new forecasts on the estimates and clarify whether we are completing the tasks or not. There is no particular point in inflating deadlines and estimates, because... the client feels this and will tell us this during the satisfaction survey.However, for some corporate sector projects where there is a cumbersome budgeting procedure, this approach is not suitable: all estimates and budgets must be signed and approved in advance. In this case, our assessments will include the maximum number of risks that we can foresee for each of the tasks.
I would like to note that time & material work is in practice faster and cheaper for the client, but it is only possible if the client trusts and is satisfied. This is also beneficial for us, because... reduces management and bureaucracy costs (and the manager, let me remind you, we have a bottleneck of the system).
On the issue of accurate estimates: although there are good estimation methods, there are no exact estimates. This idea is difficult to convey to the client and it is very easy to go into demagoguery. I prefer not to get carried away with discussing this topic with the client, but simply outline two schemes of work: with assessments that include our risks and assessments where the client bears all the risks, and give a choice. In the end, we must understand that the client’s budgets are limited, and the client – that it makes no sense for us to work without profit.
If you are seriously interested in the issue of accurate estimates, at the end of the article I have as many links as possible.
Responsibility for what has been done
According to the scheme of work based on finalized estimates, all coding risks lie on our side. Let me note that we are not ready to service any project according to this scheme.With the time+material scheme, essentially all the risks lie with the client. If there are a lot of errors and their correction is presented to the client, he will be dissatisfied and will tell you about it. As a rule, it is more economically profitable not to enter into a dispute and correct your mistakes at your own expense, without escalating the situation, even though a work schedule has been agreed upon based on actual hours. I am committed to correcting errors at our expense if:
- supported project;
- It’s clear step by step how to reproduce the error;
- It is obvious to both parties that this is a design (implementation) error.
If the mistake is frankly ours, we take it and fix it without composting our brains. So it ends up being cheaper.
Exception: very complex systems with a large number of dependencies. If you change a comma in the product card, some tricky import that runs once a month will break. Here you either need a code freeze + a full system test for each change (which is very expensive), or complete code coverage with tests (which is also very, very expensive), or humility that such situations are possible.
Let me note that for the scheme to work, it is necessary that controversial situations arise as rarely as possible. Otherwise, the client will be dissatisfied with the support or the support will be unprofitable for the studio.
Another nuance - we are not responsible for third parties (for example, hosting) or lost profits. Usually this is perceived adequately.
Efficiency
In our staff contracts we guarantee a response time of 24 working hours. In 97% of cases this is a valid option. Please note that we are talking specifically about reaction time, and not about the readiness time of any assigned task. This is all at the level of common sense, and there is no particular reason to demand that we foam at the mouth and cram something that we can’t fit into 24 hours.Basically, the actual speed of work depends on how quickly the task gets to development. What does it consist of:
0-8h for acceptance and clarification of the task. The manager receives a notification that a new task has been created. Banal business etiquette and the empty box principle require that all such requests be processed within 24 hours. Further, depending on the urgency, the task can either be postponed until a sprint is formed, or urgently put into work, or planned in the programmer’s work plan for the next day. Or, if the wording is unclear, we start working on clarifying the wording. Formally, here the manager has a loophole to turn on the fool and not understand something for a long, long time and clarify it. However, clients sense this and become extremely unhappy in such situations and will certainly tell you about it. All that remains is to understand the reasons and apply a control action.
8-16h usually a day after the task has been received by the project manager and all the wording is clear, it goes into development. This is due to the fact that we plan what projects each programmer will work on during morning planning meetings (at 8:45) and then we try not to deviate from this plan. As a rule, a task from a client falls into the development plan the next day after it is delivered (but it happens that it happens on the same day).
16-24h In most cases, small tasks are completed and shipped to the client in the first 8-16 hours. Another 8 hours is a reserve to smooth out our flow of work or testing.
For large and labor-intensive tasks, either a sprint or a completion schedule is formed, depending on their urgency and client priorities. It is absolutely unproductive to do 30-40 hour tasks in bursts of 2 hours a day.
It is clear that where there is force majeure, everything is broken and we need to throw everything away and fix it - we throw it away and fix it. If the level of force majeure is higher than 3-5% of all tasks, this is a reason to look for flaws in the organization of the project itself or our work on it.
Well, whatever is not expensive
We have two tariff scales:- ordinary, for tasks that do not light up. They can be collected in a sprint or done within our schedule.
- urgent (when “we give up everything, do it at any cost”), at a double rate.
The most important thing. Retrospectives. Debriefing
This is the most important part of the technical support system. Without it, mutual hidden discontent will accumulate, which will one day develop into a conflict. The web developer will always be to blame. Always!I would like to note that in the long term, client failure is almost inevitable (well, I don’t know of cases when a client would be completely satisfied with the 2-3 year result of support, would not have any complaints and would not look the other way from time to time). So.
It is quite correct to review with the client what has been done in 2-3 months. Formally analyze the list of tasks and look at the causes of errors. This could be wording, in which case you should decide together how you can improve your goal setting. These may be too frequent programming errors, and here you need to look for the reasons on your side. Finally, the client may be unhappy that he was not dissuaded from some of his ideas and this only led to unnecessary waste of money.
You must systematically check whether the client is satisfied with working with you. Meet in person, talk, discuss the prospects of the project, the client’s business prospects and his plans for the coming year. You should be especially careful when changing managers on the client side. It is important to tell the client where you can meet him halfway and where you cannot, and why. This adds openness and controllability.
Without this, you will be lost in the long run.
Total
Demand for technical support now far exceeds supply. Especially during a crisis, many will strive to “patch up the site” rather than start any serious work. However, it is VERY difficult to organize work competently, clearly and cost-effectively here. First of all, because high and versatile competencies of managers and developers are required. Efficiency, multitasking and frequent switching. Lots and lots of routine. And all this against the backdrop of a high conflict atmosphere.Click on the picture to go to the interactive map