Настройки отправки почты через SMTP
05 июля 2016. Категория: Нужно знать!
Встречаются случаи, когда сайтостроители сталкиваются с проблемой работы электронной почты сайта на CMS Joomla. Например, при отправки письма через форму обратной связи могут появляться ошибки следующего типа: «Could not instantiate mail function» или «Не удалось вызвать функцию mail» . Также возможен вариант отправления письма без появления ошибок, однако в результате оно все равно не доходит до адресата.
Почему же происходят данные проблемы с почтой? Чтобы ответить на данный вопрос необходимо в панели управления пройти по следующему пути: «Система» — «Общие настройки» — вкладка «Сервер» — раздел «Настройка почты».
В CMS Joomla предусмотрено три механизма отправки писем: PHP Mail, Sendmail и SMTP. По умолчанию используется PHP Mail с которым зачастую и происходят проблемы, которые, в основном, связаны с настройками используемого хостинга.
Исходя из вышеизложенного делаем вывод: либо обращаемся за помощью к хостинг провайдеру, либо используем способ отправки писем Sendmail или SMTP. Остановимся на использовании SMTP.
Настройки отправки почты при помощи SMTP
SMTP (англ. Simple Mail Transfer Protocol) — сетевой протокол, используемый для передачи электронной почты. Для использования SMTP необходимо корректно выставить настройки определенного почтового сервера, который будет использоваться.
Чтобы увидеть настройки SMTP, необходимо в «Способе отправки» выбрать «SMTP». Рассмотрим каждую настройку популярных почтовых серверов: Yandex, Mail, Gmail, Rambler и Yahoo.
Настройки SMTP для Yandex
Настройки SMTP для Mail
Настройки SMTP для Gmail
Настройки SMTP для Rambler
Настройки SMTP для Yahoo
Проверить отправку почты можно при помощи нажатии кнопки «Send test mail», которая размещена под всеми настройками почты.
Источник
Создание тикет-системы на базе OTRS
В данный момент у компании EFSOL для поддержки клиентов, а также внутренних сервисов используется платная тикет-система, которую мы получаем по модели SaaS. Со стороны функционала претензий к системе нет. Однако, мы задумались о другом решении для организации тикет-системы из-за экономических факторов:
- Количество сотрудников нашей компании постоянно увеличивается и, соответственно, ежемесячные затраты растут.
- У нас есть свой хостинг (облачные серверы и техническая поддержка) — нет проблем размещать сервис у себя, а не пользоваться сторонним облачным решением.
Выбор решения для тикет-системы
Поиск тикет-системы производился, используя следующие требования:
- Продукт должен быть на базе свободного ПО
- Установка должна выполняться на бесплатную ОС
- Система должна соответствовать принципам ITSM
- Система должна иметь широкие возможности по кастомизации и доработке.
- Постановка заявок стандартными способами : Email, телефон, web-интерфейс пользователя.
- Должна быть возможность формировать необходимые отчеты:
- отчет по заявкам: количество, %просрочки, %инцидентов, статистика по клиентам и исполнителям)
- отчет по оценке заявок
- отчет по количеству возвращенных заявок
Были обозначены цели, которые планируем достичь с использованием новой тикет-системы:
- Перевести все взаимодействие внутренних служб ( план «Минимум»)
- Перевести текущих клиентов и использовать для новых (план «Максимум»).
Из всех решений, которые были рассмотрены, наиболее подходящим показался OTRS.
В таблице 1 ниже приведены наиболее распространенные термины которые используются при работе с системой.
Таблица 1 — Термины, используемые при работе с тикет-системой
| № | Термин | Обозначение |
| 1 | Заявка (Тикет) | Любое обращение в службу технической поддержки. |
| 2 | Инцидент | Незапланированное прерывание сервиса или снижение качества его работы. Например выход из строя оборудования, медленная работа сервисов. |
| 3 | Запрос на обслуживание | Запрос от пользователя для предоставления консультации или выполнения плановых действий, например, установка нового ПО или оборудования. |
| 4 | Клиент | Внешний пользователь системы. Тот, кто формирует заявку. |
| 5 | Агент | Внутренний пользователь системы. Тот, кто заявку обрабатывает |
| 6 | Очередь | Место расположения заявки, сущность, которая позволяет разделить общий массив заявок. |
| 7 | Каталог услуг | База данных или документ, который содержит перечень услуг, предоставляемых клиенту. |
| 8 | SLA | Соглашение об уровне услуг. Соглашение, в котором регламентированы сроки решения заявок в зависимости от услуги, типа заявки и ее приоритета. |
| 9 | Блокировка заявки | Агент, когда принимает заявку к выполнению, становится ее владельцем и, таким образом, блокирует заявку. Заблокированная заявка не видна другим агентам очереди и они не могут ее закрыть. |
Обзор OTRS
Рассмотрим функционал системы, который можно получить сразу после установки и базовой настройки:
- Заведение клиентов, группировка их по компаниям.
- Заведение агентов , группировка их по группам — это могут быть группы или линии поддержки.
- Создание каталога услуг.
- Создание очередей. К разным очередям можно предоставить разные доступы и разные оповещения.
- Регистрация заявок доступна 3-мя способами:
- По почте. Письмо с почты автоматически преобразуется в заявку в определенной очереди. Можно настроить прием заявок в разные очереди с разных ящиков.
Рисунок 1 — Интерфейс настройки почты для приема заявок
Через Web-интерфейс. Клиент оставляет заявку через Web-сайт. При постановке заявки через Web-интерфейс, есть возможность выбрать услугу, а также срочность заявки.
Рисунок 2 — Интерфейс пользователя OTRS
Рисунок 3 — Настройка SLA
Далее необходимо сопоставить приоритет заявки с ее типом и SLA. В таблице ниже настраивается матрица какой ID SLA будет выбран при определенном ID типа заявки и приоритете.
Рисунок 4 — Сопоставление SLA, типа заявки и приоритета
- Перечень открытых заявок.
- Перечень закрытых заявок.
- Перечень заявок созданных за последний месяц.
- Новые заявки.
- Обзор изменения статусов заявок за месяц.
- Обзор всех заявок в системе.
Рисунок 5 — Интерфейс обработки заявки оператором
Оператор проводит классификацию заявки указывая приоритет и сервис. Далее может закрыть ее сам или же передать другому оператору или в другую очередь.
Рисунок 6 — Интерфейс классификации заявки
Настройка системы OTRS
Для реализации первого этапа установили систему и начали ее настройку.
Базовая настройка
После того как система была установлена, ее нужно было настроить.
- Создан и подключен к системе почтовый ящик для приема писем с заявками.
- Создано и подключено DNS имя для использования Web-интерфейса.
- Заведены сотрудники компании «агенты» и сгруппированы по отделам. Клиентов не создавали — так как система будет пока служить для постановки заявок между сотрудниками.
- Созданы 2 очереди техподдержки: 1-я и 2-я линия поддержки.
- Созданы 2 очереди техподдержки: 1-я и 2-я линия поддержки.
- Вставили логотип и русифицировали интерфейс и уведомления.
Рисунок 7 — Страница входа в OTRS
В результате получился инструмент, позволяющий использовать такой функционал:
- Отправить заявку письмом или же через web-интерфейс.
- Заявка регистрируется, ей присваивается номер, передается между исполнителями, закрывается.
- Автору заявки приходят уведомления о состоянии заявки, также автор может прикрепить свой комментарий через личный кабинет или ответив на письмо.
Базовая кастомизация
Для соответствия системы потребностям компании выполнили небольшую кастомизацию:
Настроен SLA. Регламентное время решения заявки вычисляется в зависимости от типа заявки (запрос на обслуживание или инцидент), приоритета и сервиса. Настроено рабочее время. Также выполнен расчет приоритета в зависимости от срочности и критичности заявки. Изначально в заявках есть только параметр приоритета.
Настроено ограничение на прием заявок. Настроили прием заявок только с почты клиентов или агентов. С адресов, не зарегистрированных в системе, заявки не принимаются, в ответ отправляется уведомление о незарегистрированном адресе.
Реализован механизм оценки заявок. При закрытии заявки исполнителем, автор получает уведомление с просьбой принять выполнение заявки и поставить оценку. Если у автора есть замечания, он отвечает на данное письмо и заявка возобновляется в работу, а его ответ крепиться комментарием к заявке.
Рисунок 8 — Уведомление на почту о закрытой заявке
Рисунок 9 — Результат оценки заявки
Реализован механизм подсчета возвращенных заявок. Количество возвращенных заявок и количество раз, которое они были возвращены является очень важным показателем качества работы ИТ-службы, поэтому в форму заявки был добавлен счетчик возобновления заявок.
Отчеты
Для оценки качества работы ИТ-подразделения пока решили использовать 3 отчета:
Отчет по заявкам. Показывает количество заявок за определенный период, в том числе количество и процент просроченных заявок — наиболее важный параметр. Также предоставляется информация по количеству и процентному соотношению типов заявок и состояний.
Рисунок 10 — Пример Отчета по заявкам
Отчет по оценке заявок. Показывает среднюю оценку по всем заявкам за выбранный период и по каждому типу в отдельности.
Рисунок 11 — Пример Отчета по оценке заявок
Отчет «Возвращенные заявки». Показывает количество возвращенных заявок в абсолютном и процентном соотношении и показывает сколько раз была возвращена конкретно каждая заявка.
Рисунок 12 — Пример Отчета «Возвращенные заявки»
Во всех отчетах настроен интервал диапазона дат — текущее число. Отчеты можно формировать по отдельному клиенту, исполнителю или очереди.
Рисунок 13 — Интерфейс для формирования отчетов на примере Отчета по заявкам
Планы по дальнейшему развитию
В данный момент система успешно запущена для работы внутренней службы. В планах поработать несколько недель и составить список новых пожеланий к системе, которые всплывут во время боевой эксплуатации системы. Далее будем решать, какие из них действительно нужны и будем их реализовывать.
В будущем планируется реализовать следующий функционал:
- Создать веб-форму для отчетов. В данный момент отчеты выгружаются сразу в файл. Было бы удобнее чтобы формировалась форма в браузере, а уже потом, если необходима выгрузка, выгружать ее в необходимый формат.
- Сделать более презентабельную форму формирования отчетов.
- Реализовать механизм «Замораживания заявок». Сделать возможность, когда исполнитель смог бы приостановить выполнение заявки, указав причину. При этом SLA замораживается. Актуально для заявок, к решению которых невозможно приступить в ближайшее время, например, автор заявки просит подключить ему компьютер, который будет куплен только через 3 дня.
- Создание красивого клиентского интерфейса.
- Механизм согласования заявок. Необходимо создать механизм, когда определенный тип заявок не может быть выполнен исполнителем без согласования ответственного сотрудника. Очень актуально для заявок связанных с безопасностью и предоставлению доступа к данным. Такие заявки ставят сотрудники клиента, но согласовывает их выполнение служба безопасности клиента или руководитель.
Вывод
OTRS — это очень перспективная система. Основным ее преимуществом, кроме того, что она бесплатная, является большая степень гибкости. Отсюда появляется и самый большой недостаток системы — ее нужно полностью настраивать и кастомизировать под свои задачи. Без этого удастся получить только базовый функционал. Очень мало компаний используют OTRS в базовом варианте, а некоторые создают собственные платные продукты на базе OTRS или же делают платные модули, отчеты и прочее.
Мы запустили готовую тикет-систему в облаке и предлагаем её в аренду.
EFSOL Системная интеграция. Консалтинг
Источник