Эволюция: из маленькой веб-студии в опытного интегратора. Настраиваем бизнес-процессы веб-студии в CRM19.10.2016

Мы быстро поняли, делать простые сайты - невыгодно. Конкуренция возрастала, рынок наводнялся небольшими компаниями. Всё это привело к снижению цен на проекты и падению прибыльности бизнеса. Заказчики становились квалифицированнее. Запросы на создание сайтов дополнялись требованиями «привязать» их к той или иной информационной системе.

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

Наша Студия всегда располагалась в российской «силиконовой долине» - Зеленограде. У нас были сильные программисты, а значит мы могли легко получать и выполнять такие заказы. Было решёно - это наш шанс!

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

Какая гадость эта ваша веб-интеграция

Обеспечить обмен данными между двумя системами несложно. Но наши первые несколько лет работы в новом качестве были болезненными и обошлись недёшево.

Вместо ожидаемых прибылей мы раз за разом теряли деньги, натыкаясь на всё новые сложности, которым наш технический директор дал кодовое названием «подводные камни».

Мы не сдавались, и, словно мышки из анекдота, «кололись, плакали, но упорно продолжали грызть кактус».

Перед тем как приступить

Прежде чем рассказать о процессах, договоримся о терминологии этой статьи.

Для нас, программистов, любая разработка несложных сайтов сводится к такой модели:

Когда нужно создать не просто веб-сайт, а целую систему, где помимо БД сайта задействованы ещё и кассовый аппарат с кассиром, продающим билеты в театр, складская система, предоставляющая сведения об остатках товаров, или платёжный сервис, отвечающий за процессинг банковских карт, мы используем понятие «третья сторона».

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

Шаг 1. Цели и задачи

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

Типичный пример: Сайт должен быть интегрирован с билетной системой ProfTicket.

и стараемся в таких случаях добиться большей однозначности формулировки:

Хороший пример: Покупатели должны иметь возможность выбрать свободные места в зале, оплатить билеты и получить их по электронной почте в офисах продаж или с помощью курьерской доставки. Информация о наличии мест для продажи на конкретные сеансы предоставляется билетной системой ProfTicket.

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

Шаг 2. Бизнес-процессы и протокол взаимодействия

Теперь нужно решить, как системы должны взаимодействовать для выполнения той или иной задачи. Продолжим строить аналогии с билетной системой. Кстати, речь идет о совершенно реальном проекте: в 2013 году мы помогли компании «Дилявер» открыть сервис заказа билетов ShowMart.Ru . Для выполнения бронирования билета необходимо ответить на несколько вопросов:

Какое мероприятие выбрал покупатель?
Какой сеанс (сочетание даты и времени) был выбран?
Какие места (номер сектора, ряд и кресла) были выбраны?
Не были ли проданы эти места другому покупателю ранее?
Не находятся ли данные места в резерве, иными словами, не происходит ли оформление покупки этих мест другим покупателем прямо сейчас?
И так далее...

Любое взаимодействие между системами сводится к структуре «запрос - ответ». Запрос отправляет сторона, которой необходимо получить данные (клиент), а ответ - сторона, у которой эти данные есть (сервер).

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

В какой-то момент нам нужно будет «попросить» одну из систем зарезервировать билеты - проставить отметку, не позволяющую продать эти билеты повторно другому покупателю, а после оформления покупки одна из систем должна будет отправить покупателю письмо-уведомление. Поэтому иногда требуется взаимодействие не на уровне «запрос - ответ», а по формуле «запрос - действие».

Процесс взаимодействия сторон Теперь нам остаётся только зафиксировать, за какие запросы и ответы ответственна каждая из систем. А также указать перечь всех возможных ошибок.

Шаг 3. Регламент принятия решений и медиаторы

Даже в самом простом проекте веб-интеграции принимают участие как минимум три стороны:

Заказчик.
Владелец системы А (например, 1С-программист в штате клиента).
Владелец системы Б (собственно, мы - веб-программисты).

Не будем углубляться в причины и анализ происходящего. Просто зафиксируем как факт: возникновение конфликтов интересов между владельцами двух систем неизбежны. Сложность ситуации зависит от числа участников и уровня их квалификации.

Важно подумать о том, как будут разрешаться спорные ситуации до того, как они появятся. Это непростая тема, но необходимо договориться хотя бы о фундаментальных моментах, например:

Чем стороны будут руководствоваться при принятии решения: быстродействием, вопросами безопасности данных или минимальными изменениями в 1С?
Кто будет ответственной стороной, принимающей последнее решение, в том случае, если владельцы систем не могут договориться между собой?

На первый взгляд кажется, что ответ на последний вопрос очевиден: заказчик - кому же еще принимать окончательные решения? Однако, это не всегда так.

Интеграционные проекты предъявляют высокие требования к техническим знаниям ответственного за решения. Поэтому иногда пальма первенства отдается одному из участников интеграционного процесса, или привлекается независимый эксперт, чей авторитет признается владельцами обеих систем.

Шаг 4. Стандарт и формат обмена данными

Теперь необходимо договориться о том, на основе какого стандарта и каким способом мы будем осуществлять обмен данными между системами.

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

