Забезпечення виконання стандартних операційних процедур календаря: 3 календарі, нульовий ручний перегляд
Ситуація
Американський інвестиційний фонд працює за суворими стандартами проведення зустрічей. Ранки захищені для глибокої роботи, понеділки - тільки для внутрішніх зустрічей, вівторки - тільки для зовнішніх, середа та четвер поглинають переповнені зустрічі з жорстким лімітом, п’ятниці залишаються без зустрічей. Команда також розподіляє час між трьома окремими календарями Google: Бізнес, Фонд та Особистий. Будь-яка помилка в цьому коштує зосередженості, часу на угоди і, зрештою, довіри з партнерами.
Проблема
Контроль був ручним. Хтось мусив щодня перевіряти три календарі, виявляти зустріч, заплановану до полудня, помічати дві зустрічі підряд без буфера, позначати зовнішнє бронювання в день внутрішніх зустрічей. Перевірки були нудними, запізнілими і легко пропускалися. Раніша спроба використовувала вбудовані статичні дані n8n, щоб уникнути повторних сповіщень, але цей стан скидається при кожному збереженні робочого процесу. На практиці те саме порушення повторно надсилалося до Slack кожні 5 хвилин протягом усього дня. Виникла втома від сповіщень, і команда почала ігнорувати канал, що знівелювало сенс.
Рішення
Я побудував двошарову систему n8n, підтримувану Supabase. Монітор в реальному часі опитує всі три календарі Google кожні 5 хвилин, перевіряє кожну подію через механізм аудиту SOP (час доби, буфер, тип дня, щоденні ліміти) і публікує порушення в спеціальному каналі Slack. Щоденний аудит проводиться о 8:30 ранку за східним часом з повним оглядом тижня та пропозиціями щодо перенесення, згенерованими штучним інтелектом, а в п’ятницю надсилається друге повідомлення з попереднім переглядом наступного тижня.
Шар дедуплікації - це елемент, який зробив це можливим у виробництві. Кожне порушення отримує стабільний ключ (правило + дата + хеш події). Перед будь-яким надсиланням до Slack робочий процес витягує сповіщення тижня з таблиці Supabase і порівнює їх. Тільки справді нові порушення досягають Slack. Щоранку щоденний аудит видаляє рядки попереднього тижня, зберігаючи таблицю компактною.
Вся система працює всередині n8n і Supabase. Немає власного сервера, немає Docker, немає локального коду. Весь інструментальний ланцюг управляється через сервери MCP, тому оновлення робочих процесів, зміни схеми та розгортання відбуваються через контрольований інтерфейс, організований штучним інтелектом, з межами безпеки від стадії до виробництва.
Технологічний стек: n8n, Supabase, PostgreSQL, Google Calendar API, Slack API, OpenAI API, MCP (Протокол Контексту Моделі)
Результати
- 3 календарі Google постійно моніторяться без жодної ручної перевірки
- Виявлення за 5 хвилин від порушення до сповіщення в Slack
- Нульові дублікати сповіщень після того, як шар дедуплікації Supabase замінив крихкий хеш в пам’яті
- Щоденний аудит о 8:30 ранку з пропозиціями щодо перенесення від штучного інтелекту, плюс попередній перегляд наступного тижня в п’ятницю
- Безсерверна архітектура: немає сервера додатків, немає Docker, повністю керується через n8n і Supabase
- Безпечні розгортання: зміни робочих процесів у виробництві контролюються явним підтвердженням оператора
Як це працює
1. Планувальник спрацьовує кожні 5 хвилин і читає стан синхронізації з Supabase
2. Події витягуються з бізнесових, фондових та особистих календарів Google, а також з затвердженого списку винятків
3. Виявлення змін завершується рано, якщо нічого не змінилося з моменту останнього опитування
4. Механізм аудиту SOP оцінює кожну подію за часом, буфером, типом дня та правилами ліміту
5. Шар дедуплікації порівнює нові ключі порушень з повідомленими сповіщеннями тижня в Supabase
6. Справді нові порушення публікуються в Slack і записуються назад у Supabase
Американський інвестиційний фонд працює за суворими стандартами проведення зустрічей. Ранки захищені для глибокої роботи, понеділки - тільки для внутрішніх зустрічей, вівторки - тільки для зовнішніх, середа та четвер поглинають переповнені зустрічі з жорстким лімітом, п’ятниці залишаються без зустрічей. Команда також розподіляє час між трьома окремими календарями Google: Бізнес, Фонд та Особистий. Будь-яка помилка в цьому коштує зосередженості, часу на угоди і, зрештою, довіри з партнерами.
Проблема
Контроль був ручним. Хтось мусив щодня перевіряти три календарі, виявляти зустріч, заплановану до полудня, помічати дві зустрічі підряд без буфера, позначати зовнішнє бронювання в день внутрішніх зустрічей. Перевірки були нудними, запізнілими і легко пропускалися. Раніша спроба використовувала вбудовані статичні дані n8n, щоб уникнути повторних сповіщень, але цей стан скидається при кожному збереженні робочого процесу. На практиці те саме порушення повторно надсилалося до Slack кожні 5 хвилин протягом усього дня. Виникла втома від сповіщень, і команда почала ігнорувати канал, що знівелювало сенс.
Рішення
Я побудував двошарову систему n8n, підтримувану Supabase. Монітор в реальному часі опитує всі три календарі Google кожні 5 хвилин, перевіряє кожну подію через механізм аудиту SOP (час доби, буфер, тип дня, щоденні ліміти) і публікує порушення в спеціальному каналі Slack. Щоденний аудит проводиться о 8:30 ранку за східним часом з повним оглядом тижня та пропозиціями щодо перенесення, згенерованими штучним інтелектом, а в п’ятницю надсилається друге повідомлення з попереднім переглядом наступного тижня.
Шар дедуплікації - це елемент, який зробив це можливим у виробництві. Кожне порушення отримує стабільний ключ (правило + дата + хеш події). Перед будь-яким надсиланням до Slack робочий процес витягує сповіщення тижня з таблиці Supabase і порівнює їх. Тільки справді нові порушення досягають Slack. Щоранку щоденний аудит видаляє рядки попереднього тижня, зберігаючи таблицю компактною.
Вся система працює всередині n8n і Supabase. Немає власного сервера, немає Docker, немає локального коду. Весь інструментальний ланцюг управляється через сервери MCP, тому оновлення робочих процесів, зміни схеми та розгортання відбуваються через контрольований інтерфейс, організований штучним інтелектом, з межами безпеки від стадії до виробництва.
Технологічний стек: n8n, Supabase, PostgreSQL, Google Calendar API, Slack API, OpenAI API, MCP (Протокол Контексту Моделі)
Результати
- 3 календарі Google постійно моніторяться без жодної ручної перевірки
- Виявлення за 5 хвилин від порушення до сповіщення в Slack
- Нульові дублікати сповіщень після того, як шар дедуплікації Supabase замінив крихкий хеш в пам’яті
- Щоденний аудит о 8:30 ранку з пропозиціями щодо перенесення від штучного інтелекту, плюс попередній перегляд наступного тижня в п’ятницю
- Безсерверна архітектура: немає сервера додатків, немає Docker, повністю керується через n8n і Supabase
- Безпечні розгортання: зміни робочих процесів у виробництві контролюються явним підтвердженням оператора
Як це працює
1. Планувальник спрацьовує кожні 5 хвилин і читає стан синхронізації з Supabase
2. Події витягуються з бізнесових, фондових та особистих календарів Google, а також з затвердженого списку винятків
3. Виявлення змін завершується рано, якщо нічого не змінилося з моменту останнього опитування
4. Механізм аудиту SOP оцінює кожну подію за часом, буфером, типом дня та правилами ліміту
5. Шар дедуплікації порівнює нові ключі порушень з повідомленими сповіщеннями тижня в Supabase
6. Справді нові порушення публікуються в Slack і записуються назад у Supabase
Харків 
Вільний для роботи