Запустить Project Catalog
Результат страницы
Вы подготовите один каталожный проект, который клиент может понять без длинного интервью: конкретный deliverable, границы, входные данные, срок, цена и критерии завершения. Каталог — дополнительная витрина, а не обещание органических продаж.
Когда это нужно
Project Catalog подходит, когда услуга повторяется, результат можно стандартизировать, а основные риски известны заранее. Хорошие кандидаты: аудит, настройка одного сценария, дизайн ограниченного набора экранов, диагностический отчёт, миграционный план. Не упаковывайте в фиксированный пакет неопределённую разработку, постоянную поддержку или работу, где объём выясняется только после исследования.
Доступность, модерация, лимиты, категории, add-ons, комиссии и правила покупки зависят от аккаунта и меняются. Состояние материала проверено 12 июля 2026 года; перед публикацией используйте актуальные подсказки Upwork и пересчитайте чистую сумму.
Процесс
1. Выберите входной продукт
Возьмите услугу, которую вы выполняли минимум несколько раз или можете воспроизводимо продемонстрировать. Она должна приносить клиенту самостоятельную ценность, даже если продолжения не будет. Каталог не должен быть замаскированной бесплатной консультацией или приманкой без полезного результата.
Опишите продукт одним предложением: Я передам [deliverable] для [ситуации] на основе [входных данных]. Например: «Передам аудит Core Web Vitals с приоритетным планом исправлений для одного WordPress-магазина».
2. Зафиксируйте границы
Составьте список входит / не входит. Укажите количество страниц, сценариев, источников данных, раундов правок и формат передачи. Всё, что нельзя посчитать, замените наблюдаемым ограничением. Не пишите «полная оптимизация сайта», если реально проверяете десять шаблонов и выдаёте план.
Определите входные требования: доступы, файлы, ответы на вопросы, тестовая среда. Если без них нельзя начать, это должно быть видно до покупки.
3. Соберите уровни без искусственного урезания
Если интерфейс позволяет пакеты, каждый уровень должен быть полноценным. Разница может быть в количестве объектов, глубине анализа, сроке или формате сопровождения. Базовый пакет не должен намеренно скрывать обязательную часть результата, чтобы вынудить доплату.
Add-ons используйте только для независимого дополнительного объёма: ещё одна интеграция, дополнительный язык, ускоренный срок при реальной доступности. Новый тип задачи оформляйте отдельным scope.
4. Рассчитайте цену и срок
Оцените часы выполнения, коммуникацию, правки, платформенную комиссию, налоги и резерв риска. Добавьте время на проверку входных данных и сдачу. Срок обещайте от момента получения полного комплекта материалов, если текущий интерфейс позволяет это корректно обозначить.
Не демпингуйте только ради первого заказа. Слишком дешёвый пакет привлекает несоответствующий сегмент и оставляет мало ресурса на аккуратную сдачу.
5. Покажите результат до покупки
Обложка и примеры должны демонстрировать формат deliverable, а не стоковую картинку. Покажите обезличенный фрагмент отчёта, структуру файла, пример чеклиста или скрин прототипа. Не публикуйте данные клиента без разрешения и не выдавайте командную работу за личную.
Описание стройте так: проблема → кому подходит → что клиент получает → что требуется → этапы → ограничения → следующий шаг. Не обещайте бизнес-метрику, которую не контролируете.
6. Спроектируйте приёмку и продолжение
До публикации создайте шаблон kickoff и сдачи. На старте подтвердите входные данные и границы. При сдаче передайте список файлов, краткое резюме, критерии проверки и попросите явную приёмку.
Если выявлен следующий объём, не смешивайте его с уже купленным пакетом. Сначала честно завершите deliverable и запросите отзыв о фактически выполненной работе. Затем предложите отдельный контракт или новый этап с новым scope, ценой и сроком.
7. Измеряйте продукт, а не просмотры
Фиксируйте просмотры, вопросы до покупки, покупки, отмены, трудозатраты, правки, принятие и продолжения. Важнее валовая маржа и доля завершений без scope creep, чем число показов. После нескольких реальных выполнений пересмотрите ограничения и шаблоны, не выдавая малую выборку за доказанный рыночный результат.
Критерии решения
- Если результат нельзя принять по наблюдаемым критериям, сначала сделайте оплачиваемый discovery.
- Если каждая покупка требует уникальной оценки, каталог выбран слишком рано.
- Если фактические часы системно выше оценки, поднимите цену или сузьте scope.
- Если вопросы повторяются, добавьте ответ в требования или описание.
- Если клиенты хотят другой результат, создайте отдельный продукт, а не размывайте текущий.
- Если каталог не даёт заказов, проверьте спрос, понятность продукта и доказательства; не делайте вывод только по позиции в выдаче.
Ошибки
Продавать “всё под ключ”. Неограниченный scope превращает фиксированный пакет в спор.
Считать покупку разрешением начать без входных данных. Сначала подтвердите материалы и ожидания.
Делать бесплатный аудит внутри переписки. Дайте оценку соответствия, а диагностику оставьте частью оплачиваемого результата.
Апселлить до сдачи. Клиент должен сначала получить и принять обещанный deliverable.
Держать завершённый объём открытым. Зафиксируйте приёмку, честный отзыв и отдельный следующий scope.
Копировать описание конкурента. Чужой пакет может иметь другую экономику и процесс; обещания всё равно исполнять вам.
Чеклист
- Продукт полезен сам по себе.
- Есть точный deliverable и
входит / не входит. - Указаны входные данные и стартовые условия.
- Цена учитывает все часы, комиссию и резерв.
- Срок реалистичен.
- Примеры законны и релевантны.
- Подготовлены kickoff, сдача и критерии приёмки.
- Следующая работа продаётся отдельно после завершения.
- Платформенные условия сверены в аккаунте.
Следующий шаг
Если клиенту сначала нужна диагностика в разговоре, настройте оплачиваемые консультации.