SOAP

SOAP расшифровывается, как Simple Object Access Protocol. Если дословно переводить с английского, то получится «Простой Протокол Доступа к Объектам». Этот протокол действительно является одним из самых простых и часто используемых при построении веб-проектов. SOAP представляет собой протокол обмена структурированными XML-сообщениями.

Для того чтобы системы использовали единый регламент построения запросов и ответов, используются файлы c описанием такого регламента, составленным на основе стандарта WSDL (от англ. Web Service Description Language - Язык Описания Веб-Сервисов).

SOAP является расширением протокола XML-RPC, и это большой плюс протокола. XML широко распространен, и с форматом XML-Schema хотя бы поверхностно знакомо огромное число специалистов.

Этот же факт является и самым большим минусом SOAP. XML - объёмный формат и с ростом количества данных, которыми обмениваются системы, растет количество передаваемого трафика. С ростом последнего увеличивается время, необходимое на обработку запросов и формирование ответов на них. Всё это делает связку WSDL/SOAP практически непригодной для использования в системах с огромными объёмами плохо структурированных данных - в так называемых Big Data-системах.

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

REST

REST (расшифровка аббревиатуры в данном случае нам ничего не даст, поэтому мы ей пренебрежем) - это протокол вызова удаленной процедуры с помощью обычного HTTP-запроса. Да-да, с помощью тех самых методов GET и POST из учебников Тима О’Райли.

За каждый метод в REST отвечает не отдельно взятая запись в файле WSDL, а URL. К примеру, метод для получения сведений о пользователе будет иметь вид - http://example.com/rest/user. А метод создания нового пользователя - http://example.com/rest/user/create.

Для передачи параметров в REST можно использовать тело запроса, а для описания ошибок - статусные заголовки HTTP. Всё максимально просто и не требует использования дополнительных протоколов. REST гораздо примитивнее SOAP. Именно это делает его отличным выбором, когда нужно обмениваться большим объёмом данных и делать это часто.

REST не диктует, в каком формате передавать запросы. А значит для этих целей можно использовать JSON (текстовый формат обмена данными) - самый компактный формат обмена структур в текстовом представлении. Его использование практически полностью решает проблему объёма данных.

ВЕЛОСИПЕД

Иногда приходится использовать комбинации нескольких методов и протоколов взаимодействия.

В 1С есть собственный формат CommerceML - XML для передачи коммерческой информации, чаще всего таким способом передаются каталоги товаров.

Этот формат разработан специалистами фирм 1С и Extra.RU. Им помогали друзья из московского офиса Microsoft.

По этой причине формат не предусматривает многих вариантов использования, и «чистого» CommerceML часто не хватает. Это приводит к необходимости дополнения его специальным функционалом.

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

В случаях когда нужно постоянно поддерживать данные в актуальном состоянии, мы можем связать Rest API и передачу XML вместе. Тогда 1С будет отправлять XML напрямую на сервер, используя стандартные POST-запросы.

Шаг 5. Безопасность данных

Чаще всего там, где возникает необходимость в интеграции, есть объекты коммерческой тайны или персональные данные. Работа с ними после недавних изменений в законодательстве теперь заслуживает отдельной статьи.

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

Вариантов защиты много. Мы рассмотрим только некоторые из них.

HTTPS

Протокол HTTP - самый распространенный и самый незащищенный. Данные по нему передаются в незашифрованном виде. HTTPS - это разновидность http-протокола, поддерживающая шифрование с использованием сертификатов SSL или TCL.

Сертификаты - это алгоритм, по которому будет происходить шифрование данных. Об этом алгоритме знают только передающая и принимающая стороны в момент передачи данных. SSL-сертификаты могут поставляться самим сервером, но тогда они будут считаться недоверенными, и браузеры могут выдавать пугающие пользователя картинки.

Окно предупреждения пользователя о недостоверном соединении Для того чтобы сертификат считался доверенным, его необходимо заказывать у организации, занимающейся сертификацией - центра сертификации. Таких учреждений много. Работая над проектами европейских заказчиков, мы предпочитаем пользоваться услугами одного из двух крупнейших игроков на рынке SSL-сертификации - Thawte или Verisign. В России работаем с Ру-центром. Их значки можно часто видеть на сайтах, где подразумевается оплата или работа с персональными данными.

HTTP-Basic авторизация

Вторым методом обеспечения защиты является способ, при котором две системы «представляются» друг другу с помощью пары «логин - пароль» до того, как начать обмениваться данными. Такой метод называется «HTTP-basic авторизация».

Чтобы злоумышленники не смогли перехватить пароли, «представляться» системам лучше в шифрованном виде, т.е. HTTP-basic авторизацию надо использовать совместно с SSL-шифрованием.

Предоставление доступа по IP-адресу

Если система не слишком сложна и у серверов взаимодействующих систем есть определенные и неизменные IP-адреса, можно предоставлять доступ к обмену данными только для этих IP-адресов.

Этот вариант прост в реализации и поэтому широко распространен. Но иногда он приводит к внезапным проблемам с доступом.

Шаг 6. Техническое задание

