Организация работы службы поддержки онлайн проекта. Первая часть

В конце прошлого года в рамках выступления на конференции “Деловой интернет“, которая прошла под Минском и стала самым ярким событием белорусской IT-сферы, мной был подготовлен доклад на тему “Организация работы службы поддержки онлайн проекта“, которым в полном объеме хочу с вами поделиться сегодня.

Считаю, что при нынешнем буме интернет-проектов в Беларуси, не все уделяют должного внимания организации обратной связи с клиентами и последующему распределению задач внутри компании. В связи с этим возникает риск понижения лояльности к проекту и возможным отказом от услуг со стороны клиента. Чтобы избежать этих “косяков” были объеденены некоторые наработки экспертов в этой области с собственными наблюдениями и принципами работы.

Возможно, для кого-то материал не покажется сверх информативным (по принципу, это и так всем известно), с другой стороны, он может помочь кому-то в развитии собственной службы поддержки клиентов…

Кратко, о чем пойдет речь.

  1. Основополагающие принципы организации службы поддержки
  2. Типы обращений пользователей
  3. Правила взаимодействия внутри службы поддержки
  4. Графическое представление правил взаимодействия
  5. Роли в службе поддержки
  6. Риски персонала и совмещение
  7. Возможность совмещения участков работ
  8. Документы, регламентирующие оказание поддержки пользователям
  9. Отчетность, предоставляемая службой поддержки
  10. Средства автоматизации: ключевые характеристики
  11. И, конечно же, выводы

Сегодня, в первой части работы вы познакомитесь с пунктами 1-5. При подготовке материала были использованы некоторые наработки Заурбека Алехина и объеденены с собственным опытом развития службы поддержки проекта «Сайтодром» на позиции ее руководителя.

В последнее время многие компании с при разработке онлайн проектов все чаще уделяют внимание необходимости создания службы поддержки пользователей. Служба поддержки  - это некоторая диспетчерская служба, которая ответственна перед пользователем за предоставление качественных  сервисов и услуг, она также выполняет задачи по приему жалоб и предложений, осуществляет мониторинг текущего состояния сервисов и распределяет поручения на устранение проблем в работе сервисов и сбоев в системе.

Для чего нужна служба поддержки пользователей? Дело в том, что эффективная поддержка предоставляемых компанией сервисов оказывается критичной для достижения поставленных бизнес-целей. Когда пользователь сталкивается с какой-либо проблемой (некорректностью работы сервиса, системным сбоем, просто неумением пользоваться) он стремится получить квалифицированную помощь в работе с купленной им услугой или продуктом. При этом единственное, что его интересует - это максимальное быстрое разрешение проблемы.

В самом общем виде служба поддержки обеспечивает единую точку контакта для пользователей, клиентов. Это наиболее важная для клиента функция службы поддержки пользователей. Действительно, клиент, как правило, пользуется сервисом без помощи представителей компании и обращается к последним только в особых случаях - при возникновении инцидента или при желании внести изменения в структуру получаемых сервисов - то есть общается только со специалистом службы поддержки. В свою очередь внутри компании служба поддержки отстаивает интересы клиента перед разработчиками сервисов и продуктов.

Также служба поддержки отвечает за устранение возникающих инцидентов даже при условии, что работы выполняются специалистами других отделов компании (в том числе - и “внешними” партнерами), ведет полный учет времени устранения инцидента, контроль за процессом устранения, информирование пользователя о состоянии проблемы, информирование руководства о задержках в устранении их причин, все это - обязанности службы поддержки. В общем, работа службы поддержки должна быть ориентирована на клиента и качество предоставляемых ему сервисов. При этом не надо забывать, что службе поддержки должны быть предоставлены соответствующие права.

Кроме этого, на плечи службы поддержки ложиться формирование разнообразных аналитических отчетов, в том числе об уровнях загруженности ресурсов; производительности и эффективности предоставляемых сервисов; необходимости обучения клиентов; дефиците сервисов и т.д.

Сразу оговорюсь, что служба поддержки необходима не только в крупных организациях с большим числом пользователей и предоставляемых сервисов, но, как показывает наш опыт, и в небольших компаниях, где управление ресурсами, технологиями и уровень документирования необходимых процедур и решений могут быть не менее важными и существенными.

Важно обратить внимание на то, что в современной концепции специалист службы поддержки обязан принимать все ощущения клиента (возникающие в ходе эксплуатации сервисов) как истину и тем самым выступать как бы на стороне клиента, требуя от персонала компании разрешения проблем данного клиента. Кроме этого сегодня существует множество возможностей для обеспечения контакта с клиентами: по телефону, электронной почте, через Web-сайт, факc и т.д.

