Ну, чё в этот раз быстро загрузилась страничка? Что там произошло, и не знаю.

Ну, чё в этот раз быстро загрузилась страничка? Что там произошло, и не знаю.

Слушай, вопрос у нас вроде простой: сервис по записи голосовых сообщений. Но я, когда смотрю в мониторинге системы Apple, по-моему, эта страничка у нас занимает - она вот сейчас 370 мегабайт, до этого она до 800 мегабайт доходило. Я думаю, как-то можно оптимизировать, вроде обычная HTML-страница, которая с сервака подгружает текст. Ну, по сути, большие текстовые истории. Я даже не думаю, что у нас здесь много файлов каких-то хранится голосовых. Все же где-то на серваке. Как мы можем сделать так, чтобы эта страница сильно легче была? Чтобы она грузилась быстрее на мобильном интернете и везде-везде? Что нам стоит изменить? Потому что меня бесит, когда вроде простой код мы написали, а оно много весит.

Слушай, вопрос у нас вроде простой: сервис по записи голосовых сообщений. Но я, когда смотрю в мониторинге системы Apple, по-моему, эта страничка у нас занимает - она вот сейчас 370 мегабайт, до этого она до 800 мегабайт доходило. Я думаю, как-то можно оптимизировать, вроде обычная HTML-страница, которая с сервака подгружает текст. Ну, по сути, большие текстовые истории. Я даже не думаю, что у нас здесь много файлов каких-то хранится голосовых. Все же где-то на серваке. Как мы можем сделать так, чтобы эта страница сильно легче была? Чтобы она грузилась быстрее на мобильном интернете и везде-везде? Что нам стоит изменить? Потому что меня бесит, когда вроде простой код мы написали, а оно много весит.

Так, вопрос мне интересно, почему интересно? АМО СРМ приняли решение переписки с клиентами в мессенджерах объединять в некие беседы, чтобы значило беседа. Беседа нужно просто для отображения в интерфейсе, когда мы заходим в карточку контакт или в карточку сделки, что у нас есть там e-mail какой-нибудь, полученный от клиента, как целая карточка или вот какая-то беседа, например, потому что очевидно, что весь чат подгрузить можно с клиентом, но нужно ли, имеет ли это смысл? И как вообще люди по природе своей относятся к чатам в телеграме или в мессенджерах? Ведь что у нас есть, у нас есть телефонный звонок, это какая-то единица смысла, там есть некая сценарий продаж, выявление потребности, connect, вопросы, единица смысла определенная. Часто все люди одним емейлом общаются, а вот переписка в телеграме, это не просто сообщение, сообщения, сообщения, мы могли, если бы по сообщению читать, мы могли бы весь флоу общение с клиентом засрать в своем интерфейсе. Поэтому очевидно, есть какое-то объединение на беседы, но что считать принципом обработки беседы, и все ли так действуют, или беседы, это то, что в течение суток произошло, как его цап предлагает, например, если сутки без действия, значит беседа закончилась. Почему такой параметр выбран? А ведь в течение суток можно успеть два раза пообщаться, в начале одного дня и в конце другого дня, люди размышления есть на этот счет, как эту структуру организовать?

Так, вопрос мне интересно, почему интересно? АМО СРМ приняли решение переписки с клиентами в мессенджерах объединять в некие беседы, чтобы значило беседа. Беседа нужно просто для отображения в интерфейсе, когда мы заходим в карточку контакт или в карточку сделки, что у нас есть там e-mail какой-нибудь, полученный от клиента, как целая карточка или вот какая-то беседа, например, потому что очевидно, что весь чат подгрузить можно с клиентом, но нужно ли, имеет ли это смысл? И как вообще люди по природе своей относятся к чатам в телеграме или в мессенджерах? Ведь что у нас есть, у нас есть телефонный звонок, это какая-то единица смысла, там есть некая сценарий продаж, выявление потребности, connect, вопросы, единица смысла определенная. Часто все люди одним емейлом общаются, а вот переписка в телеграме, это не просто сообщение, сообщения, сообщения, мы могли, если бы по сообщению читать, мы могли бы весь флоу общение с клиентом засрать в своем интерфейсе. Поэтому очевидно, есть какое-то объединение на беседы, но что считать принципом обработки беседы, и все ли так действуют, или беседы, это то, что в течение суток произошло, как его цап предлагает, например, если сутки без действия, значит беседа закончилась. Почему такой параметр выбран? А ведь в течение суток можно успеть два раза пообщаться, в начале одного дня и в конце другого дня, люди размышления есть на этот счет, как эту структуру организовать?