У вас могут быть превосходные отношения с заказчиком или его 1С-программистами, но «дружба дружбой, а табачок врозь». Мы настоятельно рекомендуем зафиксировать договоренности по всем описанным шагам письменно.

Поучительный пример из собственного опыта: Нам предстояло сделать сложную интеграцию «1С:Предприятия» заказчика с используемым интернет-магазином. На встрече с 1С-программистами мы договорились о том, что они подготовят веб-сервисы на своей стороне, к которым веб-программисты Студии будут впоследствии обращаться.

В процессе практической тесной работы, которая заняла не один месяц, 1С-программисты изменили свою точку зрения и приняли решения сделать для нас копию своей БД, реплицированную с главной и передать ее нам для того, чтобы мы «делали с ней все, что захотим».

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

В приведённом примере нам повезло - 1С-программисты оказались ребятами порядочными и подтвердили перед своим руководством нашу правоту. Но повезет ли так же в следующий раз?

Вы можете работать по гибким методологиям, использовать классический «водопад» или применять гибридную методику. Это не важно, также как и формат и объем ТЗ. Важно только то, что все договоренности должны быть так или иначе зафиксированы.

Шаг 7. Реализация

В непосредственном производстве работ по интеграции тоже есть несколько отличий от моноразработки.

ЕДИНАЯ КОМАНДА

Чтобы разработка шла как можно более гладко, избегайте деления на «ваших» и «наших». Наоборот, сделайте всё для формирования единой команды из разработчиков внешней информационной системы и ваших программистов.

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

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

ТЕСТИРОВАНИЕ НА ВХОДЕ

Работая с третьей стороной, придется заниматься тестированием не только «на выходе», но и «на входе».

Пример из собственной практики: программист CRM-системы отчитался, что веб-сервис, необходимый для выполнения работы завершен. Руководитель проекта сформировал задачу веб-программисту и выставил ее, сопроводив ссылкой на этот веб-сервис. На следующий день веб-программист в точном соответствии с графиком приступил к выполнению задачи и столкнулся с тем, что веб-сервис не работает. Задача возвращается CRM-программисту. Время веб-программиста, руководителя проекта и деньги заказчика потрачены впустую. Все снова ждут готовности нужного веб-сервиса.

Раньше всё зависело только от вашей команды, и сформулированная задача сразу выставлялась программисту. Теперь же придётся сначала убедиться в том, что компоненты для решения задачи, выполненные третьей стороной, действительно работают.

ПОКРЫТИЕ ТЕСТАМИ

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

Чем быстрее обнаружится, в каком месте системы и что именно «полетело», тем меньшими будут затраты на её поддержку, и тем выше будет прибыль. Поэтому не экономьте на покрытии кода тестами.

В случае веб-интеграции процент покрытия кода тестами должен быть как можно более высоким.

Шаг 8. Отказоустойчивость

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

Некоторые из проектов, выполненных нами, могут потерять от $35 000 до $70 000 в случае суточного простоя. Это заставляет дополнительно задумываться о мероприятиях повышения отказоустойчивости всей системы.

Резервное копирование. Все это прописывают в ТЗ и договорах. Но давайте будем честны, вы всегда проверяете, действительно ли хостер или разработчик настроил процедуры резервного копирования в соответствии с договоренностями? Чаще всего это выясняется тогда, когда беда уже произошла.
Нагрузочное тестирование. На какую посещаемость и пиковую нагрузку рассчитывает заказчик? Умножьте эту цифру хотя бы на 2,5 и сделайте синтетические нагрузочные тесты. Тестировать нужно не только сайт, но и те системы, с которыми взаимодействует проект.
Сезонность. Знайте сезонность бизнеса своего заказчика. Посещаемость сайта сети кинотеатров, который мы сделали и поддерживаем, в новогодние праздники возрастает в 2-3 раза. В этом проекте мы начинаем подготовку к Новому году в начале ноября.
Готовность к «откату». Вы работаете в команде, и это придется учитывать. Будьте готовы к тому, что ваши новые функции могут нарушить нормальную работу внешней системы и изменения придется быстро «откатить» назад. Несмотря на нагрузочное тестирование, внешние системы иногда выходят из строя по независящим от вас причинам. Вы должны быть готовы продолжить работу, отключив на время совместный функционал. Например, во время аварии сервиса покупки билетов вместо процесса оформления заказа мы показываем сообщение с извинениями, но сам сайт продолжает свою работу.

Шаг 9. Логирование и мониторинг

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

Это объективный инструмент, с помощью которого можно будет восстановить хронологию событий, поможет не только сохранить нервы, но и защитит в случае судебных разбирательств. Поэтому готовую систему важно «обвешать» индикаторами и датчиками.

В Студии мы стараемся сделать всё так, чтобы о выходе из строя сайта или его части узнавать не из телефонного разговора с разъярённым клиентом, а при помощи собственных систем мониторинга.

Мы не станем подробно затрагивать этот процесс и, может быть, посвятим этому отдельную статью, но для тех, кто плохо знаком с этими темами, советуем начать с гугления терминов Pinba, Zabbix и Munin.

Шаг 10. Документирование

Договоритесь о том, в каком виде будет вестись проектная документация, и постарайтесь держать её в актуальном состоянии.

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

