Laurel — платформа work intelligence для компаний в сфере профессиональных услуг. С её помощью компании автоматизируют учёт времени, понимают, что влияет на прибыльность, и подтверждают ROI инвестиций в AI. До недавнего времени продукт был доступен только на английском. Сегодня он поддерживает больше дюжины языков — скандинавские языки, французский, нидерландский, португальский, испанский, корейский, — а мандаринский, тайский, арабский, японский и вьетнамский уже в пайплайне.

Интеграция у Laurel прошла без лишних сложностей: большая часть работы была на их стороне — нужно было извлечь и упорядочить существующие строки, чтобы подготовить кодовую базу. Альтернатива в виде собственной разработки оценивалась в четыре–шесть месяцев инженерного времени, плюс постоянная поддержка без конечной точки. В итоге стало ясно: полная стоимость отказа от покупки примерно в 10 раз выше стоимости покупки, если учитывать сделки, которые могли бы сорваться. Теперь новый язык можно добавить за один день — и продакт-менеджер способен сделать это самостоятельно. Ещё восемнадцать месяцев назад такая фраза звучала бы абсурдно.

«Мне понравилось, как команда Lingo.dev включилась в работу, поняла наши задачи и предложила решения. Нам не пришлось строить инфраструктуру локализации — они закрыли этот вопрос идеально. Enterprise-прайсинг был адекватным, и у нас есть общий канал в Slack с их инженерами. На нестандартные кейсы они реагируют за считаные часы.»

— Nick Bazley, Staff Product Manager, Laurel

Когда SaaS-компании стоит инвестировать в локализацию?#

Nick Bazley — Staff Product Manager в Laurel. Последние шесть лет он руководит продуктовыми командами, пока компания масштабирует продукт на глобальный рынок. О локализации он начал задумываться примерно за год до того, как до неё действительно дошло дело.

«Мы понимали, что в какой-то момент нам придётся этим заняться, — говорит Nick. — Вопрос был только в том, когда. Каждый раз, когда мы это обсуждали, вывод был один и тот же: это будет проект уровня XXL, он займёт уйму времени, и мы не сможем до конца предсказать качество результата».

Laurel росла и переходила от клиентов среднего сегмента к глобальным enterprise-компаниям. Постепенно вырисовался повторяющийся сценарий: клиент подключается в одном регионе, видит ценность, а затем хочет масштабировать использование на другие регионы.

По мере того как команда продаж росла по всей Европе, а customer success обрабатывала запросы на расширение, Nick видел, что проблема уже на подходе.

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

Почему инфраструктуру локализации лучше купить, а не строить самим?#

У Laurel было два варианта: купить или строить. Собственная разработка, скорее всего, растянулась бы на несколько кварталов, а внутренняя оценка относила её к проекту уровня XXL — четыре–шесть месяцев инженерного времени. «Брать на себя затраты, сроки и усилия по созданию собственной инфраструктуры локализации — не самое разумное решение. Для бизнеса на той стадии роста, на которой мы тогда были, правильнее было купить лучшее решение на рынке и сосредоточиться на развитии нашей основной платформы».

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

«Мы не эксперты в инфраструктуре локализации. Мы не знаем, каким окажется качество. Зачем брать на себя такой риск, если кто-то уже построил целый бизнес вокруг localization engineering?»

Как оценивать платформу локализации в сравнении с legacy TMS#

Nick быстро изучил рынок через Perplexity Pro, просмотрел верхние результаты и нашёл legacy TMS. Отдельный поиск в Google дал ещё несколько вариантов, а Head of Engineering в Laurel независимо от этого тоже вышел на Lingo.dev.

Он запустил параллельную оценку обоих вариантов.

«На поверхности эта legacy TMS выглядела как очень отполированный, крепкий бизнес, — говорит Nick. — Но когда мы копнули глубже и сравнили то, что есть у них, с тем, что нужно нам, для той скорости и того качества, к которым мы стремились, выбор был только один».

«Мне понравилось, как Lingo.dev включились в работу: поняли наши задачи, поняли, чего мы хотим добиться, и предложили решения. Enterprise-прайсинг был адекватным. А обещание скорости и качества стало ключевым фактором. Больше всего выделялся уровень доступа. У нас есть общий канал в Slack с инженерами, которые реально строят платформу. Когда мы сталкиваемся с нестандартным кейсом, ответ приходит за считаные часы. Иногда кажется, будто они часть нашей команды».

Насколько точна AI-локализация для юридической и бухгалтерской терминологии?#

Пользователи Laurel — специалисты в сфере права и бухгалтерии. Если в немецком интерфейсе неверно переведены «billing rate» или «matter», это не просто выглядит неудачно — это подрывает доверие ко всему продукту. Юридическая и бухгалтерская терминология должна быть безупречно точной.

Nick проверял качество на реальных клиентах. Первый проход отправили клиентам из стран Северной Европы и одному французскому клиенту. У скандинавской команды не было вообще никаких замечаний. Французский клиент, носитель языка, нашёл только две неточности — команда сразу добавила их в глоссарий. С тех пор не возникало проблем ни с нидерландским, ни с португальским, ни с испанским и другими языками.

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

«Мы уже давно не возвращались в глоссарий, чтобы что-то там подкрутить», — говорит Nick.

Сколько времени нужно, чтобы добавить новый язык в SaaS-продукт?#