Так, я еще хочу проработать такую функцию: смотри, сейчас, когда мы к нам на сервис заходим, у нас есть страница, которая просит авторизацию, это, конечно, здорово. Но вопрос в том, что я уже не с каким своим друзьям дал сервис, и они без авторизации не могут его даже потестировать. Какой бы ты предложил маркетинговый план, как это все корректно сделать? Что я хочу, я хочу, чтобы у нас с тобой изначально был доступ к этому интерфейсу всех желающих, чтобы каждый мог что-то распознать и начать пользоваться. Но вот вопрос: очевидно, все это надо сохранить где-то, в сессиях или карте, короче, нужны видимо какие-то анонимные пользователи для каждого человека. 15, 15, и когда лимит закончен, человеку надо предложить авторизоваться, чтобы иметь возможность сохранить полностью всю историю. А потом еще какие-то тарифные планы, для того, чтобы распознавать больше, и, возможно, какие-то подписки. Так вот, мне сначала интересен интерфейс, чтобы у нас для всех был доступ и была авторизация. И спроектировать это так, чтобы оно было подвязано к некой платежной системе, чтобы можно было за это деньги брать. Им обратно сообщение уже распознанное. А потом в будущем мы прикрутим всякие эмбэддинги и подобные истории, которые помогут нам структурировать заметки и организовывать человеку либо структуру заметок его голосовых, либо какие-то выводы и дайджесты готовить по заметкам. А вообще, следующий план у меня на этот весь интерфейс: CRM apps, CRM, подготовлена или разбита на несколько сообщений, или как-то, и клиент мог бы, и менеджер мог бы упростить себе все задачи, которые связаны с вводом текста, потому что наши клиенты не любят слушать голосовушки, им удобнее текст читать. А еще мы научимся делать расчеты и счета выставлять, у нас будет крутой интерфейс, что мы можем и голосом текст записать, и ассистент может предложить какой-то текст. И вот все, что у нас есть сейчас в заметках, мы любое сообщение можем отредактировать и отправить пользователю после редактирования. Ну, то есть все, что у нас есть сейчас, все, что мы в терминал отправляем, по сути, у нас все то же самое будет для взаимодействия с живыми людьми.

Так, я еще хочу проработать такую функцию: смотри, сейчас, когда мы к нам на сервис заходим, у нас есть страница, которая просит авторизацию, это, конечно, здорово. Но вопрос в том, что я уже не с каким своим друзьям дал сервис, и они без авторизации не могут его даже потестировать. Какой бы ты предложил маркетинговый план, как это все корректно сделать? Что я хочу, я хочу, чтобы у нас с тобой изначально был доступ к этому интерфейсу всех желающих, чтобы каждый мог что-то распознать и начать пользоваться. Но вот вопрос: очевидно, все это надо сохранить где-то, в сессиях или карте, короче, нужны видимо какие-то анонимные пользователи для каждого человека. 15, 15, и когда лимит закончен, человеку надо предложить авторизоваться, чтобы иметь возможность сохранить полностью всю историю. А потом еще какие-то тарифные планы, для того, чтобы распознавать больше, и, возможно, какие-то подписки. Так вот, мне сначала интересен интерфейс, чтобы у нас для всех был доступ и была авторизация. И спроектировать это так, чтобы оно было подвязано к некой платежной системе, чтобы можно было за это деньги брать. Им обратно сообщение уже распознанное. А потом в будущем мы прикрутим всякие эмбэддинги и подобные истории, которые помогут нам структурировать заметки и организовывать человеку либо структуру заметок его голосовых, либо какие-то выводы и дайджесты готовить по заметкам. А вообще, следующий план у меня на этот весь интерфейс: CRM apps, CRM, подготовлена или разбита на несколько сообщений, или как-то, и клиент мог бы, и менеджер мог бы упростить себе все задачи, которые связаны с вводом текста, потому что наши клиенты не любят слушать голосовушки, им удобнее текст читать. А еще мы научимся делать расчеты и счета выставлять, у нас будет крутой интерфейс, что мы можем и голосом текст записать, и ассистент может предложить какой-то текст. И вот все, что у нас есть сейчас в заметках, мы любое сообщение можем отредактировать и отправить пользователю после редактирования. Ну, то есть все, что у нас есть сейчас, все, что мы в терминал отправляем, по сути, у нас все то же самое будет для взаимодействия с живыми людьми.