Совет самый простой по смыслу и самый сложный по соблюдению. Мы в Студии стараемся это делать примерно так:

Договорились о формате ведения и месте хранения проектной документации.
Составили перечень документов, входящих в понятие «проектная документация». Как правило это несколько документов, включая карту бизнес-процессов, описание серверной архитектуры, наше ТЗ, документация на API внешней системы, и т.д.
Назначили ответственного за актуальность документации. Обычно это руководитель проекта.
Назначили периодичность проверки документации.

Всё! Теперь ответственный время от времени делает выборочную или сплошную, это уже кому как нравится, проверку актуальности документов. Или не делает... и понимает, что может огрести за это в любой момент.

Заключение

Статья получилась большой и сложной. Но меньше всего хотелось отпугивать вас от веб-интеграции. Конечно, она требует опыта. Но опыта не бывает без практики. А практики не бывает без ошибок.

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

Просьба: сейчас в Студии мы пытаемся понять, заинтересованы ли вы в прочтении подобных статей? Чтобы сделать материал полезным и практичным, требуются очень большие усилия. На подготовку этой статьи ушло около 20 часов трёх специалистов.

Наш арт-директор Саша Котов считает, что мы «маемся дурью», и это никто читать не будет:-)

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

Ситуация на рынке интернет-услуг в 2017 году не так проста. Если 5-6 лет назад новые компании в этой сфере появлялись буквально десятками каждый день, сейчас ситуация усложнилась. По статистике, больше половины действующих компаний существует более 6 лет, раньше доля молодых была гораздо выше. Конкуренция на рынке огромна, а спрос на услуги – в стагнирующем положении. Причин тому несколько:

Пять лет назад бизнес переходил в интернет гораздо более широким потоком, чем это происходит сейчас. Многие уже заняли свое место на рынке, некоторые по-прежнему не видят смысла в создании сайтов или пользуются альтернативными вариантами (SMM, реклама на досках объявлений и т.д.). Кризисные явления в экономике негативно сказались на бюджетах и желании бизнеса инвестировать в развитие.
Стоимость качественного продвижения бизнеса выросла. Если раньше клик в «Яндекс.Директе» стоил, в среднем, 5-7 рублей, сегодня эта цифра выше в 5-10 раз. Если в эпоху классического SEO и низкой конкуренции продвинуть сайт в топы поисковиков стоило относительно недорого и с этим справлялся фрилансер средней руки, сейчас бюджеты могут измеряться десятками (иногда сотнями) тысяч рублей в месяц. Приобретя для клиента большую значимость, чем телевизор или наружка, интернет автоматически стал дорогим.
Конкуренция между компаниями достигла пика. Аналитики отмечают, что на рынке утвердился определенный пул авторитетных компаний (существуют более 6 лет), а количество новых компаний и тех, что ежегодно закрываются, почти сравнялось.

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

Емкость рынка, по данным 2015 года, оценивалась в 24 миллиарда рублей, а количество участников на рынке - более чем в 10 тысяч. И это не считая фрилансеров, которых, по примерным подсчетам, более миллиона.

На рынке интернет-услуг действует очень жесткая градация по статусу и бюджету. Переход из одного класса в другой очень труден. Условно можно выделить эконом-сегмент (средняя стоимость проекта - до 100 тыс. рублей), средний класс (проекты бюджетом до 500 тыс. руб.) и премиум-класс (средний бюджет - 1 млн рублей). Отмечается, что более 40% крупных заказов выполняется 20 студиями топ-класса. Средний класс находится в сложных условиях потому, что клиентов в кризис стало меньше, а те, что есть, приходят с довольно жесткими требованиями по качеству. Затраты большого количества человекочасов на проекты оборачиваются низкой рентабельностью. Эконом-сегмент специализируется на типовых проектах, что в известном смысле выгоднее, но зато постоянно конкурирует с фрилансерами. Часто веб-студия в этом сегменте - слово весьма абстрактное и скрывает того же фрилансера, только оформленного в качестве ИП.

В среднем, веб-студия с 4-5 сотрудниками в штате может одновременно вести 5-6 проектов. Средний показатель - 20 проектов в год. Есть компании, которые ведут 10-12 и более проектов одновременно, это может достигаться либо набором большего количества сотрудников, либо потоком недорогих типовых проектов. Здесь все упирается в квалификацию.

Нюанс работы веб-студии в том, что классический подход от малого к большому здесь работает слабо. Если вы планируете начать с недорогих проектов и постепенно переориентироваться на более дорогие, ваш путь будет очень долгим. И не факт, что результативным. Здесь нужно начинать с приобретения опыта - лучше всего устроиться на работу в студию среднего и высокого уровня. Здесь вы быстрее приобретете высокую компетенцию, познакомитесь с людьми, которые в будущем могут стать вашими клиентами. Таким способом путь в средний или премиум-класс будет более быстрым.

Резюме проекта

Мы открываем веб-студию среднего класса в крупном региональном центре. Предполагается, что предприниматель имеет не менее 5 лет опыта работы в аналогичной веб-студии на должности руководителя отдела разработки или продвижения.

В список оказываемых услуг входят:

Создание сайтов-визиток, интернет-магазинов и корпоративных порталов на базе «Битрикс» под ключ.
Разработка лендинг-пейдж.
Разработка индивидуального веб-дизайна.
SEO-продвижение сайтов.
Настройка и поддержка контекстной рекламы.
SMM и таргетинг в социальных сетях.
Аудит и техническая поддержка сайтов.

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

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

Регистрация бизнеса

Для работы избирается форма ИП. Ее вполне достаточно для работы на подряде у других организаций, процесс регистрации быстрее, а ведение отчетности проще. Формой налогообложения избирается УСН 15%, поскольку в этом бизнесе велики издержки на оплату труда специалистов.

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

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

Для работы желательно получение статуса партнеров, который предоставляется создателями популярных платформ для создания сайтов: «Битрикс», CS-Cart и других. На первом этапе планируется получить статус партнера «1С-Битрикс».

Стоимость затрат - 5 тыс. рублей.

Аренда помещения

Для работы потребуется офис площадью 20 кв. метров. В приоритете офисные здания и бизнес-центры. Место его размещения не приоритетно, поскольку наружная реклама не играет для нас особой роли. Каналы продвижения будут находиться в интернете.

Основные требования:

Цена офиса.
Наличие качественного инструмента.
Наличие остановки общественного транспорта и парковки для удобства поездки на работу сотрудников.

Помещение можно организовать в формате open-space. Руководитель будет выполнять и задачи по одной из должностей (в нашем случае - SEO-специалист), работать вместе с командой, поэтому выделять площадь под кабинет руководителя необходимости нет. Установим модульные стеклянные перегородки общей стоимостью 50 тыс. рублей.

Потребности в специальном ремонте помещения нет, поэтому отдаем предпочтение месту, в которое вкладывать дополнительные деньги не требуется.

Стоимость его аренды составит 12 тыс. рублей в месяц.

Покупка оборудования

Это одна из основных статей стартового капитала. Для организации каждого рабочего места необходимы:

Стол.
Стул.
Ноутбук.
Сетевое оборудование.

Кроме того, в общей зоне установим чайник, микроволновку, кулер. Вложения в таблице:

Персонал

Сотрудники - самая важная составляющая данного проекта. На них идут основные затраты в процессе работы, но они же принесут вам прибыль. В штате будут работать 4 человека, сам основатель компании будет выполнять функции SEO-специалиста.

Начисление заработной платы будет осуществляться по комбинированной схеме: фиксированная ставка (оклад) + премия.

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

График работы сотрудников: с понедельника по пятницу, с 09:00 до 18:00.

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

Итого, на персонал мы потратим 218 тыс. рублей в месяц.

Маркетинг и реклама

Стандартные методы продвижения веб-студии мало подходят. Офлайн в этом бизнесе работает крайне плохо в связи с тем, что сама целевая аудитория ориентирована на интернет и ищет партнеров именно там.

Основные усилия следует направить именно на онлайн. Планируются следующие направления:

Важно приобрести статус специалиста в своей отрасли, тогда вы быстрее сможете выйти на тот уровень, когда уже клиенты ищут вашего внимания, а не наоборот. Это важно в любой сфере, в интернете - особенно.

И желательно начинать с какой-то позиции: например, с нескольких заказчиков, с которыми вы работали прежде.

Большая часть работ по продвижению в интернете будет производиться собственными силами, но понадобится небольшой бюджет на SEO и запуск контекстной рекламы. Всего уйдет около 100 тыс. рублей. Еще столько же будет требоваться на рекламу ежемесячно.

Финансовый план

Стартовые расходы

Доходы

Доходность веб-студии можно подразделить на три группы. Во-первых, это постоянные проекты длительностью от 2 месяцев до года. Оплата их производится на основании первоначально разработанного бюджета по принципу абонентской платы или за выполнение конкретных задач по утвержденному плану. Во-вторых, это небольшие проекты короткой длительности (доработка сайтов, создание лендингов). В-третьих, хорошо пополняет счет веб-студий услуга поддержки сайтов. Она не требует постоянного внимания. Как правило, в пакет входит снятие позиций по ключевым запросам и их поддержка, а также оперативное восстановление сайта после падения, ddos-атаки или вирусного заражения.

Ориентировочный план доходов в таблице:

*Указаны усредненные цены по проектам. Реальная стоимость рассчитывается индивидуально.

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

Средняя рентабельность - около 25%. Ее можно считать неплохой для данной сферы. Лидеры рынка отмечают как отличную рентабельность на уровне 50%, к которой и нужно стремиться.

Период окупаемости, при условии быстрого выхода на данный уровень прибыли, составит 6-7 месяцев. Реальная окупаемость ожидается на 12-14-й месяц работы, когда мы выйдем на стабильный поток клиентов.

Достоинства и недостатки

Преимуществами данного плана можно назвать:

Устойчивую исходную позицию по первым клиентам, поскольку создатель веб-студии имеет солидный опыт работы в данной сфере и может собрать команду проверенных профессионалов.
Перевод части задач сотрудникам на фриланс, что положительно сказывается на рентабельности.
Недорогое помещение в офисном здании, минимальные затраты на эти цели.