Итак, создание службы поддержки пользователей полезно для любого типа организации и может принести реальные выгоды:

  1. Улучшение качества обслуживания клиентов компании.
  2. Контроль за текущим состоянием ИТ-инфраструктуры в целом, отдельных сервисов и компонент.
  3. Повышение качества взаимодействия различных подраздалений компании между собой.
  4. Уменьшение общего числа сбоев и нестандартных ситуаций.
  5. Уменьшение времени восстановления системы после возникновения аварийной ситуации.
  6. Качественное изменение уровня системы поддержки пользователей.
  7. Увеличение возможности самообразования пользователей.
  8. Прогнозирование возможных проблем и своевременное вырабатывание предложений по их предотвращению.

При всем этом у клиентов повышается уровень лояльности к компании и кредит доверия, который вполне оправдывает себя в сложных ситуациях.

Рассмотрим более подробно из чего состоит такая служба и как ее создать для онлайн проектов.

Основополагающие принципы организации службы поддержки.

Прежде всего давайте рассматривать отношения между конечными пользователями и службой поддержки как традиционные рыночные отношения. То есть при наличии некоторого сервиса или ряда услуг компания выступает в качестве их поставщика, а пользователь - в качестве покупателя соответствующей услуги. Между поставщиком и покупателем заключается некоторое соглашение, которое определяет условия предоставления услуги, т.к. только при организации взаимодействия именно на основе таких принципов возможно достижение полного контроля над качественным предоставлением услуг и обслуживания сервисов, а также существенное сокращение расходов на сожержание службы поддержки.

Предметом договоренности в предлагаемой модели является некоторая услуга, предоставляемая компанией, и которую в дальнейшем мы будем называть “сервис”.

Понятие “сервис” в ситуации предоставления услуг в онлайне обычно употребляется в нескольких различных смыслах. С одной стороны - это услуга, которую служба поддержки предоставляет конечному пользователю. Например, использование конструктора сайтов для создания и поддержки сайта в интернете. С другой стороны, предоставление услуги связано с использованием целого ряда технологий и решений. В этом смысле всякий сервис - это структурированный набор оборудования, программного обеспечения, технологий, других сервисов. Например, создание сайта в конструкторе сайтов предполагает наличие серверов с инсталляцией CMS, организации их бесперебойной работы, персонального компьютера с установленным на нем браузером и т.д. Эта сторона сервиса не должна представлять большой интерес для конечного пользователя. Но она очень важна для организации деятельности службы поддержки пользователей.

В итоге сервис - это то, что пользователи хотят получить, а их поддержка при работе с сервисом - основная задача службы поддержки проекта.

Одной из острых проблем остается обучение пользователей работе с предоставляемыми сервисами. И поскольку система постоянно развивается - обучение пользователей должно происходить регулярно, т.к. у них все равно возникнут различные вопросы и проблемы, связанные с предоставляемыми сервисами. То есть будут возникать ситуации, когда клиенту будет нужна помощь. В этом случае пользователь может попробовать самостоятельно решить проблему или обратиться за помощью к поставщику сервиса. У каждого из вариантов есть свои положительные и отрицательные черты.

Самостоятельное решение проблемы - наиболее быстрый способ, поскольку нет необходимости искать кого-нибудь, ждать, объяснять и т.д. Но далеко не все проблемы могут быть решены самостоятельно: например, никакой пользователь не сможет устранить проблемы на сервере.

Наиболее правильным является обращение за помощью к поставщику сервиса. Основной проблемой при таком обращении обычно является отсутствие качественного механизма для получения необходимой информации от поставщика услуг. В остальном - только плюсы: имеются квалифицированные специалисты; проблема будет решена оптимальным образом; имеется база знаний, которая может помочь в решении проблем. И еще одно неоспоримое преимущество перед первым способом: заключив соглашение с поставщиком сервиса, пользователь тем самым имеет право требовать от поставщика нормальной работы сервиса, в то время, как требовать это от себя невозможно. Поэтому по всем вопросам, связанным с использованием сервисов, пользователи должны обращаться только в службу поддержки пользователей.

Приняв решение о необходимости обратиться за помощью, пользователь обычно оказывается в несколько неопределенной ситуации: кому именно задать вопрос? Он может попытаться спросить любого сотрудника компании и тот, скорее всего, посоветует к кому именно следует обратиться по данному вопросу. Вероятность успешного результата по поиску ответа невелика. Отсутствие ответственных за работу с пользователями сотрудников приводит к определенному хаосу в деятельности компании, а в итоге - к контрпродуктивному выяснению отношений.

Пользователи  не должны держать в уме по несколько телефонов и имен специалистов, отвечающих за тот или иной участок. Должен существовать единый телефон и e-mal службы поддержки, которая координирует всю работу и взаимодействует с пользователями по всем запросам.

