Года 2 назад, а судя по посту в ВК - 1 год с копейками:

... закрылся проект Sale Script Gift. Бесплатный конструктор скриптов продаж в течение месяца или двух свернул свои паруса и умер, оставив за собой образ и инструкцию по развёртыванию VM.

Я бы не акцентировал на этом моменте внимание, если бы не тот факт, что на момент закрытия сервиса у нас в личном кабинете было от 60 до 80 скриптов продаж различной сложности и различного объёма. Экспорта в Sale Script Gift предусмотрено не было - голый JSON и понимание того, что данные терять нельзя, иначе будет грустно всем.

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

Выхода на тот момент не было другого, как оперативно поднимать что-то своё и одновременно конвертировать существующий формат хранения сценариев в другой. Да, был всё-таки вариант поднять ту же VM, которую парни оставили в паблике, но на тот момент у нас уже была инфраструктура на PHP / MySQL и начинать разворачивать что-то на Python / Java желания не было от слова совсем.

Героическими усилиями 1 человека за 1 день и 1 ночь был поднят самый ужасный по удобству, но спасительный редактор скриптов продаж.

За несколько дней команда перенесла в ручном режиме скрипты на новый формат и мы на некоторое время вздохнули с облегчением - платформа наша, расходы - нулевые (поддержку и доработки опускаем), ограничений - нет, риски лишиться данных - нулевые. Мы в безопасности.

На тот момент у нас была собственная платформа для ведения аутсорсинга продаж через холодные звонки - Deep Sales Platform. Она и сейчас есть, но сильно отличается от первой версии и от самого Скорозвона (будете смеяться, но на тот момент и на него у нас денег не было - только своими силами что-то вытаскивали из инструментов).

В ней есть такие вещи как:
 

• Автоматизированные финансовые начисления за звонки операторам и за достижения целей по воронке продаж;
• Возможность строить неограниченное количество воронок продаж;
• Загружать большие объёмы баз контактов и обзванивать их в полуавтоматическом режиме;
• Разрабатывать скрипты продаж;
• Управлять командой сотрудников;
• Слушать аудио-записи в режиме реального времени;
• и прочее и прочее и прочее.

Пару скриншотов для любопытных:

Deep Sales Platform: Детализация по звонкам​

Первый продукт работает до сих пор и мы его активно используем, но вот развивать перестали из-за стека... В какой-то момент PHP (Symfony) + MySQL стал болью для поддержки. В планах стоит задача перенести на другой стек и возобновить доработки, потому что видим потребность в таком решение от малого бизнеса, который к нам обращается или небольших колл-центров, которые хотят запуститься.

В этой платформе у нас и начал зарождаться второй продукт - конструктор скриптов продаж.

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

Рывка сразу не последовало - не успели восстановиться, поэтому начали дорабатывать конструктор внутри платформы и смотреть, как же на это всё реагируют клиенты, руководители команд продаж и сами операторы. До июня-июля 2019 года мы всё пилили и пилили, как платформу Deep Sales Platform, так и конструктор скриптов продаж.

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

После самой серии видео-роликов появляется и сравнительная табличка с самыми примечательными конкурентами.

Мы двигались в правильном направлении и уже прошли часть граблей, которые просматривались у некоторых конкурентов.

Конструктор было проще выносить из DSP, как отдельного проекта, по той простой причине, что весь frontend в Deep Sales Platform и Telly построен на Vue + Vuetify на компонентной основе, а это значило, что мы себе сократили время на публикацию готового решения до минимума.

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

Начали штурмовать и вспоминать все "боли", которые за 3-4 года случались с нами и... нашли такую (как в итоге оказалось, одна боль повлекла за собой другую боль!) - вынести магазин-скриптов на публичную сторону и дать основную роль, а конструктору скриптов продаж дать второстепенную роль, как вспомогательному инструменту.

Сработало ли это? Пока не знаем - тестируем.

Пора посмотреть на сам редактор. Регистрация в один клик.

Сразу хочу предупредить тех, кто будет читать эту статью через месяца 2-3 - мы планируем обновить интерфейс личного кабинета, но настолько сильно, чтобы вы его не узнали, он не изменится.

По-умолчанию у вас будет пустой экран, а у меня пока там один скрипт продаж:

Каждый скрипт продаж можно:

• Расшарить (например, вот так);
• Отредактировать (мета-информацию);
• Дублировать;
• Удалить.

Публичных ссылок можно делать сколько угодно:

Если ссылку потом удалить, то и доступ к сценарию будет невозможен.

Так выглядит сценарий в режиме чтения:

С левой стороны - реплики менеджера и основная структура диалога, по центру - основной блок с вариантами ответа клиента, с правой стороны - вопросы и возражения.

Вот так выглядит скрипт продаж в режиме редактирования:

Так как весь конструктор - SPA, то забудьте про обновления страниц - всё настолько плавно и гладко работает, что похоже на нативное приложение.

Вся доска в Trello в задачах и детализациях, поэтому если вы поняли, что инструмент вам нравится и вы хотите его использовать, но чувствуете, что наличие чего-то сделало бы ваш процесс работы лучше / эффективнее / результативнее в нём, то просто напишите мне по контактам в конце поста и мы обсудим детали.

