Контрольный список импорта данных перед тем, как новый клиент пришлёт CSV

Почему импорт ломается ещё до первого дня

Большинство задержек с импортом начинаются на этапе продажи, а не в самом импортере.

Представитель слышит «у нас есть CSV» и воспринимает это как лёгкое «да», но никто ещё не открыл файлы. К тому моменту, как файлы попадают к инженерии, обещание уже стало частью сделки.

CSV‑файлы на расстоянии выглядят аккуратно. Откройте их — и беспорядок проявляется сразу. В одном файле заголовок "Customer Name", в другом — "client", а в третьем то же значение разбито по двум столбцам. Форматы дат меняются строка к строке. Номера телефонов теряют коды стран. Целые столбцы пустуют, потому что кто‑то экспортировал каждое поле «на всякий случай».

Это создаёт давление с обеих сторон. Клиент ожидает быстрый старт, потому что ему сказали, что импорт будет простой. Инженеры вынуждены замедлиться, задавать базовые вопросы и объяснять, почему файлы нужно привести в порядок, прежде чем что‑то станет рабочим.

Решение начинается до того, как клиент отправит хоть что‑то. Нужны простые правила: какие столбцы обязательны, какие форматы дат и чисел вы принимаете, кто удаляет дубликаты и заполняет пустые значения, и что делать с неизвестными значениями или дополнительными полями.

Небольшой пробел в любом из этих правил может стоить дней. Если продажа говорит «пришлите данные — мы разберёмся», клиент слышит скорость. Инженерия слышит риск, потому что двадцать CSV‑файлов чаще всего означают двадцать слегка разных версий правды.

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

Сам импорт обычно не сложен. Сложность в том, что до первого дня никто не установил ограничения.

Решите, что именно входит в импорт

Когда новый клиент говорит, что у него двадцать CSV, первая задача — не загружать все двадцать. Первая задача — решить, что должно войти в стартовый импорт, а что может подождать.

Команды попадают в беду, когда считают каждый файл неотложным. Это превращает простую задачу онбординга в проект миграции.

Начните с типов записей, которые нужны людям в первый день. Во многих случаях это активные контакты, компании, открытые сделки или заказы и текущие продукты или услуги, связанные с этими записями. Этого обычно достаточно, чтобы клиент мог работать.

Старые счета 2017 года, закрытые возможности, дубли контактов и наполовину использованные кастомные поля могут подождать, если только у кого‑то нет реальной необходимости в них в первый день.

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

Выбор полей важен не меньше, чем выбор записей. Имена, email, название компании, статус, владелец и текущий план часто важны в первый день. Старые заметки, наследственные ID, неиспользуемые теги и пустые кастомные столбцы обычно нет.

Запишите, что исключено из объёма до старта. Будьте прямыми. Скажите, что запуск включает активные контакты и открытые сделки, но исключает архивные записи, удалённых пользователей, логи истории и очистку заметок. Этот шаг предотвратит множество споров позже.

Короткое примечание о зоне ответственности работает лучше большого обещания. Когда обе команды могут указать на один и тот же список для запуска, импорт остаётся меньшим, быстрее и легче проверяемым.

Установите лимиты файлов до того, как продажа скажет «да»

Отдел продаж часто обещает импорт, прежде чем кто‑то видел файлы. Это кажется безобидным, пока новый клиент не приходит с экспортами из пяти инструментов, странными кодировками и листами, где в одной вкладке смешаны три типа записей. Лимиты файлов останавливают этот беспорядок на ранней стадии.

Начните с количества строк. Выберите максимум на файл и зафиксируйте это письменно. Даже простая граница, например 100 000 строк на файл, даёт всем понятную линию. Если у клиента больше данных, попросите разбить по таблицам, диапазонам дат или аккаунтам. Меньшие файлы легче тестировать, проще перезапустить и гораздо проще исправлять, когда одна партия терпит отказ.

Ограничьте принимаемые форматы. Если ваша команда поддерживает CSV — скажите CSV. Если нужен UTF‑8 — скажите UTF‑8. Не оставляйте место для файлов Excel с скрытыми вкладками, скопированных таблиц из письма, PDF или скриншотов. Это ручная очистка, а не нормальный импорт.

Обычно один файл должен содержать одну таблицу. Контакты — в одном файле. Компании — в другом. Заказы — в третьем. Когда один лист смешивает контакты, заметки, счета и историю статусов, импорт превращается в догадки.

Правила парсинга должны быть короткими и конкретными. Используйте один разделитель. Один формат даты, например YYYY‑MM‑DD. Одно правило для десятичных. Решите, как выглядят пустые значения. Требуйте заголовков в первой строке.

