Сергей, мы с вами, оказывается, из одного города! Приходите в гости — покажу гибкую настраиваемую CRM, которая не требует особых затрат ;)
Допускаю, что рынок у вашего сервиса есть, поскольку до сих пор многие мелкие организации ограничиваются сочетанием Excel+Outlook. Другое дело, что если они начнут пользоваться вашим сервисом, то скоро осознают, что CRM им все-таки нужна — и либо вам придется допиливать необходимый функционал, либо они уйдут туда, где он уже есть.
Не понимаю, почему связка идет с электронной почтой, по которой отправляются выставленные счета, а не с самой той программой, в которой эти счета выставляются. Или предполагается, что менеджер делает это вручную, каждый раз вбивая данные клиента напрямую в документ Word/Excel?
Если бы я решала такую проблему (напомнить менеджеру, что пора перезвонить клиенту после выставления счета, или выслать автоматическое письмо клиенту), то я бы отталкивалась все-таки от способа формирования счета, а не от способа его отправки. В гибких настраиваемых CRM вполне можно настроить автоматическое действие в ответ на какое-то событие или при наступлении определенной даты. В данном случае можно было бы настроить либо напоминание менеджеру (оповещение внутри программы для выставления счетов), либо автоматическую отправку письма по заранее настроенному шаблону через заданный промежуток времени от даты выставления счета.
Заманчивое предложение! Вот только способ взаимодействия с аудиторией нужно правильный подобрать. Вряд ли народ там станет слушать про какие-то сервисы, тем более не развлекательные. По-моему, тут главное не про сервис рассказать, а с логотипом на фотки попасть, которые в соцсетях потом выложат :) Если получится, можно как-то связать активность со своим продуктом, если нет — неважно, главное чтобы обратили внимание. А уж серьезную полезную информацию можно заинтересованным людям и после фестиваля рассказать.
Нам в компанию сейчас требуются люди на должность, которую правильнее всего назвать «Менеджер проектов», но при этом они должны быть еще и бизнес-аналитиками, и немножко проектировщиками, ну и всего остального, что вы перечислили, хотелось бы понемножку :)
Понравилась ваша идея, как искать таких людей — брать одну узкую специальность и переманивать из нее в смежную.
как все эти люди, сидящие с чашкой кофе в уютном офисе, могут знать тонкостей и лайфхаков о моем бизнесе больше, чем я сам, пашущий по 14 часов в сутки без выходных?
Насколько я понимаю, суть работы этих бизнес-ассистентов не в советах по бизнесу, а в выполнении всяких мелких поручений, для которых не требуется особой квалификации, но которые отнимают много времени. Т.е. это просто другое название секретаря.
В статье рассказывается, какой договор выгоден заказчику. А если посмотреть со стороны разработчика?
Часто разработчик использует при создании ПО на заказ собственные разработки (например, программное ядро или «движок»), которые хочет тиражировать в дальнейшем. В таком случае мы рекомендуем включать в договор на создание ПО условия о передаче заказчику только прав на версию ПО, созданную по договору, с сохранением исключительного права на предшествующие и последующие разработки за разработчиком.
Что значит «предшествующие» и «последующие» разработки? Как отделить их от «созданного по договору»?
И как отделить «движок» от результата работ по договору?
Прибыль есть. Но тут дело не столько в прибыли, сколько в бизнес-модели. Изначально мы были нацелены на развитие платформы (отсюда перевес в коллективе в сторону разработчиков), а решения на ней (как мы предполагали) будут делать сами пользователи, а мы их лишь консультировать по отдельным вопросам. На деле оказалось, что многим проще заказать разработку и только потом, когда приложение готово, какие-то мелочи в нем менять самостоятельно.
И вот в чем вопрос: можно продолжать фокусироваться на платформе и помогать с разработкой только тем, кто сам к нам обратился, а можно увеличить количество людей, работающих с клиентами, и начать активно продавать готовые решения и услуги по разработке. Платформу конечно тоже продолжать развивать, но акцент сместить на взаимодействие с клиентами.
У каждой компании есть какое-то свое представление о комфортном размере компании. Знаю случай, когда компания осознанно сдерживала свой рост, но это было при количестве сотрудников около 50. У нас пока численность колеблется от 3 до 5 постоянно работающих сотрудников + по мере необходимости подключаем фрилансеров.
В статье приведен хороший пример для иллюстрации холодного звонка, но ответ на вопрос, вынесенный в заголовок, сформулирован слишком сжато. К тому же мне кажется, что длина скрипта измеряется не в страницах, а в количестве реплик или в количестве минут разговора.
Если есть «те, которые ее сильно просят», то, возможно, есть какие-то их контакты? Email, телефон, логин в вашем сервисе — по какому-то каналу ведь они просили эту новую функцию? Вот по тем контактам и сделать рассылку — сообщить заинтересованным, что нужная им возможность появилась. Ну и в ленту новостей добавить — кому интересно, что нового появляется, тоже увидят.
Под внутренним проектом вы, видимо, подразумеваете саму платформу SkyBase. На ней мы делаем различные решения для бизнеса. Говоря о взаимодействии с клиентами, я имела в виду доработки их индивидуальных проектов на нашей платформе.
С новичками, к сожалению, бывает еще и другая крайность — от процесса обсуждения того, как всё будет круто, они получают больше удовольствия, чем от реального результата. Поэтому могут долго и с вдохновением согласовывать ТЗ, выдумывая всё новые и новые фишки, которые будут в их творении, а потом их энтузиазм угасает и всё на этом. С таких лучше сразу хотя бы минимальную предоплату брать — тогда им жалко будет всё бросить на полпути.
Верно. Небольшие консультации нужны — коротко и по делу. Иначе как клиент поймет, что вы сможете решить его проблему? Но не стоит слишком углубляться в обсуждение деталей проекта, пока не известно, придется ли его вообще делать.
Если основатель проекта больше продавец, чем разработчик, то он легко с вами согласится. А если проект запускает программист (в случае с IT-проектами это часто случается), то даже когда продукт уже в каком-то виде существует и даже кому-то приносит пользу, автору очень трудно решиться показать продукт широкой аудитории.
А если мы ведем работу над проектом через наш внутренний трекер, вход в который осуществляется по логину-паролю, можно ли считать историю работы над задачей (фиксируется ТЗ, все даты, комментарии, изменение статусов, согласование стоимости и сроков) доказательством на случай каких-либо разногласий? Электронная подпись при этом не используется, но в договоре (настоящем, бумажном) прописан логин, с которым заказчик заходит в трекер.
Уметь обосновывать стоимость через себестоимость — полезно, по крайней мере, для самого себя: тогда при переговорах с заказчиком будешь уверен, что цену назвал адекватную, и скидывать ее просто так не станешь.
А вот заказчику надо не столько обосновывать цену, сколько разбивать проект на понятные для него задачи. Если сказать, что сайт стоит 180 тыс., заказчик не сможет сразу понять, много это или мало, т.к. не знает, откуда эта цифра взялась. Поэтому он пытается торговаться — вдруг подрядчик испугается, что сделка сорвется, и согласится уступить. А когда ему разложишь это на несколько мелких составляющих, то у него появляется некоторая уверенность, что сумма взята не с потолка, за ней реально стоят какие-то расчеты. Тут ему уже сложнее просить скидку, т.к. придется аргументировать свою просьбу несогласием с оценкой конкретного блока.
Допускаю, что рынок у вашего сервиса есть, поскольку до сих пор многие мелкие организации ограничиваются сочетанием Excel+Outlook. Другое дело, что если они начнут пользоваться вашим сервисом, то скоро осознают, что CRM им все-таки нужна — и либо вам придется допиливать необходимый функционал, либо они уйдут туда, где он уже есть.
Если бы я решала такую проблему (напомнить менеджеру, что пора перезвонить клиенту после выставления счета, или выслать автоматическое письмо клиенту), то я бы отталкивалась все-таки от способа формирования счета, а не от способа его отправки. В гибких настраиваемых CRM вполне можно настроить автоматическое действие в ответ на какое-то событие или при наступлении определенной даты. В данном случае можно было бы настроить либо напоминание менеджеру (оповещение внутри программы для выставления счетов), либо автоматическую отправку письма по заранее настроенному шаблону через заданный промежуток времени от даты выставления счета.
Нам в компанию сейчас требуются люди на должность, которую правильнее всего назвать «Менеджер проектов», но при этом они должны быть еще и бизнес-аналитиками, и немножко проектировщиками, ну и всего остального, что вы перечислили, хотелось бы понемножку :)
Понравилась ваша идея, как искать таких людей — брать одну узкую специальность и переманивать из нее в смежную.
И вот в чем вопрос: можно продолжать фокусироваться на платформе и помогать с разработкой только тем, кто сам к нам обратился, а можно увеличить количество людей, работающих с клиентами, и начать активно продавать готовые решения и услуги по разработке. Платформу конечно тоже продолжать развивать, но акцент сместить на взаимодействие с клиентами.
А вот заказчику надо не столько обосновывать цену, сколько разбивать проект на понятные для него задачи. Если сказать, что сайт стоит 180 тыс., заказчик не сможет сразу понять, много это или мало, т.к. не знает, откуда эта цифра взялась. Поэтому он пытается торговаться — вдруг подрядчик испугается, что сделка сорвется, и согласится уступить. А когда ему разложишь это на несколько мелких составляющих, то у него появляется некоторая уверенность, что сумма взята не с потолка, за ней реально стоят какие-то расчеты. Тут ему уже сложнее просить скидку, т.к. придется аргументировать свою просьбу несогласием с оценкой конкретного блока.