Эффективная поддержка является ключевым моментом в организации обслуживания и сопровождения пользователей сервисов. По качеству работы службы поддержки зачастую оценивают деятельность всей компании. Поэтому очень важно заслужить авторитет и статус надежной и оперативной службы поддержки, предоставляя пользователям постоянно доступную, единую и дружественную точку контакта с ИТ-персоналом, гарантируя своевременное квалифицированное решение проблем по поступившим запросам и заявкам.

“Единая точка” означает обращения в службу поддержки по всем доступным каналам (почта, телефон, факс, заявка с сайта и т.п.) и обрабатываются в итоге одним и тем же способом. Типичная ошибка - отказ от выделения единых для всех пользователей каналов взаимодействия. В таких случаях подразумевается, что любой контакт с любым представителем службы поддержки - и есть тот самый канал, а значит, все и так хорошо и вполне соответствует рекомендациям. Но это не обеспечивает четко обозначенное требование по обмену информацией, и в результате следует признать, что единая точка контакта здесь не обеспечена. Например, пользователь задал вопрос одному сотруднику службы поддержки, и пока тот думает - потребовал ответ у другого. В худшем случае пользователь получит два противоречивых ответа, что может стать основанием для предъявления претензий к работе службы поддержки.

Решением может стать четкое обозначение каналов взаимодействия пользователей и службы поддержки, а также обеспечение своевременного обмена информацией. В данной ситуации необходимо построение единого централизованного хранилища всей информации и обеспечение возможности доступа к ней персоналу службы поддержки. Конечно, это должно быть подкреплено соответствующими регламентами: следует предотвратить неправильное использование технологий.

Многие пользователи давно общаются с отдельными сотрудниками службы поддержки, и особых неприятностей это не вызывает. Но будет ли компания четко знать о текущем состоянии заявки, если о ней знает только один специалист? Да, но только в том случае, если он ее зарегистрирует непосредственно при получении. Станет ли он так делать? Скорее всего нет, поскольку будет занят ее решением, а регистрация для него - не основная задача. Что будет происходить, если заявка связана с некоторым инцидентом, затрагивающим более одного пользователя? Пользователи начнут обращаться в общем случае либо к другим специалистам компании, либо в службу поддержки. При этом будет происходить дублирование усилий на устранение инцидента или возникнет ситуация, когда пользователь уже обращался, а о заявке никто ничего не знает. Реально кто-то конечно же знает, но больше никому об этом не говорит.

Еще одним минусом в описанной ситуации является стремление пользователей задавать любые вопросы знакомому специалисту. Многие из этих вопросов будут явно обращены не по адресу, будут и те, что не требуют быстрого решения. Если сотрудник компании сам будет расставлять приоритеты в своей работе, то служба поддержки не сможет обеспечить исполнение обязательств перед клиентами.

Решение – это следование рекомендованным правилам:

  1. Сформировать службу поддержки пользователей
  2. Оснастить ее необходимыми технологическими решениями и обучить ее персонал качественно исполнять обязанности
  3. Изолировать сотрудников компании от первичных контактов с пользователями
  4. Обеспечить регистрацию всех действий по обработке инцидентов и иных заявок, исполняемых специалистами.

Это улучшит возможности управления персоналом службы поддержки и специалистами компании, исключит традиционные претензии, связанные с тем, что пользователь не может найти ответственного за решение его вопроса, а также с потерей заявок и т. п.

Благодаря отлаженной работе службы поддержки увеличивается эффективность работы каждого сотрудника, от которого в свою очередь зависит успех всей компании в целом, организация получает дополнительные конкурентные преимущества, предоставляя клиентам качественное и бесперебойное обслуживание.

Поэтому единственный вариант, когда любой пользователь точно знает к кому именно следует обращаться с вопросами, и при этом соответствующий представитель службы поддержки всегда готов выслушать обращение пользователя и предпринять необходимые шаги для решения поставленного вопроса - это создание в рамках компании, разработавшей сервис, службы поддержки пользователей. В рамках службы поддержки должен существовать круг лиц (это может быть и один человек), которые будут отвечать на запросы пользователей.

Но нельзя ограничиться только этим кругом лиц. Чтобы запрос пользователя не оказался “повисшим в воздухе”, а был рассмотрен специалистом в допустимые сроки, необходимо разработать определенные правила взаимодействия. Дело в том, что с момента обращения пользователя в службу поддержки за помощью, он снимает с себя ответственность и может абсолютно ничего не делать, поскольку при разборе ситуации виноватой все равно окажется компания, предоставляющая набор сервисов. Таким образом, уже сама служба поддержки становится заинтересованной в качественной и быстрой обработке заявки, разграничении полномочий и упорядочении деятельности сотрудников при оказании помощи пользователям. Последовательность обработки обращений пользователей должна помочь сосредоточить силы сотрудников компании на наиболее важных и критичных, но вместе с тем не оставить без должного внимания и все остальные обращения пользователей. Поэтому все обращения должны быть оценены и приоритезированы специалистами службы поддержки (диспетчерами). Это связано с тем, что невозможно одинаково быстро отработать все проблемы, тем более что большинство из них и не требуют быстрого решения. Поэтому ранжирование заявок способствует более гибкому управлению ресурсами и позволяет устранять критичные проблемы. Происходит своеобразное разделение труда. Пользователи тоже участвуют в такого рода разделении труда, поскольку обращаются за помощью только к диспетчерам и не отвлекают своими вопросами остальных сотрудников компании, давая им возможность работать более продуктивно.

