Ту коллеги много путей описали. Я знаю только один путь. Взять например eMotion(Мультифон), завернуть мобильные звонки на облачную АТС с записью, оттуда копировать записи в облако, и вызов дальше закидывать на мобилку.
Друзья, Записать вызов проблемы никогда не было и нет.
Статья о том, как сделать хранилище транскрибированных записей. Чтобы искать в них текстом, а не прослушивать их.
Мне очень ценны ваши комментарии, но давайте не будет их оставлять про то как записать свой вызов. История совсем не про это. Спасибо.
Спасибо. Вот спрашивается почему бы Мегафону не добавить транскрибирование?
На базе Experience Portal кстати можно и письма получать, транскрибировать и отсылать результат дальше. Только сейчас поменялись правила лицензирования. К сожалению. Отсылать можно бесплатно. А обрабатывать входящие нужен коннектор достаточно дорогой.
Спасибо за комментарий. Тут конечно история для телеком гиков. Но на самом деле каждый, кому данная история интересна, может погуглить и вникнуть. В целом это и есть история про обычных людей и обычные телефоны. Ну естественно для тех кто увлечен. И по моим фразам и по фразам комментаторов можно понять, что для мобильных телефонов есть сложности. Хотя решаемые. Данный сервис можно запустить и на офисном телефоне и на домашнем телефоне. И на домашнем все еще интереснее. Все это можно запустить на 8Gb памяти. Вообще телеком отрасль в России переживает кризис кадров. Молодежи мало и ей почему-то не интересно. Хотя тематика очень интересная. Ей интересно в Сбербанке плющиться почему-то. Наверное потому, что им кажется что там деньги ближе. Хотя это не так.
Еще раз спасибо за комментарий. Но если хотя бы несколько человек заинтересуются словом Астериск и почему это наипростейший путь, то я считаю, что статью я написал не зря. Спасибо.
На 30000 Avaya в нашей стране станций нет. Самая большая на 22 тысячи. Следующая 15 тысяч.
Средняя станция около 1к-2к. Из них у части людей только есть телеграмм. А уж сколько процент неотвеченных?
Даже если предел числа сообщений будет достигнут, то легко завести второго бота и переадресацию с половины пользователей сделать на одного бота, а вторую половину на другого. При использовании Configurable Variables даже приложение пересобирать не нужно и деплоить на сервере приложений не нужно.
Ну для объявленых задач это все подходит. Уведомление о пропущенном вызове чаще раза в секунд 30 не пройдет. Уведомление о превышении очереди в КЦ тоже чаще чем в минут в 10 не нужно. Ну тут кстати вы правы. Приведенное приложение не нормирует число вызовов API в минуту. И если вызовы идут потоком, то казус неприменно возникнет. Надо в приложении на IVR делать контроль числа полученных эвентов и не посылать уведомление супервизору чаще чем в Х минут.
Как общий комментарий. Данное описание еще не покрывает следующую сопутствующую задачу:
Автоматизация просмотра регистрация и апдейт данной информацией некой базы.
Ну чтобы пользователь писал боту /register XXXX. Некое приложение должно извлечь данный номер и положить его в базу, связав с идентификатором пользователя. Далее основное приложение при получении вызова на DNIS XXXX должно просканить базу и всем пользователям, связанным с номером ХХХХ выслать соответствующее сообщение.
Внимательно изучил вот это. Противоречий не нашел. Если есть сомнения — озвучьте pls. Обсудим. Вообще данное решение является прототипом во-первых. А во-вторых данная задача не предусматривает огромной нагрузки и объема. Необходимо лишь быстро уведомить пользователя не заморачиваясь с операционкой его мобильного или десктопного клиента.
Давеча наблюдал как на проходной в бизнес-центр с проходом через вертящуюся штуку с валидатором народ проходит. Кто носит карточку на шее и пригибается к валидатору, кто задним карманом в нее тычется. Кто сумку пытается обтереть об валидатор. И народ говорит проблемы нет. Посмотрите на такой валидатор 5 минут и все становится ясно. В случае же с телефоном ничего прижимать и доставать и обтирать не надо. Подошел, толкнул рамку, телефон считался через маячок, отвалидировался и вперед.
Ну развивается же NFC или Apple Pay. Это по сути то-же самое, что и предложенная мной идея. И почему-то она активно развивается, хотя по сути та-же самая проблема. Достать для оплаты телефон или достать карточку из кошелька. Достать для открытия двери телефон или карточку.
Но мне персонально эта идея даже больше нравится, если дверь открывать с часов.
Или автоматически открывающаяся при приближении авторизованного телефона.
Но часов под Android у меня под рукой не было. :-( А то бы сделал.
Согласен, нашел эту информацию позже. По неизвестной причине она не попалась мне на глаза в момент работы с маячками, хотя я перелопатил изрядно информации в попытках достучаться до них. Ну будем считать «не свезло». Как-то эмпирически получил доступ и слава богу.
На шею вешают обычно карточку внутри офиса. А в офисное здание и вход? Конечно теоретически я вижу в офисах людей с карточками на шнурках, но ни в одном моем офисе таких не было. А знаком я более чем с 1000 людей, пользующихся карточками. По-видимому это были какие-то другие карточки.
Ну тут вопрос то этот эмпирический. Кому как удобно. Вот я например, работая в офисах с такими дверьми уже более 15 лет, не держу карточку отдельно. Иначе ее просто забыть или потерять. У меня персонально карточка лежит в кошельке. Потому что он всегда со мной. В зависимости от его наполненности :-) его бывает не просто достать из кармана. А телефон всегда ближе. Работа у меня требует частых переговоров и это мой инструмент.
Поэтому я не готов с вами согласиться. Мне телефон достать быстрее чем кошелек с карточкой. Хотя у кого-то наверное карточка лежит в чехле телефона и это вообще равноценно.
В данном решении несколько аспектов. 1- удобство пользования. По поводу вытаскивания карточки и телефона вопрос эмпирический. Я с этим согласен. При условии носимой электроники — однозначно удобнее. Но не у каждого она есть. При условии расположения двери в конце коридора и возможности разрешения открытия двери без нажатия кнопки — тоже удобнее.
2 аспект — удобство обслуживания сети маячков вместо сети считывателей. Это конечно вопрос IT, а не пользователей.
Понимаете, тут же важен сам факт верификации двери и телефона. Можно же сделать реализацию когда кнопка на телефоне будет нажиматься сама. Т.е. вы подходите к двери и она открывается, верифицируясь по телефону и маячку. Однако а как быть если вы просто проходите мимо? Ну то есть должен быть факт принятия решения.
Относительно карточки и телефона. Еще неизвестно что быстрее достается и в любом случае это практически равноценно. Также можно переносить кнопку принятия решения открытия двери на носимую электронику. ну то есть например на часы. Тогда открытие двери будет еще проще.
Ну около 5-10 секунд. В целом быстро. Учитывая, что телефон начинает ее искать метров за 30, то при подходе к двери и даже раньше он его всегда находит. Можно конечно предположить гипотетическую ситуацию, когда дверь находится сразу при открытии дверей лифта за сплошной бетонной стеной с заземленной экранировкой. Тогда да, может возникнуть ситуация, когда надо будет ждать. Я поделал эксперименты со своей дверью, маячок за стеной из пеноблоков исправно находился метров за 15 до двери.
На самом деле задачей не стояло проанализировать результаты работы движка распознавания. Это как бы уже над-сервис.
Задачей стояло упростить и сделать более комфортным взаимодействие с старой, я бы даже сказал древней, корпоративной системой.
А вот следующий шаг уже будет улучшение движка распознавания. Но это как-бы работа вендора.
Статья о том, как сделать хранилище транскрибированных записей. Чтобы искать в них текстом, а не прослушивать их.
Мне очень ценны ваши комментарии, но давайте не будет их оставлять про то как записать свой вызов. История совсем не про это. Спасибо.
На базе Experience Portal кстати можно и письма получать, транскрибировать и отсылать результат дальше. Только сейчас поменялись правила лицензирования. К сожалению. Отсылать можно бесплатно. А обрабатывать входящие нужен коннектор достаточно дорогой.
Еще раз спасибо за комментарий. Но если хотя бы несколько человек заинтересуются словом Астериск и почему это наипростейший путь, то я считаю, что статью я написал не зря. Спасибо.
Средняя станция около 1к-2к. Из них у части людей только есть телеграмм. А уж сколько процент неотвеченных?
Даже если предел числа сообщений будет достигнут, то легко завести второго бота и переадресацию с половины пользователей сделать на одного бота, а вторую половину на другого. При использовании Configurable Variables даже приложение пересобирать не нужно и деплоить на сервере приложений не нужно.
Автоматизация просмотра регистрация и апдейт данной информацией некой базы.
Ну чтобы пользователь писал боту /register XXXX. Некое приложение должно извлечь данный номер и положить его в базу, связав с идентификатором пользователя. Далее основное приложение при получении вызова на DNIS XXXX должно просканить базу и всем пользователям, связанным с номером ХХХХ выслать соответствующее сообщение.
Но мне персонально эта идея даже больше нравится, если дверь открывать с часов.
Или автоматически открывающаяся при приближении авторизованного телефона.
Но часов под Android у меня под рукой не было. :-( А то бы сделал.
Нужно подойти и открыть дверь. Все.
Поэтому я не готов с вами согласиться. Мне телефон достать быстрее чем кошелек с карточкой. Хотя у кого-то наверное карточка лежит в чехле телефона и это вообще равноценно.
В данном решении несколько аспектов. 1- удобство пользования. По поводу вытаскивания карточки и телефона вопрос эмпирический. Я с этим согласен. При условии носимой электроники — однозначно удобнее. Но не у каждого она есть. При условии расположения двери в конце коридора и возможности разрешения открытия двери без нажатия кнопки — тоже удобнее.
2 аспект — удобство обслуживания сети маячков вместо сети считывателей. Это конечно вопрос IT, а не пользователей.
Относительно карточки и телефона. Еще неизвестно что быстрее достается и в любом случае это практически равноценно. Также можно переносить кнопку принятия решения открытия двери на носимую электронику. ну то есть например на часы. Тогда открытие двери будет еще проще.
Задачей стояло упростить и сделать более комфортным взаимодействие с старой, я бы даже сказал древней, корпоративной системой.
А вот следующий шаг уже будет улучшение движка распознавания. Но это как-бы работа вендора.