Боль. Боль. Боль.

Не всё так страшно, но некоторые моменты мы уловили только спустя 7 дней после первых индексаций страниц Яндексом и Google.

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

Заголовок не был бы заголовком, если бы не содержал ответа - SEO и поисковые системы со своей механикой индексирования.

Но давайте вернёмся к SPA и первой проблеме с которой я столкнулся - индексирование страниц, содержимое которых генерируется JS после загрузки.

Яндекс... кошмар (с 2015 года, поправьте, если ошибусь, Яндекс предлагает дублировать контент с передачей специального параметра и не поддерживает индексацию JS-контента). Google... не проиндексировал (несмотря на то, что индексацию JS-контента поддерживает), хотя Google Search Console показала, что страница отдаётся полностью с нужным содержимым.

Вот, как выглядит страница публичного скрипта продаж в магазине и она состоит из:
 

• Заголовка;
• Описания;
• Предпросмотра скрипта;
• Тегов.

Ничего из этого поисковики не подхватывали, а значит в поиск не добавляли, а значит идея глубинной индексации по тегам была на грани провала.

Первым шагом стало генерирование заголовка (title, meta) и описания (description, meta) на стороне сервера с помощью PHP (дальше вы сильно будете смеяться, когда узнаете на каком стеке был и есть сам конструктор).

Тестируем.

Ура! Подхватывает!

Но радость в одной части реализации была омрачена печалью в другой части реализации.

Перед запуском у меня была гипотеза, что Яндекс и Google следующие URL будут воспринимать по-разному и считать уникальными:
 

• https://telly.pw/store?q=банк
• https://telly.pw/store?q=медицина
• https://telly.pw/store?q=ИТ
   

Но после добавления в индексы через несколько дней, Яндекс и Google начали помечать страницы дубликатами и исключать из поиска.

Тут я был некоторое время в ступоре, но потом быстро осознал, что мне надо перевести URL в такой вид:
 

• https://telly.pw/store/search:банк
• https://telly.pw/store/search:ИТ
• https://telly.pw/store/search:медицина
   

Сказано - сделано. Изменения сработали.

На этом мои преключения не закончились, но остальные детали реализации связаны с технологическим стеком. О нём поговорим в следующем блоке.

Наша платформа Deep Sales Platform изначально разрабатывалась на PHP + MySQL. 3 года назад делалась на коленке, как решение, которое впервые спасло бизнес от гибели. В качестве спасительного круга - Symfony.

Развитие платформы сильно повлияло на дальнейший мой выбор инструментов и архитектуру решения.

Если на начальном этапе развития проекта Deep Sales Platform был на Symfony + Twig, то затем стал на Symfony (REST API) + Twig + Vue.js. После нескольких итераций Twig выкинул совсем и остался на стеке Symfony + Vue.js. Следующей итерацией frontend стал полностью SPA + Symfony (REST API) на backend.

Во-первых поддерживать такие решения проще, а во вторых разрабатывать такие решения быстрее. Обкатав единожды такую механику работы небольшая команда, следуя ей, может сильно ускориться в выпуске продуктов запараллелив frontend и backend. У SPA есть свои нюансы с которыми мы столкнулись при разработке, но не было такого, что бы не решилось.

Когда на frontend у тебя JavaScript, а на backend PHP + MySQL, то бывает сложно поддерживать две "модели мышления" и различные подходы к архитектуре приложений, поэтому желание свести всё к чему-то одному логичное.

Я рисковал, сильно рисковал, но решил переносить конструктор на стек Node.js + Vue.js + Vuetify + MongoDB, потому что к тому моменту мы сильно увязли (в хорошем смысле этого слова) в JS и тянуть хвостом Deep Sales Platform на PHP становилось тяжело.

В процессе разработки конструктора на связке PHP + MySQL стали проявляться проблемы MySQL и задачи, которые требовалось решать в конструкторе - они не совсем подходили друг другу.

И если начинать что-то с нуля, так начинать на все 100%... Если раньше был Apache + PHP FPM, то тут я решил - nginx. И я скажу, что ни единой минуты не пожалел о своём выборе, когда дело заходило до конфигурации проксирования запросов на ноду, кеширования и прочего.

Так как изначально мы Deep Sales Platform разворачивали на Selectel, то и Telly было решено там же развернуть. И там и там у нас крутится CentOS 7.0.

По железу сейчас такое:

• vCPU 1 ядро;
• RAM 2 Гб;
• SSD 15 Гб;
   

И по цене - 1 490 руб / мес.

Технологии мы "утрясли" и на ближайшую перспективу их менять не собираемся. Deep Sales Platform, как я уже говорил, тоже будем переводить на новый стек.

Теперь, когда продукт в публичном доступе мне бы хотелось в который раз (для себя, а теперь и публично) заявить - никаких ограничений, никаких запретов, никаких блокировок или любых других условий, которые будут мешать бизнесу использовать наш инструмент и развиваться.

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

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

• shmig@ojok.ru
• shmig@telly.pw
• https://vk.com/ashmig