Эти правила кажутся мелкими, но они предотвращают тихие ошибки. Дата вроде 03/04/2024 может означать два разных дня. Число 1,234 может быть одной тысячей двести тридцать четыре или одной целой и двумя десятыми, в зависимости от источника.

Попросите образцы файлов до подписания контракта. Десять‑двадцать реальных строк из каждого файла обычно обнаруживают сломанные заголовки, странные символы, дублирующиеся ID и столбцы, которые нужно сопоставлять. Если образец не подходит под ваши правила, измените область работ до того, как клиент услышит «да».

Напишите правила сопоставления, которыми смогут пользоваться обе команды

Лист сопоставления должен убирать споры ещё до прихода файлов. Продажи могут использовать его, чтобы объяснить, что клиенту нужно прислать. Инженерия — чтобы собрать импорт без домыслов. Если у двух команд разные правила, клиент платит этим путём за путаницу задержкой.

Начните с простого правила: каждое целевое поле получает один исходный столбец. Не объединяйте «Company» и «Account Name» в одно целевое поле, если вы не прописали правило, как решать конфликт. Если клиент присылает три похожих столбца, выберите один официальный источник и укажите, что будет с остальными.

Практический шаблон сопоставления полей должен содержать пять вещей:

• Название целевого поля
• Обязательно ли поле
• Допускаются ли пустые значения
• Допустимые значения для полей с фиксированным набором
• Значение по умолчанию, если оно есть

У обязательных полей должны быть однозначные правила, а не предположения. Если email обязателен, скажите, блокирует ли пустая ячейка всю строку или такая запись пропускается. Если для телефона пустые значения допустимы — тоже запишите. Это избавит команду поддержки от постоянных одинаковых вопросов во время онбординга.

Статусы и типы требуют дополнительной осторожности, потому что клиенты маркируют их по‑разному. В одном файле «Active», в другом — «A», в третьем — «Current». Ваши правила импорта CSV должны перечислять каждое принимаемое значение и точный результат. Если нужен запасной вариант, определите его. Например, отсутствующая стадия жизненного цикла может по умолчанию стать «lead», а отсутствующая страна останется пустой и пойдёт на проверку.

Дополнительным столбцам тоже нужен регламент. Можно их игнорировать, сохранить в заметках или отклонить файл до объяснения клиентом. Любой из подходов работает — просто выберите один и запишите.

Небольшой пример полезен. Если целевое поле называется "customer_status", сопоставление должно говорить: используйте только исходный столбец "Status", принимайте "active", "inactive" и "trial", трактуйте пустые как "trial" и игнорируйте отдельный столбец "state", если он не был утверждён в области работ. Это достаточно ясно и для продаж, и для инженерии.

Назначьте владельца очистки данных

Именно на этом этапе многие импорты сходят с рельсов. Плохие даты, отсутствующие ID, дубли строк и странные имена столбцов сами себя не исправят. Если продажа обещает «мы импортируем», вашей команде нужно чётко ответить: кто что исправляет?

Начните с исходных данных. Если клиент прислал битые экспорты, кто‑то должен решить: будет ли ваша команда их чистить, клиент отправит исправленные файлы или работа будет поделена. Зафиксируйте это письменно до старта, иначе инженерия окажется на бесплатной починке таблиц, пока все ждут.

Продажи должны собирать реальные образцы файлов рано, а не скриншоты и не устные отчёты. Пример из реальной системы расскажет больше, чем заметки с созвона. Один грязный CSV может показать проблемы с форматом даты, пустыми обязательными полями и столбцами, которые меняют имена между файлами.

Инженерия затем должна валидировать импортер по этим образцам. Речь не только о том, загружается ли файл. Команда должна проверить сопоставление полей, лимиты строк, кодировку и реакцию на ошибочные данные. Если импортер отклонит 12 000 строк из‑за одной неправильной ячейки, вы хотите узнать об этом до дедлайна клиента.

Разделите работу до старта

Простое разделение ролей обычно работает хорошо:

• Продажи собирают реальные экспорты и подтверждают, что клиент ожидает импортировать.
• Инженерия тестирует импортер и документирует случаи отказов.
• Customer success ведёт живой список задач по очистке и сроки выполнения.
• Один назначенный ответственный принимает решения по исключениям (например, пропустить поле или импортировать частично).

Эта последняя роль важнее, чем многие думают. Когда клиент присылает двадцать CSV в шести форматах, краевые случаи копятся быстро. Кому‑то нужно дать полномочия сказать: «Мы импортируем эти четыре файла сейчас, отклоняем эти два и просим клиента исправить остальное». Если никто не принимает такое решение, вопрос скользит между командами днями.

