Как приложения SaaS / Mult-Tenancy реализуют уведомления по электронной почте (отправка и получение)?

Учитывая мультитенантное приложение, как поставщики реализуют уведомления по электронной почте с точки зрения настройки и программирования учетной записи электронной почты:

Отправка электронных писем может происходить из общей учетной записи: например, [email protected] или [email protected], это кажется разумным, учитывая, что адреса для ответов и ссылки могут содержаться в содержимом электронной почты.

Получение электронных писем. Например, как приложение будет получать электронную почту; для создания заявок в службу поддержки или назначения комментариев по электронной почте к проекту / задаче. Я видел идентификаторы в теме и некоторые ответы на адреса, содержащие имя учетной записи, например: [email protected]

Я понимаю, что можно программно подключаться к серверу pop3, получать электронные письма и искать идентификаторы с темой, но есть ли способ настроить и получать электронную почту на одну учетную запись pop3 с нескольких подчиненных узлов укажите адреса электронной почты (не уверен в терминологии), например: [email protected] или [email protected] и проверьте Имя учетной записи из адреса? (аналогично проверке поддоменов по URL)

Какие-либо практики, опыт, комментарии или предложения?

(не уверен, что это актуально, но с использованием С # asp.net-mvc и служб и т.д.)


email multi-tenant pop3 saas
person Mark Redman    schedule 25.04.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

Для входящих писем мы используем FogBugz (от создателей Stack Overflow) для отслеживания обращений. Он принимает новые заявки по электронной почте (например, [email protected]). Билеты создаются автоматически из электронной почты. Моя единственная жалоба заключается в том, что клиенту необходимо проверить неясную ссылку для получения обновлений кейсов (нет веб-портала «Мои дела», но, возможно, это появится в следующей версии FogBugz).

У нас есть настраиваемое поле в FogBugz, чтобы указать клиента, от которого принадлежит билет. Теоретически мы могли бы написать плагин для FogBugz, который автоматически назначает это, используя домен отправителя, но я думаю, что CSR еще не жаловались достаточно громко :-)

person Eric J.    schedule 25.04.2010
comment
Интересно, спасибо. Я только что реализовал SmarterTrack для конкретного проекта, и он работает аналогичным образом. В админке вы настраиваете данные SMTP для отправки, а в pop3 указываете вашу собственную учетную запись поддержки / случаев и т. Д. Это здорово и легко реализуется / настраивается для технарей, которые надеются найти более удобное решение? - person Mark Redman; 25.04.2010
comment
@Mark: Забавно, что мы только что ответили на вопросы друг друга :-) SmartTracker, кажется (судя по домашней странице), сосредоточен только на стороне службы поддержки. FogBugz включает в себя управление внутренними рабочими элементами в дополнение к исправлению ошибок клиентов для команды разработчиков (хотя SmartTracker, вероятно, более полнофункциональный на стороне службы поддержки). У нас есть информация об электронной почте, привязанная к нашему экрану учетной записи, к которому может получить доступ клиент или CSR. Никакой дополнительной настройки не требуется (у нас есть серверный компонент, который считывает объект Account, чтобы получить адрес электронной почты для уведомления). - person Eric J.; 25.04.2010
comment
:-) Я тоже это заметил ... Да, SmarterTrack - это чисто справочная служба ... Я все равно могу взглянуть на FogBugz, слышал хорошие отзывы .. - person Mark Redman; 25.04.2010

arrow_upward
2
arrow_downward

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

Для наших собственных исходящих потребностей самый простой способ - использовать API отправки электронной почты. Не беспокойтесь об отправке SMTP самостоятельно. Мы используем Amazon SES, а также пробовали Sendgrid, что дало нам дополнительные преимущества, такие как статус доставки и анализ электронной почты.

Есть два способа обработки нескольких учетных записей для получения всех адресов электронной почты. Если ваша целевая система может различать разных клиентов и назначать задачи правильным представителям на основе содержимого / отправителя, попросите всех своих клиентов отправить электронное письмо на адрес [email protected].

Как вы правильно сказали, вы также можете создать адреса электронной почты *[email protected]* и использовать разные учетные записи в любом решении CRM / поддержки, используемом для управления этими электронными письмами.

Другой подход заключается в том, чтобы ваши клиенты отправляли вам электронное письмо на адрес [email protected], а вы используете систему на основе правил (например, muHive) для пересылки этих писем соответствующим руководителям учетной записи на основе клиента / учетной записи. кто отправил почту.

person Ritesh M Nayak    schedule 23.08.2013