---
title: "Мини-CRM на Google Sheets и n8n: заявки и статусы - Nodbot"
source_url: "https://nodbot.ru/recipes/google-sheets-crm/"
canonical_url: "https://nodbot.ru/recipes/google-sheets-crm/"
language: "ru"
content_type: "HowToGuide"
section: "recipes"
generated_at: "2026-05-30"
word_count_source: 869
---

# Мини-CRM на Google Sheets и n8n: заявки и статусы

## AI summary

Рецепт n8n «Мини-CRM на Google Sheets и n8n: заявки и статусы»: логика workflow, входные данные, настройки, типовые ошибки и критерии готовности к запуску.

## Best used for

Страница объясняет «Мини-CRM на Google Sheets и n8n: заявки и статусы - Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Схема workflow
- Структура таблицы
- Дубли
- Ограничения
- Архитектура production workflow
- Минимальная схема данных
- Проверка на реальных крайних случаях
- MVP и production-версия рецепта

## Source outline

# Мини-CRM на Google Sheets и n8n: заявки и статусы

Обновлено: 2026-05-29

Google Sheets часто используют как первую CRM: быстро, понятно, не требует разработки. n8n добавляет автоматизацию: принимает заявки, проверяет дубли, создаёт строки, отправляет уведомления и формирует отчёты.

## Схема workflow

```
Webhook/Form → Normalize Lead → Validate → Find Duplicate → Append/Update Row → Telegram Alert → Log Execution
```

## Структура таблицы

Минимальные колонки: lead_id , created_at , name , email , phone , source , status , manager , comment . Стабильные названия колонок важны: переименование email в почта может сломать workflow.

## Дубли

Перед добавлением строки ищите лид по email или телефону. Если найден дубль — обновите строку или добавьте комментарий. Если нет — создайте новую запись. Для надёжности используйте внешний lead_id .

## Ограничения

Google Sheets хорош для старта, но не заменяет базу данных при большой нагрузке. Если заявок много и нужны связи, роли и история, переходите в CRM или PostgreSQL.

## Архитектура production workflow

Для сценария Мини-CRM на Google Sheets и n8n: заявки и статусы полезно строить workflow не как одну длинную цепочку, а как понятный конвейер: вход, нормализация, проверка, основное действие, запись результата и обработка ошибок. Тогда статью можно использовать как инструкцию внедрения, а не как набор разрозненных советов.

- Слой | Задача | Что логировать
- Trigger | получить событие от google sheets | event_id, source, время получения
- Normalize | привести поля к единой схеме | id события или записи, source, created_at, status, payload_hash
- Validate | отсечь пустые, повторные и рискованные входы | причину отказа и исходный payload_hash
- Action | выполнить главное действие рецепта | id созданной/обновлённой записи
- Notify | сообщить человеку или системе результат | канал, статус, ссылка на execution

## Минимальная схема данных

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

- id события или записи
- source
- created_at
- status
- payload_hash
- email
- phone
- lead_source
- owner
Если поля отличаются у разных источников, добавьте отдельную нормализационную ноду сразу после trigger. Это снижает количество выражений в последующих нодах и упрощает поддержку.

## Проверка на реальных крайних случаях

- пустой payload или форма без обязательного поля
- повторная доставка одного и того же события
- частичный успех: внешняя запись создана, но уведомление не отправилось
- медленный API или временный 429/5xx
- ручной повтор старого execution через неделю после первого запуска

## MVP и production-версия рецепта

Рецепт Мини-CRM на Google Sheets и n8n: заявки и статусы не должен конкурировать со справочником нод. Здесь важен готовый сценарий: какие ноды соединить, какие данные передать и как проверить бизнес-результат.

- Уровень | Что включить | Что пока не делать
- MVP | Webhook/Trigger, нормализация, основное действие, короткий ответ | сложные retry, multi-tenant логику, лишние ветки
- Production | idempotency, error workflow, лог статусов, ручная очередь, alert | хранить токены в тексте нод или логировать полный payload
- Scale | очередь, лимиты, batch processing, SLA-метрики | раздувать один workflow до нечитабельной схемы

### Как понять, что рецепт готов

- Есть один владелец процесса и понятный критерий успеха: лид создан, письмо отправлено, документ сохранён, задача закрыта.
- Повторный запуск с тем же payload не создаёт дубль.
- Ошибочный payload не теряется, а попадает в manual review или alert.
- Все внешние API вызываются через credentials, а не через токен в plain text.
- К рецепту привязан готовый шаблон в разделе workflow или указано, почему шаблон не нужен.

## Production-сценарий и проверка рецепта

Рецепт «Мини-CRM на Google Sheets и n8n» стоит собирать в два прохода: сначала минимальный happy path, затем production-слой. В production-слое появляются dedupe, retry, error branch, audit trail и уведомление владельцу процесса, а не только красивые ноды на canvas.

Источник события для проверки: объект Google API: строка таблицы, письмо, календарное событие или файл с внешним ID. Сразу подготовьте три теста: обычный вход, повтор того же события и ошибку внешнего API.

- Слой | Что зафиксировать | Зачем
- Вход | объект Google API: строка таблицы, письмо, календарное событие или файл с внешним ID | позволяет повторить проблему без доступа к production-секретам
- Контроль | created_vs_updated, duplicate_rate, api_429_count, manual_review_count, owner_missing_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | создать дубли, перезаписать статус сделки или потерять ответственного при повторной доставке события | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Мини-CRM на Google Sheets и n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "external_id": "lead_12345",
  "source": "webhook|form|chat|email",
  "contact": {"email_hash": "sha256:...", "phone_masked": "+7***"},
  "stage": "new|qualified|waiting",
  "owner_id": "crm_user_id",
  "dedupe_policy": "update_existing_before_create"
}
```

### Критерий готовности

- рецепт проходит на тестовых данных и не создаёт дубли при повторном запуске
- ошибка внешнего сервиса уходит в отдельную ветку с понятным уведомлением
- результат можно найти по execution_id или external_id
- у workflow есть владелец, описание и ссылка на runbook

## Что читать дальше

Смотрите Google Sheets , Webhook и Telegram .

## Как адаптировать рецепт

Не копируйте workflow механически. Сначала сохраните архитектуру, затем замените сервисы под свой стек: Telegram на Slack, Google Sheets на PostgreSQL, готовую CRM-ноду на HTTP Request. Важно, чтобы остались нормализация, валидация, логирование и обработка ошибок.

- Определите trigger и формат входных данных.
- Сразу приведите поля к единому формату.
- Добавьте проверку дублей или idempotency, если действие нельзя повторять.
- Сделайте alert для критичных ошибок.

## Критерий готовности

Рецепт готов к production, когда он успешно проходит не только «идеальный» пример, но и пустой input, дубль, ошибку API и повторный запуск. Если эти случаи не проверены, workflow лучше считать прототипом.

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)
- [Сравнения](/compare/)

## Retrieval hints

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