SOP для переводческого агентства: как задокументировать процессы и перестать держать все в голове¶
Ваш project manager уволился в пятницу. В понедельник у вас 12 активных проектов, 8 фрилансеров ждут брифы, а вся информация о том как оформлять заказы, проверять качество и общаться с клиентами - была в его голове. Знакомая ситуация? Если да, то у вас нет SOP. А без SOP ваше агентство - это не бизнес, а просто набор людей, которые как-то работают.
Стандартные операционные процедуры (Standard Operating Procedures, SOP) - это задокументированные пошаговые инструкции для каждого повторяющегося процесса в агентстве. Не общие описания “как мы работаем”, а конкретные шаги: кто, что, когда, в каком порядке и что делать если что-то пошло не так.
Разберем, какие SOP нужны первыми, как их писать чтобы команда реально использовала, и какие инструменты упрощают этот процесс.
Зачем переводческому агентству SOP: 5 причин, которые решают реальные проблемы¶
“Мы маленькое агентство, у нас 3 человека - зачем нам процедуры?” - слышите это от себя? Вот почему SOP критичны даже для микро-агентства с 2-3 штатными и 5-10 фрилансерами.
1. Онбординг новых людей за дни, а не за месяцы. Без SOP обучение нового PM или переводчика - это “садись рядом и смотри как я делаю”. С SOP - “прочитай эти 8 документов, пройди тестовый заказ по инструкции, задай вопросы по непонятным моментам”. По данным Trainual, компании с задокументированными SOP сокращают время онбординга на 50-70%. Представьте: вместо 3 недель, когда вы лично водите новичка за руку - 4-5 дней, и он уже берет первые проекты.
2. Стабильное качество независимо от того, кто работает. Когда TEP-процесс (Translation, Editing, Proofreading) задокументирован - не имеет значения, новый переводчик или опытный. Шаги одинаковые, чеклисты одинаковые, результат предсказуемый. Клиент не должен чувствовать разницу между тем, кто именно делал перевод - он платит агентству за стабильное качество.
3. Масштабирование без хаоса. Если вы масштабируете агентство от соло-фрилансера до LSP, SOP - это фундамент. Без задокументированных процессов каждый новый проект или новый фрилансер добавляет хаос, а не revenue. Вы буквально не можете делегировать то, что не описано.
4. Подготовка к ISO 17100. ISO 17100 - международный стандарт качества переводческих услуг - прямо требует задокументированные процедуры для перевода, редактирования, управления проектами и квалификации исполнителей. Даже если сертификация не в планах прямо сейчас - построенные по ISO процессы выглядят серьезно для enterprise-клиентов и отличают вас от агентства-однодневки.
5. Защита от “bus factor”. Если завтра ваш лучший PM заболеет на неделю - кто-то другой сможет подхватить его проекты? С SOP - да. Без SOP - вы сами будете сидеть до ночи, разбираясь в чужих проектах, переписках и договоренностях.
Как указывает ISO в описании стандарта 17100:2015:
ISO 17100:2015 provides requirements for the core processes, resources, and other aspects necessary for the delivery of a quality translation service that meets applicable specifications.
Простыми словами: если хотите оказывать качественные переводческие услуги стабильно - документируйте процессы. Это не бюрократия ради бюрократии, а инструмент, который защищает вас от хаоса при росте.
8 SOP, которые нужны переводческому агентству первыми¶
Не пытайтесь задокументировать все сразу - это гарантированный способ бросить на третьем документе. Начните с 8 критичных SOP и расширяйте постепенно.
1. Прием заказа (Intake & Quoting)¶
Что покрывает: от момента когда клиент написал “мне нужен перевод” до подтверждения заказа.
Ключевые шаги: - Анализ входящего файла (формат, объем, языковая пара, сложность) - Определение типа перевода (стандартный, присяжный, MTPE) - Расчет стоимости (формула: количество слов x ставка + надбавки за срочность/сложность) - Подготовка и отправка квоты клиенту - Подтверждение заказа и внесение в систему
Что должно быть в SOP: шаблон квоты, формула расчета цены, матрица надбавок (срочность +30-100%, сложная тематика +20-40%), список вопросов которые обязательно уточнить у клиента. Без этого каждый PM будет считать по-своему, и клиент получит разные цены в зависимости от того, кто взял трубку.
2. Назначение исполнителей (Assignment)¶
Что покрывает: как выбрать правильного переводчика/редактора для конкретного проекта.
Ключевые шаги: - Проверка языковой пары и специализации - Проверка доступности (capacity и дедлайны) - Отправка брифа фрилансеру - Подтверждение от исполнителя - Фоллоу-ап если нет ответа в течение X часов
Этот SOP тесно связан с vendor management - ваша база фрилансеров должна быть структурирована так, чтобы поиск правильного исполнителя занимал минуты, а не часы. Если у вас 30 фрилансеров и нет системы тегов (языковая пара, специализация, рейтинг, загрузка) - вы каждый раз будете тратить 30-40 минут на подбор.
3. TEP-процесс (Translation, Editing, Proofreading)¶
Это сердце любого переводческого агентства. ISO 17100 требует как минимум Translation + Revision (редактирование вторым лингвистом). Proofreading - опциональный, но рекомендуемый шаг для ответственных проектов.
Ключевые шаги: - Translation: перевод первым лингвистом, самопроверка по чеклисту - Editing: билингвальная проверка вторым лингвистом (сравнение с оригиналом) - Proofreading: финальная проверка только целевого текста (стиль, форматирование, консистентность) - QA-чеки между этапами (теги, числа, термины - автоматизированные через CAT-инструменты)
Как объясняет TÜV SÜD, сертификационный орган ISO 17100:
Every translation must be revised by a second qualified linguist before final delivery.
Это не рекомендация - это требование стандарта. Ваш SOP должен четко описывать кто и что проверяет на каждом этапе, какие инструменты использовать, и какой порог ошибок допустим до передачи на следующий этап.
4. Контроль качества (QA)¶
Отдельный от TEP SOP, который покрывает техническую и лингвистическую проверку.
Ключевые шаги: - Автоматизированные QA-чеки (теги, числа, пунктуация, консистентность терминов) - Проверка соответствия глоссарию и style guide - Проверка форматирования (таблицы, headers, списки) - Финальная проверка перед отправкой клиенту - Документирование найденных ошибок для фидбека исполнителям
Для отслеживания качества используйте простые метрики: количество ошибок на 1000 слов, процент проектов с переделками, время на QA. Без метрик вы не знаете, работает ли ваш QA-процесс или просто создает иллюзию контроля.
5. Доставка и обратная связь (Delivery & Feedback)¶
Что покрывает: от финального файла до закрытия проекта.
Ключевые шаги: - Подготовка финального файла (формат, naming convention) - Отправка клиенту с сопроводительным письмом - Сбор обратной связи от клиента (простой вопрос “все ли устроило?” - уже что-то) - Обработка запросов на изменения (если есть) - Закрытие проекта в системе, выставление счета
Многие агентства пропускают шаг с обратной связью - и зря. Это единственный способ узнать о проблемах до того, как клиент молча уйдет к конкуренту.
6. Онбординг фрилансера (Vendor Onboarding)¶
Что покрывает: от первого контакта с потенциальным фрилансером до его добавления в активный пул.
Ключевые шаги: - Проверка квалификации (образование, опыт, сертификаты) - Тестовое задание (250-500 слов в профильной паре) - Оценка тестового по стандартизованной шкале - Подписание NDA и рамочного договора - Добавление в базу с тегами (языковая пара, специализация, рейтинг, ставка) - Отправка welcome pack (style guides, глоссарии, инструкции к инструментам)
Без этого SOP каждый новый фрилансер - это лотерея. Вы не знаете, какого уровня работу получите, пока не увидите первый проект. А к тому моменту клиент уже ждет результат.
7. Эскалация и решение проблем (Escalation)¶
Что покрывает: что делать когда что-то пошло не так.
Типичные сценарии: - Фрилансер не сдает работу вовремя - Клиент жалуется на качество - Ошибка в доставленном переводе (юридическая, фактическая, терминологическая) - Фрилансер исчезает посреди проекта - Клиент меняет scope после старта
Для каждого сценария SOP должен описывать: кто принимает решение, какие шаги, какие таймлайны, какая коммуникация с клиентом. Самое главное - не паниковать, а действовать по процедуре. Паника обходится дороже любой ошибки.
8. Выставление счетов и оплата фрилансерам (Billing)¶
Что покрывает: финансовый цикл от инвойса клиенту до оплаты исполнителям.
Ключевые шаги: - Генерация инвойса клиенту (автоматически по завершении проекта или по графику) - Отслеживание оплаты клиентом (кто контролирует просрочки и когда отправлять напоминание) - Расчет оплаты фрилансерам за период - Выплата фрилансерам (net-15, net-30 - зависит от договоренности) - Сверка с бухгалтерией
Это напрямую связано с управлением денежным потоком - без четкого SOP по биллингу легко попасть в кассовый разрыв. Особенно если клиент платит net-60, а фрилансерам нужно заплатить net-30.
Приоритизация: с чего начать¶
Если 8 SOP кажутся неподъемными - вот порядок, который дает максимальный эффект при минимальных усилиях:
| Приоритет | SOP | Почему первый |
|---|---|---|
| 1 | TEP-процесс | Качество = репутация = клиенты. Без этого все остальное не имеет смысла |
| 2 | Прием заказа | Стандартизирует коммуникацию с клиентом, уменьшает ошибки в квотах |
| 3 | QA | Ловит ошибки до того как их увидит клиент |
| 4 | Онбординг фрилансеров | Масштабирование начинается с правильных людей |
| 5 | Назначение исполнителей | Скорость реакции = конкурентное преимущество |
| 6 | Доставка и фидбек | Закрывает цикл проекта, собирает данные для улучшений |
| 7 | Эскалация | Готовит к кризисным ситуациям до того как они случатся |
| 8 | Биллинг | Финансы должны быть в порядке, но это обычно уже как-то работает |
Реалистичный план: 1-2 SOP в неделю, начните с TEP. За месяц у вас будут 4-8 задокументированных процедур - этого достаточно для стабильной работы агентства с 5-15 фрилансерами. Не пытайтесь сделать идеально с первого раза - первая версия SOP всегда будет несовершенной, и это нормально. Лучше несовершенный SOP, чем никакого.
Как написать SOP, который команда реально будет использовать¶
Главная проблема с SOP не в том, чтобы их написать. Проблема в том, чтобы команда их читала и придерживалась. SOP который никто не открывает - хуже чем отсутствие SOP, потому что создает иллюзию контроля.
Формат: просто, коротко, с примерами¶
Каждый SOP должен содержать 7 элементов:
- Название и цель - одно предложение: “Этот SOP описывает процесс приема нового заказа от клиента”
- Scope - к чему применяется: “Все заказы кроме recurring проектов с рамочным договором”
- Ответственный - кто выполняет: “Project Manager”
- Триггер - когда запускается: “Клиент отправляет запрос на перевод через email/форму/чат”
- Шаги - пронумерованные действия, максимально конкретные
- Чеклисты - что проверить перед завершением каждого шага
- Что делать если - edge cases и эскалации
Золотое правило: если в SOP нет конкретных цифр (таймлайнов, порогов, процентов) - это не SOP, а пожелание. “Ответить быстро” и “ответить в течение 2 часов” - разница между декларацией и инструкцией.
Пример: SOP для приема заказа (сокращенно)¶
Триггер: Клиент отправил запрос на перевод.
Шаг 1. Ответь на запрос в течение 2 часов в рабочее время (8:00-18:00 CET). Если запрос пришел после 18:00 - следующим рабочим утром до 10:00.
Шаг 2. Проанализируй файл: - [ ] Формат (docx/pdf/скан/фото) - [ ] Языковая пара - [ ] Количество слов (Tools → Word Count в Trados/MemoQ, или считай вручную для сканов) - [ ] Тематика (юридическая/медицинская/техническая/общая) - [ ] Нужен ли присяжный/заверенный перевод
Шаг 3. Рассчитай стоимость: - Базовая ставка: [ссылка на внутренний прайс] - Надбавки: срочность (<24 ч +50%, <4 ч +100%), сложная тематика (+25%), сканированный документ (+15%) - Скидка для recurring клиентов: [ссылка на таблицу скидок]
Шаг 4. Отправь квоту через [шаблон в email/CRM]. Укажи: стоимость, срок выполнения, что входит (TEP), формат доставки.
Если клиент просит скидку - эскалируй на Senior PM или владельца если скидка > 15%.
Если файл нечитаемый - сообщи клиенту в течение 1 часа и запроси лучшее качество.
Обратите внимание: каждый шаг содержит конкретные цифры (2 часа, 50%, 15%) и конкретные действия. Не “как можно быстрее проанализируйте”, а “в течение 2 часов”. Именно это делает SOP работающим инструментом, а не декоративным документом.
Три формата SOP¶
Не все процессы требуют одинакового формата:
| Формат | Когда использовать | Пример |
|---|---|---|
| Пошаговый список | Линейные процессы с фиксированной последовательностью | Прием заказа, доставка |
| Блок-схема (flowchart) | Процессы с ветвлениями и условиями | Эскалация, QA (если ошибка критическая → один путь, некритическая → другой) |
| Чеклист | Проверки где порядок не критичен | QA перед доставкой, онбординг фрилансера |
Для блок-схем используйте Miro или Whimsical - оба имеют бесплатные тарифы. Встраивайте визуальную схему в начало SOP, а ниже - текстовую версию для тех кто ищет конкретный шаг. Так вы покроете и тех кто предпочитает визуал, и тех кто ищет по ctrl+F.
Как рекомендует Asana в своем гиде по SOP:
Choose where your SOP will live - whether in a shared Google Doc or Drive, a company wiki like Notion or Confluence, or dedicated SOP software. Your SOP should be accessible right when it’s needed, not buried in a random folder.
Практический совет: создайте главную страницу “SOP Hub” со списком всех процедур, сгруппированных по категориям (Продажи, Операции, Качество, Финансы). Каждый член команды должен знать где эта страница - и она должна быть на расстоянии одного клика. Не в папке внутри папки внутри Google Drive, а на главной странице вашей wiki.
Инструменты для создания и хранения SOP¶
SOP не живет в Google Doc, который никто не может найти в общей папке с 200 файлами. Нужно место где команда быстро находит нужную процедуру.
Сравнение инструментов¶
| Инструмент | Цена/юзер/мес | Для кого | Плюсы | Минусы |
|---|---|---|---|---|
| Notion | $0-10 | Агентства 2-15 человек | Гибко, красиво, есть шаблоны, можно строить wiki | Может быть слишком гибким - нужна дисциплина структуры |
| Confluence | $5.42+ | Агентства 5-50+ человек | Мощный поиск, версионирование, интеграция с Jira | Сложнее в настройке, интерфейс менее интуитивный |
| Process Street | $25+ | Агентства с повторяющимися workflow | Чеклисты с автоматизацией, трекинг выполнения | Дорого для маленьких команд |
| Google Docs + Drive | $0-6 | Микро-агентства 1-3 человека | Бесплатно, все умеют пользоваться | Сложно поддерживать структуру при росте, нет версионирования “из коробки” |
| Waybook | $83/мес | Агентства с фокусом на онбординге | Специализирован под SOP и тренинг, трекинг прохождения | Нишевый, менее известный, дороговат для старта |
Для агентства на стадии 2-3 (5-20 фрилансеров) Notion - оптимальный выбор: бесплатного тарифа достаточно для начала, структура wiki позволяет организовать SOP логично, а шаблоны баз данных помогут связать SOP с проектами и людьми. По мере роста до 20+ человек имеет смысл смотреть на Confluence или Process Street.
Типичные ошибки при создании SOP¶
1. Писать SOP “для себя”¶
Автор SOP знает контекст и пропускает “очевидные” шаги. Но для нового PM шаг “проверь файл” ничего не значит. Какой файл? Где он лежит? Что именно проверять? Правило: напишите SOP так, чтобы человек без опыта в переводе мог выполнить процедуру с первого раза. Дайте прочитать кому-то другому из команды - если есть вопросы, SOP недостаточно детальный.
Хороший тест: попросите нового сотрудника пройти SOP самостоятельно и записать все места, где он застрял или не понял что делать. Каждое такое место - дыра в вашем SOP.
2. Написать один раз и забыть¶
SOP - живой документ. Процессы меняются: новые инструменты, новые клиенты, новые типы проектов. Как отмечает VisualSP:
Revising your SOPs every 6 or 12 months is a must if you want to stay on top of all the changes and keep on delivering the best possible results.
Поставьте напоминание в календаре на ревизию SOP каждые 6 месяцев. Назначьте ответственного за каждый SOP - PM для операционных, QA lead для качественных, owner для финансовых. Если за SOP никто не отвечает лично - его никто не обновит.
3. Чрезмерная детализация¶
SOP на 15 страниц никто не прочитает. Оптимальная длина - 1-3 страницы для простого процесса, 3-5 для сложного (как TEP). Если SOP выходит длиннее - разбейте на несколько отдельных SOP. Например, вместо одного монструозного “Управление проектом от А до Я” - отдельные SOP на прием, назначение, TEP, доставку. Каждый можно открыть и пройти за 5 минут.
4. Не включать edge cases¶
SOP который описывает только “happy path” (когда все идет по плану) - бесполезен. Добавьте секции “Что делать если”: клиент отменил заказ после начала работы, фрилансер сдал с опозданием, файл оказался в другом формате, клиент не отвечает на уточнения в течение 48 часов. Именно edge cases - то, ради чего SOP и нужен. В обычной ситуации большинство людей и так справятся.
5. Нет метрик¶
Как понять что SOP работает? Добавьте к каждому SOP 1-2 KPI: время на обработку заказа, процент проектов без переделок, время онбординга нового фрилансера. Без метрик вы не знаете помогает SOP или мешает - а может, его вообще никто не использует, и вы просто тешите себя мыслью что “у нас все задокументировано”.
Ревизия и поддержка SOP: процесс для процесса¶
Создать SOP - половина дела. Поддерживать актуальным - вторая, и часто более сложная. Вот как организовать цикл ревизии, чтобы SOP не превращались в артефакты прошлого.
Ежемесячно: сбор фидбека от команды¶
Раз в месяц спрашивайте команду: “Какие SOP вы использовали в этом месяце? Где были проблемы? Что непонятно?” Это можно делать асинхронно через форму или Slack-канал #sop-feedback. Не надо устраивать часовое совещание - простая Google-форма с тремя вопросами даст вам 80% полезной информации.
Ключевые вопросы: - Какой SOP вы открывали чаще всего? - Был ли момент когда SOP не покрывал вашу ситуацию? - Есть ли шаг, который описан неточно или устарел?
Каждые 6 месяцев: полная ревизия¶
Пересмотр каждого SOP: актуальны ли шаги, изменились ли инструменты или расценки, появились ли новые edge cases. Ревизию делает не автор - а человек, который реально использует этот SOP в работе. Автор слишком близок к документу и пропустит неочевидные проблемы.
При смене инструментов или процессов: немедленное обновление¶
Перешли с MemoQ на Phrase? SOP по TEP-процессу должен быть обновлен ДО того как команда начнет работать в новом инструменте. Не “мы потом обновим” - потом никогда не наступит, а команда будет работать по памяти, каждый по-своему.
Версионирование¶
Каждое обновление SOP - новый номер версии (v1.0 → v1.1 → v2.0 для крупных изменений). Notion и Confluence делают это автоматически через историю страницы. В Google Docs - используйте “Version history”. Версионирование нужно не для красоты, а чтобы при разборе проблемы можно было сказать: “на момент инцидента действовала версия 1.3, в которой этот кейс не был описан - добавлено в версии 1.4”.
SOP + бизнес-план: как это работает вместе¶
SOP - это не отдельный проект “на потом”. Это операционная часть вашего бизнес-плана.
Если вы на стадии масштабирования от соло-фрилансера до агентства - SOP вам нужны уже на стадии 2 (микро-агентство). Без них вы не сможете делегировать качество, а без делегирования - не сможете расти. Это ловушка: вы застрянете на этапе “всю работу делаю сам” навсегда.
Если планируете сертификацию ISO 17100 - SOP прямое требование аудита. Аудитор спросит: “Покажите ваш задокументированный TEP-процесс. Покажите как вы отбираете и квалифицируете переводчиков. Покажите как обрабатываете жалобы клиентов.” Без SOP - аудит не пройти. С SOP, написанными по нашей структуре - у вас уже будет 80% необходимой документации.
Если отслеживаете KPI агентства - SOP определяет ЧТО измерять и КАК. Метрика “время от получения заказа до отправки квоты” имеет смысл только когда есть SOP с конкретными тайм-фреймами для каждого шага. Иначе с чем сравнивать?
Связка работает и в обратную сторону: бизнес-план определяет стратегию, SOP - тактику. Без стратегии SOP будут описывать хаотичные процессы. Без SOP стратегия останется на бумаге.
FAQ¶
Сколько времени занимает создание одного SOP?¶
Зависит от сложности процесса. Простой SOP (доставка файла клиенту) - 1-2 часа. Средний (прием заказа со всеми edge cases) - 3-4 часа. Сложный (TEP-процесс с описанием всех этапов, чеклистами и ветвлениями) - 4-8 часов. На полный набор из 8 базовых SOP реалистично закладывать 20-40 часов работы, распределенных на 4-6 недель. Не пытайтесь написать все за один выходной - выгорите и бросите.
Нужно ли писать SOP на английском если команда русскоязычная?¶
Если вся команда говорит на одном языке - пишите на этом языке. SOP должны быть максимально понятными, а не “международными”. Если планируете нанимать фрилансеров из разных стран - сделайте ключевые SOP (TEP, QA, эскалация) на двух языках. Отраслевые термины (TEP, QA, TM, CAT, MTPE) оставляйте на английском - они и так стандарт индустрии, и переводить их на русский будет только запутывать.
Какие SOP нужны для сертификации ISO 17100?¶
ISO 17100 требует задокументированные процедуры для: управления переводческими проектами, отбора и квалификации переводчиков и ревайзеров, TEP-процесса, обработки обратной связи от клиентов, и корректирующих действий при проблемах. По сути - это те же 8 SOP из нашего списка, оформленные по требованиям стандарта. Если вы напишете их по структуре из этой статьи и добавите формальные элементы (номер документа, дата утверждения, подпись ответственного) - вы будете готовы к аудиту на 80%.
Можно ли использовать AI для написания SOP?¶
AI (ChatGPT, Claude) может помочь со структурой и первым черновиком - это экономит 30-50% времени на этапе создания. Но финальный SOP должен писать или утверждать человек, который реально выполняет этот процесс. AI не знает ваших внутренних инструментов, ваших клиентов и ваших edge cases. Используйте AI как стартовую точку: скормите ему описание процесса, попросите структурировать в формат SOP, а потом дополняйте конкретикой. Не используйте AI-текст как финальный результат - он будет слишком общим.
Сколько SOP нужно агентству с 5 фрилансерами?¶
Для агентства с 1-2 штатными и 5 фрилансерами достаточно 4-6 базовых SOP: TEP-процесс, прием заказа, QA, онбординг фрилансера. Добавляйте новые по мере того как появляются повторяющиеся проблемы. Простое правило: если что-то пошло не так дважды по одной и той же причине - это сигнал что нужен SOP. Не документируйте процессы которые случаются раз в год - это пустая трата времени.
Как убедить команду следовать SOP?¶
Первое - привлекайте команду к написанию. SOP написанный “сверху” без участия исполнителей - это документ для полки, не для работы. Люди охотнее следуют правилам, которые сами помогали создавать. Второе - начинайте с процессов где болит больше всего: если команда каждую неделю тратит время на исправление одних и тех же ошибок - SOP для QA решит эту боль и команда почувствует реальную пользу. Третье - не наказывайте за несоблюдение SOP, а разбирайте почему не соблюдали. Часто причина в том, что SOP неудобный или не покрывает реальную ситуацию - тогда нужно менять SOP, а не людей.