Customer success должен отслеживать каждый открытый пункт очистки в одном месте. Держите это просто: имя файла, проблема, владелец, статус и дедлайн. Так продажи, инженерия и клиент видят одно и то же, что блокирует импорт.

Запустите простой процесс приёма данных

Хороший процесс приёма занимает около 20 минут и может сэкономить дни позже. Он превращает «у нас есть CSV» в задачу с понятными лимитами.

Попросите у клиента два образца файлов до старта, а не полный дамп. Один файл должен показывать нормальные данные. Второй — известные «грязные» случаи. Уточните ожидаемое количество строк. Файл с 800 строками — одно дело, файл с 4 миллионами строк — другое.

Затем проверьте базовые вещи вручную:

• Используют ли заголовки понятные имена или они меняются между файлами?
• Пусты ли обязательные поля в большом количестве строк?
• Повторяются ли одни и те же контакты, заказы или компании?
• Следуют ли даты, валюты и телефоны одному формату?
• Соответствуют ли образцы согласованной области работ?

Поместите сопоставление полей в один общий шаблон. Одна колонка — исходный заголовок, другая — целевое поле. Добавьте короткие примечания с правилами вроде «оставить пустым, если неизвестно» или «сопоставлять дубликаты по email и названию компании». Если у продаж, онбординга и инженерии будут разные заметки, первый тест‑импорт обычно провалится по банальным причинам.

Отмечайте пункты очистки до начала работ. Если клиенту нужно исправить пустые поля, битые даты или дубликаты, скажите об этом заранее. Если ваша команда будет делать часть очистки, опишите точно, что вы исправите, а что нет.

Завершите согласованием объёма, сроков и запасных правил. Решите, что делать, если столбец не сопоставлен, количество строк отличается от оценки или один файл приходит позже. Процесс приёма должен закончиться ясным решением: импортировать как запланировано, импортировать после очистки или приостановить, пока клиент не исправит данные.

Реалистичный пример с двадцатью CSV

Новый аккаунт присылает двадцать CSV во вторник утром. Он хочет, чтобы контакты, сделки, счета и все заметки из старой системы были загружены до запуска.

На первый взгляд всё выглядит управляемо. Но когда команда открывает файлы, она находит пять разных форматов дат. Один файл использует 03/04/2024, другой — 2024-04-03, третий писал Apr 3 2024, а в двух остальных в одном и том же столбце смешаны день‑первый и месяц‑первый форматы.

Список компаний тоже грязный. Один и тот же клиент встречается как "North Star LLC", "NorthStar" и "North Star, LLC". Если это не поправить заранее, импорт создаст три аккаунта, три истории и множество тикетов в поддержку.

Продажи уже пообещали, что старые заметки тоже перейдут. Это обещание кажется маленьким, пока инженеры не проверят экспорт. Заметки лежат в длинных текстовых полях с временными метками, именами пользователей и тегами, слитых вместе. Нет плана сопоставления, нет правила для дубликатов и нет согласования, где эти заметки должны храниться в новой системе.

Спокойная команда сокращает область работ, прежде чем беспорядок вырастет. Они выбирают меньший набор для запуска: активные контакты, открытые сделки, неоплаченные счета, единый стандарт даты для всех файлов и очищенные названия компаний до импорта.

Это решение обычно спасает запуск.

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

Вот для чего нужен хороший чек‑лист импорта. Цель — не импортировать всё, что люди могут экспортировать. Цель — загрузить те записи, которые аккаунту нужны в первый день, сделать их чистыми и спланировать остальное без драмы.

Команды, которые делают это хорошо, редко выглядят героически. Они просто избегают недели хаоса, которая начинается, когда приходят двадцать CSV, а никто ещё не сказал «нет».

Частые ошибки, которые тормозят аккаунт

Самые медленные импорты часто начинаются с безобидной фразы: «Мы можем импортировать всё». Продажи говорят это, чтобы сохранить импульс. Инженерия получает результат позже и объясняет, почему пять форматов дат, пустые ID и несовпадающие названия аккаунтов не загружаются автоматически. Чёткие лимиты останавливают проблему на ранней стадии.

Ещё одна обычная ошибка — пропустить правило для дубликатов. Если никто не решает, как совпадать записи, команда делает догадки под давлением. Совпадать по email, внешнему ID, названию компании или по смеси полей? Выберите правило до прибытия первого файла. Иначе получите дубликаты контактов, объединённые аккаунты, которые должны оставаться отдельными, и растущую задачу по очистке.

Работу по очистке тоже часто неправильно называют «частью импорта». Это звучит невинно, пока инженеры не потратят дни на исправление битых телефонов, обрезку пробелов, разделение полного имени и удаление тестовых строк. Эта работа не бесплатна и не должна лежать в неопределённой корзине.