К недостаткам можно отнести:

Вероятные репутационные риски из-за более сложного контроля удаленных сотрудников.

Перспективы развития

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

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

В будущем мы планируем постепенно расширять штат сотрудников, брать больше заказов и, соответственно, увеличивать количество и качество реализуемых проектов.

Риски бизнеса

Не выйти на запланированный уровень по продажам. Решение: проанализировать причины невыполнения плана, поработать дополнительно над улучшением каналов продвижения и устранением своих недостатков.
Завышенный план по продажам. Решение - составлять план не ранее чем через три месяца, когда будут понятны возможности сотрудников по количеству выполненных задач и эффективности работы. В процессе планомерно повышать эффективность расходования времени, поскольку временные ресурсы сотрудников - самое дорогое в этом бизнесе.
Низкое качество оказываемых услуг. Проанализировать причины, заменить сотрудников, которые не справляются со своими задачами. Если трудно найти работников в своем регионе, попытаемся использовать децентрализацию и работать с удаленщиками.
Финансовый кризис. Кризисы вызывают урезание бюджетов бизнеса на продвижение в интернете. Это серьезный риск для веб-студий, предсказать который, к сожалению, невозможно.

В итоге

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

5000 RUB

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

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

Хотите контролировать всю работу организации? Сконструируйте все бизнес-процессы с самого начала развития бизнеса.

Что подразумевает собой бизнес-процесс?

Это взаимосвязь различных задач (цепочек действий), помогающих в создании услуг или определенного товара для клиентов. Например, оплата счетов, утверждение отпуска, контроль расхода материалов, реализация заказа в интернет-магазине и т.п.

Рабочие процессы состоят из трех этапов:

Поддержка;
операция;
управление.

Они, в свою очередь, подразделяются на под-процессы.

Создание бизнес-процесса довольно не простая вещь и больше подходит для крупных организаций, предполагает следующее:

Сбор необходимой информации;
описание уже имеющихся бизнес-процессов;
анализ полученных данных. Описание того, чего хотелось бы получить. Определение всех сложностей;
создание плана. Пропись всех взаимосвязей. Назначение ролей и ответственных сотрудников;
формирование процесса в системе (CRM, BPM);
обучение рабочего персонала.

Веб компания WM предлагает своим клиентам создание сайта на системе управления 1С-Битрикс с интеграцией сайта с CRM Битрикс24 .

Как происходят бизнес-процессы в небольшой организации?

Для маленькой и еще молодой компании существует упрощенный вариант организаций бизнес-процессов, главными из которых являются:

Обработка заказов;
общение с клиентами;
взаимодействия с поставщиками.

Чтобы понять, какие наиболее важными будут бизнес-процессы, необходимо проанализировать часто повторяющиеся проблемы.

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

Что делать? Пошаговая инструкция

Определить и сформировать как можно быстрее основу бизнес-процесса.
Определить проблему.
Провести исследования по каждому проблемному пункту, и найти места, в которых образуются сложности и задержки.
Описать идеальный процесс работы:
- Кто будет участвовать, и кто на каком этапе за что будет отвечать;
- какая информация на каждом этапе будет передаваться от одного сотрудника к другому;
- сроки завершения процесса.
Представить блок-схему или сразу выполнить программу в BPM/CRM.
Выбрать ответственных за каждый процесс, дать разъяснения по работе.

Веб студия «WM» готова взять на себя организацию бизнес-процессов вашей компании.

Одни из важных услуг, которые предлагает наша организация, это:

Интеграция 1С с корпоративным порталом;
интеграция магазина с 1С УТ (УНФ);
поддержка сайта ;

Бизнес-процесс «Взаимодействие с потребителем» на реальном примере

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

Каким образом в вашей организации обрабатываются заявки клиентов?

Распределяются ваши клиенты по группам (размер сделки, их местонахождение, тематика)?
Знает менеджер вашей компании, как вести клиента от первого обращения до оплаты? Какие четкие шаги нужно выполнять?
Систематизирован ли процесс повторных продаж, и насколько?
С какой систематичностью от вас уходят клиенты? Не успеваете оформить документацию, своевременно напомнить, дать ответ на письмо или позвонить?

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

Примерное описание данного бизнес-процесса

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

Передаем его свободному менеджеру компании, либо выбираем по определенному критерию: месторасположение, тема сделки, сумма сделки.

Связываемся с клиентом и уточняем информацию.

Подготавливаем коммерческое предложение и отправляем заказчику. Назначаем встречу. Предоставляем уточняющую информацию по средствам буклета, презентации и т.п.

Спустя некоторое время напоминаем о себе телефонным звонком или письмом.

Подготавливаем и высылаем пакет документов. Предварительно согласовываем их с юр. отделом и бухгалтерией.

Выставляем счет.

Закрываем сделку.

Второстепенные бизнес-процессы

Их важность заключается в помощи оперативного роста организации, без утраты правильного учета управления и финансирования.

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

На данный момент на рынке TaskManager/CRM очень много разных предложений, но не все они подходят для управления проектами в веб-студии.