У меня к тебе есть предложение: давай разработаем интерфейс, некий админский, точно мне доступный, какие-то права должны быть у меня, где я видел бы список всех пользователей, количество заметок или там дата регистрации, либо еще что-то. Короче, надо как минимум дашборд видеть о всех пользователях, которые есть на сервисе. Сколько они ресурсов потребляют, сколько они хранят мегабайт заметок голосовых. Если бы мы за это платили, мы это в соседнем терминале проектируем историю с авторизацией, прайсингом, бесплатными тарифами, бесплатными юзерами, которые без авторизации могут заходить, у которых там не знаю какой-то лимит на 15 минут распознаваний. Какое у тебя предложение есть по структуре таблицы для управления всеми пользователями? В идеале, чтобы на экране телефона поместилось, не Telegram, статистику еще что-то, как Apple это делает, понятно, большие системы управления, на есть какие-то ключевые, наверно, таблицы, которые чаще всего пользуются, плюс формат оплат разные можно привязывать, наверно, оплата это будет тоже целая отдельная структура в базе данных. Пока я не создаем, ну просто подумать, это же и донатом могут быть оплата месячной подписки и разовой расшифровки какой-то. А где для него грань переключения? Когда он готов зарядить новый аккаунт, потерять старые заметки, но не платить, например, 500 рублей в месяц. То есть нужны какие-то короткие, очень простые платежи, видимо, типа СБП или еще что-то. Что много чего поделал, раз там 50 рублей закинул, 50 рублей ни для кого не проблема, но если 10 раз заместить 50 рублей, то это уже примерно сопоставимо подписке. Что бы ты предложил, исходя из стоимости API, которая у нас есть на Гроке, стоимости одной заметки и какой-то ценности для людей?

У меня к тебе есть предложение: давай разработаем интерфейс, некий админский, точно мне доступный, какие-то права должны быть у меня, где я видел бы список всех пользователей, количество заметок или там дата регистрации, либо еще что-то. Короче, надо как минимум дашборд видеть о всех пользователях, которые есть на сервисе. Сколько они ресурсов потребляют, сколько они хранят мегабайт заметок голосовых. Если бы мы за это платили, мы это в соседнем терминале проектируем историю с авторизацией, прайсингом, бесплатными тарифами, бесплатными юзерами, которые без авторизации могут заходить, у которых там не знаю какой-то лимит на 15 минут распознаваний. Какое у тебя предложение есть по структуре таблицы для управления всеми пользователями? В идеале, чтобы на экране телефона поместилось, не Telegram, статистику еще что-то, как Apple это делает, понятно, большие системы управления, на есть какие-то ключевые, наверно, таблицы, которые чаще всего пользуются, плюс формат оплат разные можно привязывать, наверно, оплата это будет тоже целая отдельная структура в базе данных. Пока я не создаем, ну просто подумать, это же и донатом могут быть оплата месячной подписки и разовой расшифровки какой-то. А где для него грань переключения? Когда он готов зарядить новый аккаунт, потерять старые заметки, но не платить, например, 500 рублей в месяц. То есть нужны какие-то короткие, очень простые платежи, видимо, типа СБП или еще что-то. Что много чего поделал, раз там 50 рублей закинул, 50 рублей ни для кого не проблема, но если 10 раз заместить 50 рублей, то это уже примерно сопоставимо подписке. Что бы ты предложил, исходя из стоимости API, которая у нас есть на Гроке, стоимости одной заметки и какой-то ценности для людей?