Необходимо учитывать, что способность к быстрой оценке проблемы является практическим навыком и не любой специалист может выполнить такую работы. Для этого требуются специфические навыки, широкие знания по ИТ (иногда достаточно даже вполне поверхностных), умение эффективно общаться с людьми, быстро принимать решение. Специалист службы поддержки должен быть:

  • ориентирован на клиента;
  • четко и систематически выражать свои мысли;
  • иметь навыки межличностного общения;
  • способен понимать цели бизнеса;
  • должен помнить, что:
  1. проблемы клиента важны для бизнеса;
  2. без клиентов не нужна будет и служба поддержки;
  3. клиенты являются экспертами в своей деятельности.
  • стремится предоставлять первоклассный сервис.

Поэтому необходимо тщательно отработать процедуры решения тех вопросов, которые требуют особого внимания или имеют приоритетную важность. В этих случаях служба поддержки обращается напрямую к разработчикам сервисов. В случаях с наиболее срочными проблемами, получающими высший Уровень важности, команда разработчиков и служба поддержки должны работать до тех пор, пока вопрос не будет решен или не уменьшится острота стоящей проблемы, при этом с клиентом поддерживается постоянный контакт для того, чтобы он также отслеживал состояние процесса и степень достигнутого успеха.

Основные виды поддержки пользователей (пример приоритезации запросов пользователей):

grafik_obrabotki_zajavok.gif

Порядок оказания поддержки пользователям должен быть четко формализован для пользователей, диспетчеров, разработчиков сервисов.

С этой точки зрения перечисленные нами возможности и пути улучшения позволяют построить реально полезную для компании систему поддержки пользователей. Для дальнейшего восприятия необходимо определить более точно предмет деятельности службы поддержки, то есть - какого типа помощь может понадобиться конечным пользователям.

Типы обращений пользователей.

Предлагается следующий вариант классификации обращений пользователей в службу поддержки:

  • Запрос обслуживания. Запрос, связанный с необходимостью обслуживания того или иного компонента сервиса со стороны службы поддержки. Например, смена учетных записей для почтовых ящиков клиента. Или расширение квот на использование ИТ сервиса в рамках текущего тарифного плана.
  • Запрос информации. Пользователю нужна информация по сервису, способу подключения, его стоимости и т.п.
  • Инцидент. Работа сервиса нарушена: недоступен или качество сервиса не заявленному.
  • Запрос документации. Пользователю необходима документация: руководство пользователя, финансовые документы и прочее..
  • Запрос на внесение изменений. Запрос на смену параметров сервиса. Такие запросы в основном связаны с низким качеством сервиса либо ограничениями в рамках текущего тарифного плана.

Такая классификация позволяет более эффективно строить дальнейшую обработку обращений в службу поддержки. В зависимости от типа обращения специалист службы поддержки принимает решение о том, кто будет исполнителем данного обращения. Наиболее критичным для бизнеса типом обращения является инцидент, обработка которого является основным процессоом, выполняемым службой поддержки пользователей. Данный тип обращения включает в себя выполнение действий по восстановлению работоспособности сервиса.

Правила взаимодействия внутри службы поддержки.

Создание службы поддержки пользователей - это в первую очередь четкое определение: правил взаимодействия конечных пользователей со службой поддержки, правил работы сотрудников службы поддержки и правил взаимодействия сотрудников компании между собой. Эти правила равила должны содержать ответы на перечисленные ниже вопросы.

Взаимодействие конечных пользователей со службой поддержки:

  • каким образом конечный пользователь может обратиться за поддержкой

  • какие запросы пользователя должны быть обработаны службой

  • каким образом конечный пользователь может уточнить текущее состояние обработки своего запроса

  • каким образом пользователь подтверждает закрытие своего запроса

Работа сотрудников службы поддержки пользователей:

  • каким образом осуществляется учет обращений пользователей

  • каким образом определяются приоритеты обработки обращений пользователей

  • каким образом определяются исполнители, ответственные за обработку обращений пользователей

  • каким образом специалист, ответственный за обработку обращения пользователя, осуществляет данную обработку

  • каким образом сотрудники службы поддержки учитывают выполненные действия и отчитываются о проделанной работе

Взаимодействие сотрудников компании между собой:

  • каким образом специалист назначается ответственным за обработку обращения пользователя 

  • каким образом осуществляется контроль процесса обработки

  • каким образом может быть изменен ответственный за обработку обращения пользователя