Веб-студия «Магвай» работает с 2009 года. За это время мы пробовали много разных систем для ведения проектов и только недавно нашли для себя идеальную программную связку. Но, вернемся к началу.

В начале 2009 года мы вели проекты с помощью форума на PhpBB. Сейчас это звучит смешно и нелепо, но тогда казалось, что ничего удобнее и быть не может. Туда же заносились данные по документообороту и потенциальным сделкам.

Этого «разнообразия» нам хватило на пару лет, а затем в 2011 году мы нашли TaskManager, заточенный под бизнес веб-студии и это был «Мегаплан». В тот момент нашей радости не было предела – клевый интерфейс, с продуманным юзабилити, и весьма удобная начинка. Но скоро наш энтузиазм быстро прошел. Система на тот момент была еще довольно «сырой», функциональность хромала. Было неудобно заносить потенциальные сделки, хранить файлы, ставить задачи. Раздражали слишком отвлекающие элементы, ненужные кнопки, фишки; например, при постановке задачи кнопки окружали форму создания аж с 4-х сторон. Бизнес-процессы было сложно настроить, возможно, для некоторых и вовсе не было подобного функционала. Сейчас, судя по отзывам, «Мегаплан» уже продуманная, функциональная и удобная штука. В 2011-2013 годах это было не совсем так, но за неимением лучшего, мы продолжали работать с «Мегапланом».

В то время также рассматривали и зарубежные аналоги – Basecampи Jira, но англоязычный интерфейс отталкивал, а на освоение многих функций требовалось больше времени, чем мы могли и хотели выделять.

А затем в 2013 году мы открыли для себя Битрикс 24, на котором работаем и по сей день. Это неидеальный продукт, но для начала он был функциональнее и удобнее «Мегаплана». Мы перешли на него почти безболезненно, с переносом и сохранением данных. Данные переносили не сразу, а только когда 1С-Битрикс купили долю в Мегаплане – появилась удобная интеграция данных из Мегаплан в Б24, чем мы успешно и воспользовались.

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

Мы в студии «Магвай» непрерывно ищем наиболее удобные программные связки для того, чтобы сделать бизнес-процессы максимально удобными и логичными для нас.

На сегодняшний момент связка Битрикс24 + Trello + AmоCRM для нас удобна и закрывает все процессы, начиная с продаж, продолжая планированием задач, и заканчивая самой разработкой.

Битрикс24 имеет достаточно обширный функционал, но есть некоторые нюансы, которые являются для нас не совсем удобными, и есть функционал, которого нам порой не хватает в работе.
Например, очень не хватает приоритетов, которые можно присваивать задачам, выстраивая очередность. Да и сама очередность задач в Битрикс24 не так удобна для нас: каждый раз нужно задавать сортировку. Общая картина – кто и что делает, сколько задач в дизайне, сколько задач у технической поддержки – прослеживается в Битрикс24 с трудом. Последнее – особенно важно, ведь необходимо, чтобы руководители всех звеньев видели занятость специалистов на данный момент, очередь из будущих задач, приоритеты. Только так можно понимать загруженность студии, возможность взять новый проект или выделить время на разработку собственного продукта студии.

Со стороны Исполнителей также есть определенные трудности. Исполнитель видит 100500 различных задач, и, хоть они и объединены по группам, «портянка» от этого меньше не становится. С другой стороны, функционал постановки задач, контроль их выполнения, общение в чате Б24 нас полностью устраивают. Как с этим быть? - Мы нашли решение в виде Trello.

Trello, по сути, обычная канбан-доска, которых существует великое множество, в том же Б24 есть некая встроенная функция доски задач, есть неплохое платное решение от Сибирикс. Но Trello, по нашему мнению, имеет ряд преимуществ:

1. Не нужно платить деньги. Точнее, вы можете приобрести подписку на расширенный функционал, но и того, что предлагают бесплатно, вполне хватает;

2. Простота и интуитивность интерфейса.

3. Кастомизация под нужды команды. Мы создаем только те доски, которые нужны, настраиваем свои списки задач в каждой доске, управляем уровнями доступа к каждой доске, сами настраиваем и присваиваем маркеры к каждой карточке.

Таким образом, все задачи обязательно ставятся в Б24 и дублируются в Trelloв виде карточек с кратким описанием и ссылкой на задачу. Мы видим, сколько задач и на каком исполнителе сейчас, какая очередность у задач и какие статусы (например «сделать срочно» или «баг после тестирования»).

Перед тем, как мы начали использовать Trello, у нас было несколько магнитных досок, на которых мы планировали работы и следили за приоритетом задач. Многие наши коллеги пользуются стикерами, в общем, каждый выкручивается как может. Но сейчас мы совсем отказались от физических носителей для планирования задач.

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

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

Еще важный момент, которого нам недостает в Б24 – это база потенциальных сделок, контроль работ по ним для отдела продаж. И снова, этот функционал есть в Б24, но нас он категорически не устраивает. Есть ощущение, что его делали технари, без поправки на нужды маркетологов и продажников – настолько, на наш взгляд, там неудобный интерфейс. Поэтому мы не используем встроенный в Б24 механизм CRM, заменяя его еще одним сторонним сервисом AmoCRM.

