В статье разберем реальные данные для B2B-демо: какие клиенты, сделки, документы и статусы нужны, чтобы первый показ выглядел правдоподобно.
Пустое демо выглядит аккуратно только первые несколько секунд. Потом взгляд цепляется за пустые таблицы, нулевые отчеты и карточки без истории. У зрителя возникает простой вопрос: как система ведет себя в обычной работе?
B2B-продукты редко оценивают по интерфейсу отдельно от содержания. Людям нужно увидеть знакомую картину: клиент оставил заявку, менеджер создал сделку, документ ушел на согласование, статус изменился, в карточке остались комментарии и следующий шаг.
Показ становится убедительным не из-за большого объема данных, а из-за понятных деталей. Достаточно нескольких записей, если они похожи на реальную работу. Например, в системе могут быть несколько компаний разного типа, сделки на разных этапах, пара документов с датами и суммами, короткие комментарии вроде «ждем ответ юриста» или «согласован бюджет».
Такие мелочи помогают человеку мысленно примерить систему на свой процесс. Он уже не просто смотрит на экран, а узнает свою повседневную ситуацию.
При этом перегружать базу тоже не стоит. Если в демо сотни клиентов, десятки статусов и хаотичный набор файлов, встреча уходит в объяснение лишнего. Вместо ясного сценария получается шум. Лучше показать пять хороших записей, чем пятьсот случайных. Хорошее демо не обязано быть большим. Оно должно быть узнаваемым.
Для первого показа не нужна большая база. Нужен небольшой, но связный набор данных, который сразу отвечает на вопрос, как система выглядит в работе, а не в пустом шаблоне.
Обычно достаточно четырех основных сущностей: компании, контакты, сделки и документы. Если в продукте важна ежедневная работа менеджера, можно добавить задачи или комментарии, но в самом простом виде.
На практике хватает такого минимума:
Этого объема достаточно, чтобы интерфейс не выглядел пустым и при этом не перегружал зрителя. Человек должен быстро уловить логику: вот клиент, вот история общения, вот сделка, вот документ, вот следующий шаг.
Не пытайтесь сразу добавлять сложные отчеты, длинный архив старых сделок, редкие типы документов, нестандартные статусы и все исключения из реальной жизни. Если этого не покажут в первые 15 минут, значит, на старте это не нужно.
Хорошее правило простое: каждая запись должна участвовать в сценарии. Если вы показываете путь от нового лида до подписанного договора, то в системе должны быть только те данные, которые поддерживают этот путь.
Для первого показа обычно хватает 5-8 компаний. Этого достаточно, чтобы интерфейс не выглядел пустым, а зритель увидел живую картину: кто-то только пришел, кто-то уже в работе, кто-то давно покупает.
Главное не количество, а разнообразие. Хорошая база для первого демо обычно включает:
В карточке клиента должны быть только поля, которые дают контекст за несколько секунд. Обычно достаточно названия компании, отрасли, размера, города, контактного лица, должности, телефона, почты, ответственного менеджера и короткого комментария. Если это важно для вашей ниши, можно добавить ИНН, текущий продукт или тариф, источник обращения.
Названия компаний должны звучать обычно. Не «Компания 1» и не слишком известные бренды. Подойдут нейтральные варианты вроде «СеверЛогистик», «ГородСнаб», «Альфа Медиа Групп». Имена людей тоже лучше делать простыми и знакомыми: Анна Смирнова, Илья Козлов, Марина Орлова. Роли должны соответствовать реальной покупке: директор, руководитель отдела продаж, операционный менеджер, IT-специалист, закупщик.
Полезно показать различия между клиентами. Один может быть маленьким бизнесом с быстрым решением, другой - средним клиентом с длинным согласованием. Один из Москвы, другой из региона. У одного один контакт, у другого несколько участников. Такие различия делают демо убедительным без лишних объяснений.
Если все карточки одинаковые, данные выглядят искусственно. Небольшая разница в размере компании, ролях и истории общения делает показ намного сильнее.
Для первого показа обычно хватает 5-7 сделок. Если их меньше, система выглядит пустой. Если больше, внимание уходит в детали, а не в сам процесс.
Лучше показать и небольшие, и средние, и одну более крупную сделку. Тогда интерфейс выглядит живым. Суммы стоит брать обычные для рынка, а не слишком круглые «для красоты». Например: 120 000, 380 000 или 1 250 000 рублей.
Сроки тоже важны. Не ставьте всем сделкам одну и ту же дату закрытия. Пусть одна должна завершиться через неделю, другая через месяц, третья - в следующем квартале. Так видно, что воронка живая, а не собрана за пять минут до встречи.
Для первого показа достаточно такого набора:
Этого хватает, чтобы показать движение по этапам. Не нужно заполнять каждый статус несколькими примерами. Важно, чтобы у зрителя сложилась простая картина: от входящего интереса до результата.
Отдельно продумайте проигранные сделки. Они делают демо честнее. Достаточно нескольких понятных причин отказа: заморозили бюджет, выбрали другого подрядчика, перенесли проект на следующий квартал, не согласовали решение внутри компании.
Хорошо работает одна сделка, которая почти выиграна, но еще требует действия. Например, клиент запросил финальную версию договора, а дата закрытия стоит через три дня. По такой записи удобно показать задачи, комментарии, документы и следующий шаг менеджера.
Чтобы демо выглядело рабочим, в системе должны быть не только клиенты и сделки, но и понятные вложения. Когда в карточке есть хотя бы два-три знакомых документа, экран сразу воспринимается как реальный, а не тестовый.
Для первого показа не нужен архив на десятки файлов. Чаще всего хватает базового набора:
Файлы лучше разложить по смыслу. В карточке клиента логично хранить реквизиты, анкету, NDA или общий бриф. В карточке сделки - коммерческое предложение, актуальную версию счета, согласованное ТЗ и финальную редакцию договора. Тогда зритель видит не просто список файлов, а ход работы.
Если настоящих документов мало, часть можно заменить шаблонами. Это нормально, если шаблон выглядит как рабочий файл: есть дата, номер, название компании, сумма, ответственный менеджер и понятная версия. Пустой файл с именем вроде «dogovor_final_final» сразу ломает впечатление.
Хороший прием - показать короткую историю одной сделки. Сначала в ней лежит бриф, потом коммерческое предложение, потом договор и счет. Даже четыре файла уже создают ощущение живого процесса.
Не перегружайте демо вложениями. Если в карточке 15-20 файлов, зритель начинает искать нужный документ и теряет нить разговора. Для первого показа обычно хватает 3-5 документов на ключевую сделку и 1-2 файлов на карточку клиента.
Еще один важный момент - названия файлов. Лучше «КП_Альфа_март_2025» или «Договор_поставка_версия_2», чем безликие «doc1» и «new_scan».
Для первого показа воронка должна читаться за несколько секунд. Если человек видит 12 этапов с внутренними сокращениями, демо кажется не живым, а перегруженным. В большинстве случаев хватает пяти основных шагов и двух финальных исходов.
Оставьте простые этапы:
После них достаточно двух финалов: «Сделка закрыта» и «Сделка проиграна».
Такая схема выглядит правдоподобно почти в любой B2B-продаже и не требует длинных пояснений. Названия этапов лучше делать простыми словами. Вместо «Квалификация MQL», «SQL» или «Discovery» используйте то, что клиент поймет сразу.
Служебные действия лучше не смешивать с этапами продажи. Формулировки вроде «Ждем реквизиты», «Нужен звонок» или «На проверке договора» скорее подходят для внутренних меток, задач или комментариев. Если превратить их в этапы воронки, экран быстро становится тяжелым и запутанным.
Главное правило простое: оставляйте только те статусы, которые двигают сделку вперед и понятны без перевода с внутреннего языка компании.
Чтобы подготовить убедительное демо, не нужно заполнять систему сотнями записей. Достаточно собрать маленький, но связный набор: несколько клиентов, несколько сделок, документы и понятные статусы. Проще всего идти по таймеру.
В первые 15 минут добавьте 5-7 клиентов. Пусть это будут компании разного типа: новый лид, действующий клиент, контакт с паузой. Сразу назначьте роли: директор, закупщик, бухгалтер, пользователь продукта.
Следующие 15 минут посвятите сделкам. Создайте 4-6 записей с разными исходами: одна в работе, одна почти согласована, одна выиграна, одна проиграна. Так вы покажете, как система выглядит не только в идеальном сценарии.
Еще 10 минут уйдет на документы. Прикрепите по одному-двум файлам к ключевым карточкам. Обычно хватает коммерческого предложения, счета, договора или короткого брифа.
Потом проверьте даты, суммы и ответственных. Если в одной сделке сумма за март, а документ датирован январем следующего года, доверие к демо падает сразу.
Последние 10 минут посвятите прогону сценария. Пройдите весь путь от первого контакта до закрытия сделки. Лучше заметить пустое поле или странный статус заранее, чем во время встречи.
Хороший ориентир такой: у каждого клиента должна быть причина находиться в системе, у каждой сделки - следующий шаг, у каждого документа - понятная связь с этапом продажи.
Если вы собираете такой прототип в TakProsto, удобно сначала коротко описать сценарий в чате, а уже потом собирать приложение с нужными сущностями. Это помогает не потерять связи между клиентом, сделкой и документом.
Для быстрого и правдоподобного показа не нужно охватывать весь цикл продаж. Достаточно одного понятного кейса: новая компания пришла с запросом, менеджер завел клиента, создал сделку, прикрепил документы и довел процесс до следующего шага.
Представьте компанию «ООО СеверСнаб». Ей нужен внутренний портал заявок. Менеджер получает входящий запрос и показывает в системе, как выглядит работа с клиентом от первого контакта до согласования.
Сначала в карточке клиента указываются базовые данные: название компании, контактное лицо, телефон, почта и источник обращения. Затем из карточки создается сделка, например «Разработка портала заявок», с бюджетом 450 000 рублей и плановым сроком запуска шесть недель.
Внутри сделки появляются два файла: коммерческое предложение с кратким описанием работ и черновик договора. После демонстрационного звонка статус меняется с «Новый запрос» на «Коммерческое предложение отправлено», а затем на «Согласование условий». Показ заканчивается понятным действием: назначить следующую встречу, отправить финальную версию договора или выставить счет.
Такой сценарий читается за минуту. Человек быстро понимает, кто клиент, что он хочет, на каком этапе находится сделка и что будет дальше.
Даже хорошая система выглядит слабо, если данные в ней похожи на учебный пример. Для демо важна не красота, а правдоподобие.
Одна из самых частых ошибок - одинаковые названия компаний и контактов. Если в базе стоят «ООО Ромашка 1», «ООО Ромашка 2» и «Иван Иванов 3», доверие падает очень быстро. Лучше взять несколько разных компаний с понятными ролями и разным состоянием отношений.
Не меньше вопросов вызывают слишком крупные суммы без объяснения. Когда в системе внезапно появляется сделка на 48 миллионов, зритель хочет понять, почему она такая большая, кто ее согласует и сколько длится цикл продажи. Если ответа нет, сумма выглядит как декорация.
Еще одна частая ошибка - статусы, которые никто не понимает. Названия вроде «На этапе внутренней квалификации 2.1» или «Предфинал согласования» звучат сложно, но не помогают. Статус должен читаться сразу.
Плохо работают и пустые документы с формальными именами. Файл под названием «Коммерческое_предложение_финал_v4» без содержимого выглядит хуже, чем простой, но заполненный шаблон на одну страницу.
И наконец, настораживает слишком идеальный путь. Если все сделки двигаются только вперед, без отказов, пауз и возвратов на доработку, картинка кажется постановочной. В реальной воронке почти всегда есть задержка ответа, перенос срока, потерянная сделка или документ на правках.
Иногда достаточно оставить немного «жизни» в данных:
Тогда демонстрация выглядит не идеальной, а честной. А это убеждает сильнее.
За 10 минут до звонка полезно пройтись по демо как по короткому маршруту: открыть список клиентов, зайти в пару сделок, показать документ и быстро пройти по статусам. Если на любом шаге данные выглядят пустыми, одинаковыми или случайными, доверие падает сразу.
Перед встречей проверьте несколько вещей. В базе должны быть 5-7 клиентов, и они не должны быть похожи друг на друга. Сделки должны быть распределены по этапам, а не стоять в одном статусе. У ключевых сделок должен быть хотя бы один понятный файл: коммерческое предложение, счет, договор или бриф. Названия статусов должны читаться без дополнительных пояснений. Даты, суммы и имена должны выглядеть правдоподобно.
В конце полезно посмотреть на демо глазами клиента и задать себе один вопрос: похоже ли это на реальную работу компании хотя бы за одну неделю. Если ответ «да», базовый уровень уже хороший.
Сразу после встречи не оставляйте демо в том виде, в котором вы его показывали. Важно понять, какие данные сработали, что отвлекало и на чем клиент задержал внимание.
Сначала сохраните удачный набор как базовый шаблон. Если в системе были понятные клиенты, несколько сделок, пара документов и простые статусы, зафиксируйте именно эту версию. Так вы не будете каждый раз собирать демо заново и случайно ломать рабочий сценарий.
Потом разберите заметки или запись разговора. Уберите лишние поля, тестовые записи и детали, которые не помогали разговору. После звонка полезно добавить в демо реальные вопросы клиента: что он искал, где сомневался, какие кейсы просил показать.
Если вас спрашивали, как выглядит работа с просроченным договором, в следующей версии должна появиться такая сделка с понятным статусом и документом. Если интересовались повторной продажей, добавьте клиента с уже закрытой прошлой сделкой и новой активной заявкой.
Дальше стоит сделать короткий рабочий цикл: сохранить текущую версию как базовую, убрать все, что не использовалось на звонке, добавить несколько частых вопросов клиента в сценарий и подготовить вторую версию под конкретный сегмент.
Один и тот же набор редко подходит всем. Одним важны счета и согласования, другим - бриф, договор и продление, третьим - отгрузка и повторный заказ. Чем ближе данные к повседневной работе клиента, тем легче ему представить свою команду в системе.
Если после встречи стало ясно, что нужен новый черновик B2B-приложения под другой сценарий, такой вариант можно быстро собрать в TakProsto. Платформа позволяет создавать веб, серверные и мобильные приложения через чат, поэтому проще проверить другой набор клиентов, документов, статусов или экранов без долгой ручной подготовки.
Лучший способ понять возможности ТакПросто — попробовать самому.