Четко проработанные ответы даже только на перечисленные вопросы позволят организовать нормально функционирующую службу поддержки онлайн проекта.

Графическое представление правил взаимодействия.

graph.jpg

Роли в службе поддержки.

Следующим важным составляющим звеном при создании службы поддержки являются люди. Необходимо выделить группу сотрудников, которые будут исполнять обязанности диспетчеров - то есть именно тех, к кому непосредственно будут обращаться пользователи со своими запросами. В случае небольшой компании это может привести к возложению таких обязанностей на одного сотрудника дополнительно к существующим обязанностям.

В общем случае необходимые изменения в компании при организации службы поддержки связаны с возникновением новых ролей в результате формального описания процессов взаимодействия. Роль - это набор обязанностей, прав и ответственностей.

В ходе организации поддержки пользователей могут возникнуть несколько ролей? Во-первых, это диспетчеры или “первая линия поддержки”. Диспетчеры являются “лицом” службы поддержки и отвечают за организацию взаимодействия с пользователями, своевременное информирование пользователей о прогрессе в рассмотрении их запросов, закрытие запросов. Кроме этого диспетчеры инициируют рассмотрение обращения пользователя путем его регистрации и назначения ответственного за его обработку, а также контролируют процесс обработки, следя за тем, чтобы все запросы были обработаны, и своевременно сообщая о возможных задержках.  На них могут быть возложены и иные обязанности, в частности, оказание дополнительных услуг.

Еще одной ролью, которая может быть дана специалисту службы поддержки (диспетчеру), является контролер качества. Данная роль помогает организовать процесс постоянного мониторинга ИТ-процессов с целью повышения качества конечных продуктов и услуг, а также обслуживания пользователей. Основными участками работы специалиста с данной ролью являются разработка новых предложений по усовершенствованию сервисов и поддержка пользователей. Он осуществляет контроль за соблюдением установленных регламентов и стандартов в области ИТ, отслеживают адекватность пользовательской документации, проводит контрольное тестирование программного обеспечения.

Во-вторых - это руководитель службы поддержки пользователей. Его основной задачей является организация поддержки пользователей; координация действий сотрудников; контроль эффективности работы службы поддержки; организация обучения персонала службы поддержки; обучение конечных пользователей и другие. Также руководитель службы поддержки выступает в роли системного аналитика. Он интерпретирует требования и пожелания пользователей, облекая их в документальную форму, понятную пользователям (бизнес-требования), и в форму, понятную разработчикам, программистам (техническое задание). Он должен обладать широким профессиональным кругозором, детальным пониманием бизнеса и предметных областей, при этом знать основы проектирования информационных систем, возможности и ограничения при разработке программ. Для исполнения роли руководителя службы поддержки пользователей рекомендуется выделить отдельную штатную единицу.

В-третьих, это специалисты по различным направлениям деятельности компании (разработчики отдела девелопмента коммпании), так называемая “вторая линия поддержки”. Специалисты второй линии - основные исполнители запросов пользователей на серьёзные модификации, люди, решающие критические проблемы в стабильности системы. Для повышения уровня взаимодействия им могут быть назначены роли ответственности (например, распределение ролей по поддержке определенных сервисов). Очевидно, что в этом случае не стоит формировать отдельные подразделения, а следует привлекать специалистов компании на временной основе.

Наиболее востребованные роли специалистов “второй линии поддержки” это:

Прикладные программисты - отвечают за разработку новых систем, доработку, изменение используемых систем. Эта разработка ведется на основе согласованных системными аналитиками требований и документов. Профессиональные навыки состоят в умении наиболее эффективным способом создавать программы, используя знания по современным средствам разработки. Также для них очень важным является умение работать в группе разработчиков, осуществляя программирование в соответствии с утвержденными стандартами и распределением обязанностей.

Тестировщики - осуществляют тестирование разработанных программ с целью выявления ошибок или возможных проблем при эксплуатации систем. Для тестирования требуется менее высокая квалификация, чем для анализа или разработки, однако эта работа требует повышенного внимания и аккуратности.

Системные программисты - отвечают за поддержку, настройку и организацию корректного взаимодействия с системным программным обеспечением (операционные и сетевые системы, утилиты). Обычно в небольшой компании бывает достаточно одного системного программиста для поддержания этой функции на необходимом уровне.

Отдельно несколько слов необходимо сказать об ИТ-менеджерах. Их роль, как и в любой другой деятельности, очень высока. Для управления ИТ требуются две группы менеджеров - линейные менеджеры и руководители проектов. Линейные (или функциональные) менеджеры возглавляют статические подразделения, такие, как отдел поддержки пользователей. Руководители проектов (Project Managers) осуществляют оперативное управление проектом.