Когда менеджер customer success видел, что клиенту нужен португальский в интерфейсе, раньше такой запрос попадал в дорожную карту, проходил приоритизацию, ждал своего спринта и занимал недели.

Теперь Nick создаёт тикет, берёт за шаблон предыдущий тикет на добавление языка, направляет на него AI Tooling — и ждёт. Дальше инструменты добавляют язык в конфигурацию, обновляют переключатель языков и открывают PR. Инженер проверяет PR и отправляет его в релиз, а Lingo.dev берёт непрерывную локализацию на автопилот.

«Один день — это полный цикл: от составления тикета до готового PR. Это не значит, что я весь день только этим и занимаюсь. Большую часть времени я параллельно делаю другие задачи».

С AI-инструментами для написания кода и инфраструктурой локализации от Lingo.dev Nick может добавлять новый язык без привлечения инженерного ресурса.

«С Lingo.dev теперь любой в компании может добавлять новые языки и настраивать наши движки локализации. Это действительно впечатляет».

Как скорость локализации влияет на скорость enterprise-сделок?#

Бизнес-кейс здесь не только в экономии инженерного времени — хотя и в этом тоже. Главное, что мы можем быстро реагировать на новые возможности для масштабирования.

«С enterprise-клиентами возможность для расширения может появиться очень быстро, — говорит Nick. — Клиент получает первые результаты в новом офисе и хочет масштабироваться дальше, если мы можем оперативно выпустить продукт на его языке. Нам нужно уметь реагировать с такой скоростью без лишних проблем, чтобы продолжать расти».

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

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

Стоит ли строить инфраструктуру локализации самим или лучше купить?#

Когда Nick спрашивают, что бы он посоветовал VP Product в похожей компании — enterprise B2B, профессиональные пользователи, глобальная экспансия, инженерная команда и без того загружена реальной продуктовой работой, — он не колеблется.

«Я на 100% выбрал бы вендора».

Вот что чаще всего недооценивают, когда решают строить всё сами: «Сложность и качество. Ты не знаешь, каким будет качество. Зачем брать на себя такой риск?»

А вот в чём легко ошибиться при выборе вендора: недостаточно чётко понимать собственную задачу, чтобы выбрать правильного партнёра. «По-настоящему понять, какую проблему ты решаешь, и выбрать под неё правильного вендора — вот что критически важно».

Что тестировать в первую очередь: «Скорость и time to market. А после начальной настройки — скорость и масштабируемость».

Во что на самом деле обходится ожидание#

Первичная настройка в основном была на стороне Laurel: нужно было подготовить технологический стек. Дальше — один день на каждый новый язык, без инженерного спринта и без торга за место в дорожной карте.

Альтернатива — три–четыре месяца инженерного времени на разработку, бесконечная поддержка и качество, которое они не могли гарантировать для языков, на которых в команде никто не говорит.

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

Что это значит для продуктовых команд, выходящих на новые рынки#

Опыт Laurel отражает типичную для B2B SaaS-компаний с международным спросом со стороны enterprise-клиентов ситуацию: локализация перестаёт быть просто запросом на новую функцию и становится ограничением для роста. Вопрос уже не в том, «нужна ли нам локализация?», а в том, «как быстро мы сможем сказать “да” следующему рынку?»

Подход Laurel определили три фактора: команда не могла позволить себе тратить инженерные ресурсы на инфраструктуру, которая не относится к их основному продукту. А качество юридической и бухгалтерской терминологии нужно было не принимать на веру, а проверять.

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

Laurel создаёт AI для специалистов в сфере права и бухгалтерского учёта. Компания выпускает продукт более чем на дюжине языков — и может добавить ещё один всего за день. Их инфраструктура локализации работает на Lingo.dev.

Часто задаваемые вопросы#

Сколько времени занимает добавление нового языка в SaaS-продукт?

Laurel добавляет новый язык примерно за один день — от начала до конца. Менеджер продукта создаёт тикет, ссылаясь на предыдущее добавление языка, направляет на него AI-агента для написания кода, а инженер проверяет PR. Без отдельного спринта, без координации с подрядчиком. Прежняя альтернатива — строить инфраструктуру локализации своими силами — оценивалась в четыре–шесть месяцев до запуска хотя бы одного языка.

Стартапу стоит разрабатывать инфраструктуру локализации самостоятельно или купить готовое решение?

Staff PM Laurel Ник Базли сравнивал два варианта: разрабатывать своими силами или покупать готовое решение. Его вывод: «Мы не эксперты в инфраструктуре локализации. Мы не знаем, каким будет качество. Зачем брать на себя этот риск, если кто-то уже построил целый бизнес вокруг localization engineering?» По оценке команды, собственная разработка превратилась бы в XXL-проект и заняла бы половину инженерной команды на месяцы.

Насколько точна AI-локализация для профессиональной терминологии?

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

Как скорость локализации влияет на цикл enterprise-продаж?

Опыт Laurel показывает: enterprise-клиенты, которым нужна поддержка нового языка, ждут ответа в течение дней, а не месяцев. Как объясняет Ник Базли: «Возможность не ждёт долго. Если мы не сможем уложиться в неделю, это окно может закрыться». После перехода на инфраструктуру локализации Laurel добавила семь языков за шесть месяцев — каждый менее чем за день.

Как выглядит сравнение затрат между собственной разработкой и покупкой решения для локализации?

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