Если говорить об AmoCRM, то открытие этого сервиса быстро и четко расставило все точки над «И» в секторе продаж студии.

В Amo мы работаем с 2016 года и это настолько приятно и удобно, что прямо проецируется на довольных лицах специалистов отдела продаж.

Система выстроена настолько просто, что освоение ее функций происходит интуитивно. AmoCRM позволяет вести учет всех потенциальных клиентов, просматривать их на общей «доске», прикреплять различные стикеры-этапы (которые, кстати, можно создавать самому) и ставить задачи внутри сделки.

Отдельно можно рассказать о том, что Amo – это удобный справочник всех контактов, которые взаимодействовали с нашей студией во время продажи проектов. Это позволяет хранить всю информацию о Заказчике в одном месте, а не создавать для этого горы архивов. К тому же с данной системой легко осуществлять вторичные сделки, когда клиент возвращается в студию, или когда мы снова «напоминаем» о себе по прошествии времени.

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

Мы, исследовав многие сервисы за долгое время работы студии, нашли и используем максимально удобную для нас программную связку Битрикс24 + Trello + AmоCRM.

Но нет предела совершенству, мы с интересом смотрим на рынок TASKManager/CRM и с удовольствием тестируем что-то новое. Например, для почасовой технической поддержки и для постоянной работы с зарубежными заказчиками уже применяем Slack. Потому что мы всегда стараемся гибко адаптироваться к новым обстоятельствам на рынке веб-разработки или к изменениям внутри студии.

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

Автоматизация базовых бизнес-процессов студии на этапе продаж

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

Именно благодаря описанному ниже подходу WebCanape добилась высокой производительности на старте без роста расходов на масштабирование команды. Только спустя 5 лет работы у нас появился выделенный отдел продаж. До этого поток в 120 заявок в месяц с конверсией в 60% обрабатывал один человек.

Но скорость — это не только экономия, это еще и лояльные клиенты. Кто первый сделает КП того и тапки:) Реальный предприниматель с деньгами скорее выберет первое понравившееся предложение, чем будет тратить время на ожидание различных вариантов.

Базовые бизнес-процессы студии на этапе продаж

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

Учет входящей заявки

Отправка анкеты, брифа

Обработка брифа, расчет стоимости

Подготовка КП

Подготовка договора и приложений

Выставление счета

Оплата счета

Заявку нужно принять, внести в учетную CRM систему (5 минут), данные перенести в базовую часть брифа и отправить его клиенту (еще 5 минут). После заполнения клиентом брифа, его нужно обработать, сделать расчет (20 минут) и подготовить продуманное коммерческое предложение (40 минут) с предварительной структурой сайта и сервисами. На подготовку договора и приложений потребуется еще 30 минут, 10 минут на выставление счета.

На реализацию этих процессов по одной заявке стандартному отделу продаж требуется примерно 110 минут чистого времени. Это значит, что для обработки 70 заявок необходимо 128 часов. При перерасчете на большое количество заявок — это существенные потери, которые не нужны клиенту, но влияют на конечную стоимость продукта. При этом, веб-студия почему-то пытается оптимизировать работу производства (процесс создания продукта), а не эти пустые процессы. Давайте посмотрим, что сделали мы.

Для обработки 70 заявок в месяц менеджеру требовалось 128 часов (фул-тайм продажник). После оптимизации и автоматизации процессов стало 37 часов. Теперь вы видите почему мы долго работали без выделенного отдела продаж. Единственное, очень важно иметь опытного человека на входе. Автоматизация сама по себе работать не будет.

Скорость и взаимозаменяемость

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

Для многих она выходит на первый план. Менеджер по продажам не может подготовить профессиональное КП. Где взять продажников с опытом продажи сайтов, когда их нет в регионах?

Соответственно нам необходимо было дать инструмент, который поможет хорошим менеджерам с небольшим опытом в сфере веб-разработки быстро вести документооборот и создавать профессиональные КП.

Таким инструментом стал наш внутренний инструмент, который мы назвали «Калькулятор». Существенно позже он переродился в CanapeCRM, которую мы стали предлагать клиентам.

Электронные документы. Мы на 100% отказались от вордовских документов и перешли в online. Клиенту отправляется только ссылка (на бриф, КП, договор, счет). Если что-то меняется — достаточно внести правки документа в системе, нажать F5 и у клиента документ уже обновлен. Из экономии на этом и подобных процессах — появляется высокая эффективность работы.

Автоматические уведомления. Вторая важная часть автоматизации — это оповещения. В процессе работы менеджер вынужден писать большое количество писем клиентам, не несущих важной информации. Нужно клиенту сообщить статус проекта, запросить информацию, рассказать, что подготовить для предстоящих этапов и т.д. Когда проектов много — это сильно отвлекает от основной задачи, заставляет переключаться и тормозит работу. CRM система может и должна сама сообщать клиенту информацию, отправлять напоминания.

Один день, который сэкономит миллион

Потратьте этот день на полную настройку системы. Тексты уведомлений, шаблоны КП, договора и все, что может пригодится. Это поможет вам работать рентабельней и не расти в цене вслед за ростом зарплат.

Следите за новыми материалами на ,