Еще одна группа ролей - внешние поставщики сервисов (хостинг компании, регистраторы доменов и проч.). Порядок взаимодействия с ними определяется в соответствии с сервисными контрактами. Желательно стремиться к стандартизации правил взаимодействия.

И, наконец, последняя роль - это конечный пользователь сервиса. Мы специально выделяем эту роль, чтобы еще раз подчеркнуть, что конечный пользователь на самом деле является активным участником процесса поддержки и имеет не только определенные права, но и обязанности.



Еще по теме можно почитать:

  • Организация работы службы поддержки онлайн проекта. Часть вторая, заключительная
  • TUT.BY начал перевод пользователей почты на сервис от Google
  • Отчет блога за февраль 2008 года
  • Вышел восьмой номер онлайн журнала для сеошников SeoDigest
  • TUT.BY начал переводить пользователей почтовой службы на почтовый сервис Google


  • Комментариев: 10

    1. Организация работы службы поддержки онлайн проекта. Часть вторая, заключительная пишет:

      […] Организация работы службы поддержки онлайн проекта. П

    2. Автолюбитель пишет:

      Хорошая у вас поддержка :)

    3. s13 пишет:

      спасибо ))

    4. pent пишет:

      Есть ли какая небудь документация о том что должен знать диспетчер? Ведь ето первая линия обороны, и они на крупных предприятия отсеивают до 70% заявок.

    5. s13 пишет:

      документация составляется на месте и должна учитывать всю специфику работы компании. Каждый случай уникален.

      Пусть начальник отдела поработает месяц со своими подчиненными и выявит основные направления обращений, на основе этого можно скорректировать текущие функции службы поддержки

    6. Роман пишет:

      Я очень хочу у вас работать

    7. Tina пишет:

      Есть над чем задуматься, очень интересно!

    8. support пишет:

      Здравствуйте, интересная статья, сам работаю в службе поддержке.
      И кое что взял для себя.

    9. Вещий пишет:

      Какое это великое счастье - ЖИТЬ,
      СУЩЕСТВОВАТЬ в мире, ДЫШАТЬ, видеть НЕБО, ВОДУ, СОЛНЦЕ! (И. Бунин)

      Вот проблема. ВАШЕ мнение и как быть?

      ВЗРЫВ всегда СТИХИЯ. Цена СТИХИИ Большого Взрыва - Термоядерный ХОЛОКОСТ Мира.
      «Некому будет судить», - это чудовищный ЦИНИЗМ Отца атомной бомбы Оппенгеймера,
      признание им КОНЦА Цивилизации от ЯДЕРНОГО маразма, под стать и его ПАЛАЧЕСКИЙ
      морализм: «Я - СМЕРТЬ, великий разрушитель Миров, несущий ГИБЕЛЬ всему Живому».
      Вот и ФАТАЛЬНО безответственные ОТЦЫ Большого Взрыва рискуют КРЕМАЦИЕЙ Планеты.
      Нет ПОНАРОШКУ Большого Взрыва, его ВСПЫШКА и НАШ Мир - ИСЧЕЗНЕТ. РАЗУМ! Где ты?
      Видимо, ГОРДЫНЯ ума ядерщиков подавила инстинкт самосохранения, УБИЛА совесть.
      Уму непостижимо! Ядерщики ДОПУСКАЮТ риск Термоядерной КАЗНИ Человечества, а Вы?
      Судите Сами. Вероятность ЖИЗНИ ничтожна (~10^-800), значит и такой риск РЕАЛЕН.
      РИСК собой - дело личное, РИСК Термоядерного ИСПЕПЕЛЕНИЯ Землян - ПРЕСТУПЛЕНИЕ.
      Игнорируя оппонентов и УГРОЗЫ 96% ТЕМНОЙ энергии и материи от всего Мироздания
      (всех звезд и Земли осталось 4%), ЯДЕРЩИКИ Большого адронного коллайдера ЦЕРНа
      и др. творят ТЕРМОЯДЕРНОЕ безумие: БОЛЬШОЙ ВЗРЫВ Земли (ОАЗИС Жизни Вселенной).
      Ау! Вселенная! МЫ одни. Похоже, Коллайдерно-Термоядерные игры выжгли иные Миры.
      Выходит, чем вероятней Жизнь, тем верней Наше НЕБЫТИЕ от Коллайдерной АГРЕССИИ.
      Теватрон США шокировал: струи частиц ТЬМЫ вырвались НАРУЖУ, потрясли аномалией.
      ЧЕРНЫЕ Дыры? Страпельки? Монополи? Аннигиляцию? БОЛЬШОЙ Взрыв? Какой Катаклизм
      РАЗВЕРЗНУТ ради «Нобелевки» ШЕФЫ коллайдеров ТЕРМОЯДЕРНОЙ провокацией 96% ТЬМЫ?
      Не атом, УЖАСЕН наш пофигизм: ЖЕРТВЫ Хиросимы, Нагасаки, АЭС Чернобыля, Японии.
      Никакая наука не стоит Землеубийства. Показательны ПРОВАЛЫ защиты безопасности:
      системы «от дурака» в ядерной энергетике и аварийная булочка - мера риска ЦЕРН.
      Не одними коллайдерами движима Наука Мироздания. Следует, оградив ядерщиков от
      ПРЕСТУПНОГО риска, развить НЕОПАСНЫЙ поиск Истины, изучая всеобъемлющий Космос.
      ФАНАТИКИ Большого Взрыва РИСКУЮТ Главным Правом Народов Мира - Правом на ЖИЗНЬ.
      Дабы отвратить Коллайдерно-Термоядерную ЛИКВИДАЦИЮ всех НАС - ПРОТЕСТУЙТЕ Люди!
      Спросите себя: «Если не Я, то кто?» Очнитесь же! Проявив волю, одолевая апатию,
      свершите ПОСТУПОК, разошлите СВОЙ или этот ТЕКСТ и возобладает Торжество ЖИЗНИ!
      P.S.
      Прошу ВАС, рассылайте, уже остановлен навсегда опасный коллайдер США Теватрон.
      Вещий.

    10. Вещий пишет:

      Какое это великое счастье - ЖИТЬ,
      СУЩЕСТВОВАТЬ в мире, ДЫШАТЬ, ВИДЕТЬ небо, воду, солнце! (И. Бунин)

      Вот проблема. ВАШЕ мнение и как быть?

      РИСК собою - дело личное, РИСК Термоядерного ИСПЕПЕЛЕНИЯ Землян - ПРЕСТУПЛЕНИЕ.
      “Некому будет судить”, - это чудовищный ЦИНИЗМ отца атомной бомбы Оппенгеймера,
      признание им ГИБЕЛИ всех ЛЮДЕЙ от ЯДЕРНОГО маразма, под стать и его ПАЛАЧЕСКИЙ
      морализм: “Я - СМЕРТЬ, великий разрушитель МИРОВ, несущий ГИБЕЛЬ всему ЖИВОМУ”.
      Видимо, ГОРДЫНЯ ума ядерщиков подавила инстинкт самосохранения, УБИЛА совесть.
      Не атом, УЖАСЕН наш пофигизм: ЖЕРТВЫ Хиросимы, Нагасаки, АЭС Чернобыля, Японии.
      Вот и ФАТАЛЬНО безответственные ОТЦЫ Большого Взрыва рискуют КРЕМАЦИЕЙ Планеты.
      РИСК небытия от ПРОВОКАЦИЙ Большого Взрыва выше вероятности Жизни во Вселенной.
      Уму непостижимо! Ядерщики зная, ДОПУСКАЮТ РИСК Термоядерной КАЗНИ Человечества.
      Игнорируя оппонентов и УГРОЗЫ 96% ТЕМНОЙ энергии и материи от всего Мироздания
      (всех звезд и Земли осталось 4%), ЯДЕРЩИКИ Большого адронного коллайдера ЦЕРНа
      и др. творят ТЕРМОЯДЕРНОЕ безумие: БОЛЬШОЙ ВЗРЫВ Земли (ОАЗИС Жизни Вселенной).
      Нет ПОНАРОШКУ Большого Взрыва, его ВСПЫШКА и наш МИР – ИСЧЕЗНЕТ. Разум! Где ты?
      Похоже, коллайдерно-термоядерные игры ВЫЖГЛИ иные МИРЫ. Ау! Вселенная! МЫ ОДНИ.
      Выходит, чем вероятней ЖИЗНЬ, тем верней наше НЕБЫТИЕ от коллайдерной АГРЕССИИ.
      Теватрон США шокировал: струи частиц ТЬМЫ вырвались НАРУЖУ, потрясли аномалией.
      Чёрные дыры? Страпельки? Монополи? Аннигиляцию? Большой Взрыв? Какой КАТАКЛИЗМ
      РАЗВЕРЗНУТ ради “Нобелевки” ШЕФЫ коллайдеров ТЕРМОЯДЕРНОЙ провокацией 96% ТЬМЫ?
      Никакие дела ядерщиков не стоят Землеубийства. Символичны ПРОВАЛЫ безопасности:
      “от ДУРАКА” в ядерной энергетике и аварийная “булочка” - ПОКАЗАТЕЛЬ риска ЦЕРН.
      Не одними коллайдерами движима НАУКА Мироздания. Следует, оградив ядерщиков от
      ПРЕСТУПНОГО риска, развить НЕОПАСНЫЙ поиск ИСТИНЫ, изучая всеобъемлющий КОСМОС.
      ФАНАТИКИ Большого Взрыва РИСКУЮТ самым главным Правом Землян - Правом на ЖИЗНЬ.
      Любой взрыв - СТИХИЯ. Цена СТИХИИ Большого Взрыва - термоядерный ХОЛОКОСТ МИРА.
      Чтобы отвратить коллайдерно-термоядерное сожжение ВСЕХ НАС - ПРОТЕСТУЙТЕ! Люди!
      Спросите себя: “Если не Я, то кто?” Очнитесь же! Проявив волю, одолевая апатию,
      свершите ПОСТУПОК, разошлите СВОЙ или этот ТЕКСТ и возобладает торжество ЖИЗНИ!
      P.S.
      Прошу, рассылайте, есть надежда - уже ликвидирован опасный коллайдер Теватрон.
      Вещий.

    Оставьте свой отзыв!

    Новости Беларуси

    03.04.2012

    В доменной зоне .by имя можно отобрать практически у любого

    Законодательство Беларуси в свере IT еще настолько сырое, что зияющие дыры игрыют на руку не совсем честным “бизнесменам”. Опустим вопрос заработка, т.к. на сегодняшний день в белорусских реалиях актуален вопрос “опускания”.
    О том, как вас могут опустить с вашим доменом в зоне .by, отобрав его, рассказал на конференции “Деловой Интернет: Гродно” Повалишев Сергей, возглавляющий компанию “Хостер Бай”. […]

    01.04.2012

    MediaBarCamp 2012 наступает!

    3-6 мая 2012 в Литве состоится пятый международный МедиаБарКэмп, посвященный использованию новых возможностей социальных медиа и развитию медиа-активизма среди молодежи. MediaBarCamp организуется Swedish International Liberal Centre, Green Forum, Centerpartiets Internationella Stiftelse, Olof Palme Internattional Center и Беларуской партией “Зелёные”.
    Самое главное, что несмотря на то, что мероприятие в основном организовано для белорусов, принять в нем участие […]

    27.02.2012

    Домены в зоне .by теперь можно регистрировать мгновенно

    С 25 февраля 2012 года в доменной зоне .by значительно упрощены правила регистрации.
    Отныне отменена процедура обязательного согласования с Администратором доменной зоны, которая ранее занимала до пяти дней, также отмена процедура резервирования домена пользователями до его оплаты на срок до 30 дней. Последний факт искусственно закрывал возможность для регистрации интересных имен, породив спекуляции на рынке доменных […]

    05.09.2011

    “Деловой Интернет” стал платным - 5 долларов за участие

    3-4 октября 2011 года в Минске состоится шестая ежегодная конференция “Деловой Интернет-2011“. И впервые конференцию решено сделать платной и без привычного для многих генспонсора - государственного телекоммуникационного монополиста “Белтелекома”. Ожидается значительное просеивание рядов слушателей от школьников и просто прохожих, которых было бы очень много в центре Минска (конференция впервые переехала в самое удачное место для […]

    Реклама

    Новости IT-сферы

    20.01.2012

    В Рунете тестируют убийцу конструкторов-сайтов

    В начале 2000-ых в Рунет пришли конструкторы сайтов, платные и условно-бесплатные, успешные и не очень. По сути с десяток лет все было очень даже спокойно, конкуренция друг с другом на компаниях особо и не сказывалась, а новые плюшки появлялись исключительно за деньги. И вот на сцене появился setup.ru.
    Вы спросите, чем же он так хорош и […]

    19.10.2011

    Нелимитируемые переводы через Яндекс.Деньги возможны через сервис онлайн-идентификации

    Пользователи систем электронных денег теперь смогут проводить платежи на любые суммы, а не на максимально разрешенные антиотмывочным законодательством 15 тыс. руб., как это было до сих пор. Это станет возможным благодаря сервису онлайн-идентификации, запускаемому системой “Яндекс.Деньги” и бюро кредитных историй (БКИ) “Эквифакс кредит сервисиз”. По пути онлайн-идентификации клиентов готовы пойти и другие системы электронных денег […]

    05.10.2011

    За две недели “Яндекс” подешевел на 40%

    Инвесторы посчитали “Яндекс” переоцененным. Из-за небольшой потери поискового рынка России за акцию “Яндекса” дают $18,8, тогда как еще в июле одна акция оценивалась в $38,5.
    В России “Яндекс” впервые за последние годы начал терять долю рынка. В третьем квартале она снизилась всего на 0,5%, но этого хватило, чтобы по итогам минувшей среды акции “Яндекса” подешевели на […]

    08.09.2011

    Инструменты оптимизатора: новый бесплатный сервис проверки Google карт сайта

    В сети появился новый seo-сервис для оптимизаторов - Google Sitemaps Status Checker. Как пояснил Павел Мальто из SEO Research Inc., сервис выполняет только одну, но очень полезную функцию: каждый час проверяет статусы карт сайтов и отправляет на почту уведомление, если Google обнаружит ошибку.

    SEO-сервис будет полезен владельцем сайтов, у которых автоматически геренируются карты сайтов, другими словами, […]

    Ссылки