Service Desk *

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

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

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

Привет, Хабр! Меня зовут Павел Родичев, и я тимлид технической поддержки в СберМаркете. Эта статья — о том, как мы интегрировали в Jira систему, которая для этого не предназначена, и сократили время на нотификацию пользователей.

В любой организации имеются ролевые почтовые адреса (типа info@company.com или order@company.com) с которыми коллективно работает группа сотрудников . В некоторых почтовых системах (как например MS Exhange), поддержка таких адресов уже зашита в логику программного обеспечения. В других случаях приходится самим подбирать различные технические подходы. Давайте рассмотрим их подробнее.

После ухода компании Atlassian мы взялись за задачу по импортозамещению её продуктов. И если ранее мы уже заменили Jira и Confluence, то теперь пришла очередь другого крупного продукта - Jira Service Management. 

Наконец-то можно рассказать о том, что мы успели сделать в его замене - EvaServiceDesk. Мы уже показывали альфа-версию продукта для сообщества Atlassian Community Moscow, теперь официальный релиз в проде.

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

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

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

Вот так завлекаю на прочтение. Остальное найдёте в статье...

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

Здравствуйте!

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

Уважаемый пользователь! Вы устроились на работу, поздравляем! Теперь вы — специалист серьёзной организации. Это значит, что для вас автоматически открыт доступ ко всем информационным системам, и не нужны никакие приказы и тому подобные бумажки. Всё автоматизировано. У других специалистов же всё работает, так и у вас должно!

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

Привет! В прошлой статье мы рассказывали о 7 из 14 кейсов, с которыми столкнулись только за последний год, работая в саппорте на зарубежном проекте. Напомним, уже 9 лет мы сотрудничаем с клиентом из Великобритании, который предоставляет ПО для госпиталей и обеспечивает целый ряд шагов бизнес-процесса. Предысторию проекта и то, как работа в саппорте помогает развивать IT-продукт и повышать квалификацию, описали здесь. 

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

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

Компания iSpring 20 лет разрабатывает решения для дистанционного корпоративного обучения. Клиенты находятся в 172 странах, поддержка работает в режиме 24/7 на семи языках. В месяц обрабатываем примерно 7300 обращений по всем каналам связи: по телефону, электронной почте, в чате. 

97% кейсов закрываются со статусом «Довольный клиент». Но так было не всегда: чем больше становилось клиентов, тем сильнее мы начали проседать. Особенно страдали кейсы, которые отдавались в разработку. 

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

Меня зовут Арина, я руководитель отдела технической поддержки iSpring. Расскажу, как переход к двухуровневой системе поддержки помог сократить время решения задач с трёх дней до трёх часов, снизить нагрузку на отдел и перестать дёргать разработчиков из-за лёгких задач. 

Привет! Я работаю в компании Bercut, которая входит в группу компаний Ростелеком и более 20 лет занимается разработкой и поддержкой ПО для операторов сотовой и фиксированной связи. Сегодня я хочу рассказать про решение по комплексному мониторингу биллинговой системы у оператора связи на основе Grafana, Prometheus и Oracle ORDS. В едином графическом интерфейсе Grafana я объединил метрики приложения из БД, некоторые статистики работы самой БД Oracle и статистики сервера БД. Теперь в Grafana инженерам доступен мониторинг всего работающего оборудования и ПО, включая биллинг, что позволяет сократить время на выявление и локализацию сбоев.

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

Хороший интерфейс действительно должен помогать пользователю быстро понять продукт и научиться им пользоваться. Как всегда есть пара НО. 

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

SaaS или On-Premise (локальное или облачное развертывание) в разрезе безопасности использования данных.

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