Кастомные поля создают тихую путаницу. Клиент просит поля вроде "Tier", "Segment 2" или "Status New", и все кивают. Потом имена меняются три раза, никто не соглашается с допустимыми значениями, и сопоставление ломается. Утвердите финальные имена полей и форматы до того, как кто‑то начнёт собирать импорт.

Последняя ошибка проявляется в неделю запуска. Команды тестируют лишь «счастливый путь» и игнорируют плохие строки до тех пор, пока дедлайн не подойдёт. Тогда пара страшных записей останавливает весь процесс. Тестируйте на «грязных» образцах рано, а не только на чистых примерах. Попросите строки с пустыми значениями, дублирующими ID, неправильными датами и дополнительными столбцами.

Простое правило помогает: если файл может упасть, решите сейчас, кто его исправляет, как вы это пометите и продолжится ли импорт или остановится.

Быстрые проверки перед стартом

Кик‑офф пройдёт лучше, если команда ответит на несколько простых вопросов до того, как клиент что‑то пришлёт.

Начните с ответственности. На каждый файл нужен один назначенный ответственный с вашей стороны и один контакт со стороны клиента. Если у файла нет владельца, никто не починит его, когда даты сломаются, заголовки изменятся или строки исчезнут.

Проверьте сопоставление. Обязательные поля должны ссылаться на реальные столбцы в образцах, а не на догадки из разговора продаж. Если ваш шаблон говорит "email", а в CSV столбец называется "primary_contact" и половина строк пустая, сопоставления нет.

Короткий предпусковой обзор должен подтвердить пять вещей:

• У каждого входящего файла есть ответственный за его проверку.
• Обязательные поля приложения соответствуют реальным столбцам в образцах.
• Количество строк и размер файлов укладываются в согласованные лимиты.
• Команда прописала, как она будет находить и объединять дубликаты.
• Видно, какие запросы выходят за рамки первоначального объёма работ.

Лимиты важнее, чем команды думают. Обещание «импортировать всё» кажется безвредным, пока один аккаунт не пришлёт двадцать файлов по 800 000 строк, с разной кодировкой и тремя годами мусора. Если продажи согласовали меньшие лимиты, инженерия сможет вовремя возразить и попросить клиента разбить работу.

Обработка дубликатов требует простого языка. Решите, будете ли вы совпадать по email, внешнему ID, номеру телефона или по комбинации. Одно предложение в письменном виде сэкономит дни переделок.

Область работ тоже должна быть на виду. Если клиент хочет очистку, дедупинг, обогащение и исторические бэфилы — вынесите это в обсуждение до старта. Скрытая работа превращает простой импорт в грязный проект.

Что делать дальше

Сведите эти правила в один общий документ по онбордингу. Сделайте его достаточно коротким, чтобы продажи его прочитали, и достаточно понятным, чтобы инженерия ему доверяла. В нём должны быть ответы на четыре вопроса без спора: какие файлы вы принимаете, как работает сопоставление, кто исправляет плохие данные и когда начинается импорт.

Дайте отделу продаж скрипт для реальных звонков. Ему не нужна красивая формулировка — нужны простые ответы про кастомные форматы CSV, частичные экспорты, отсутствующие столбцы и работу по очистке. Если продажи и инженерия используют разные слова для одного и того же импорта, передача работы сломается.

Обычно достаточно простого пакета: один документ онбординга с лимитами файлов, обязательными столбцами и областью работ; один шаблон сопоставления, который клиент заполняет до старта; и краткий скрипт продаж с утверждёнными обещаниями и красными флагами.

После этого разберите один недавний импорт, который прошёл плохо или занял слишком много времени. Не превращайте это в поиск виноватых. Ищите, где началась задержка. Может, продажи пообещали слишком много. Может, инженерия приняла файлы до утверждения сопоставления. Может, никто не владел очисткой, и клиент неделю отправлял пересмотренные CSV.

Исправьте самое слабое место первым. Маленькие изменения важны. Один обязательный шаблон может сэкономить дни переписки. Один ясный владелец очистки остановит дрейф импорта между тремя командами.

Если те же проблемы с онбордингом повторяются, внешняя помощь полезна. Oleg Sotnikov at oleg.is работает со стартапами и небольшими командами над техническими процессами, архитектурой и AI‑ориентированными операциями — такого рода передача от продаж к инженерии как раз та сложность, которую опытный внештатный CTO может упорядочить.

Когда следующий клиент пришлёт двадцать CSV, вашей команде не понадобится план спасения. У вас уже будет процесс, который говорит «да», «нет» или «ещё не готово».