Laurel je platforma pro work intelligence v oblasti profesionálních služeb. Firmy Laurel používají k automatizaci vykazování času, lepšímu pochopení toho, co ovlivňuje ziskovost, a k prokázání ROI svých investic do AI. Ještě donedávna byl produkt dostupný jen v angličtině. Dnes funguje ve více než desítce jazyků – v severských jazycích, francouzštině, nizozemštině, portugalštině, španělštině i korejštině – a v pipeline jsou mandarínština, thajština, arabština, japonština a vietnamština.

Integrace na straně Laurelu byla přímočará – většina práce spočívala v tom, že si na své straně vytáhli a uspořádali existující řetězce, aby připravili codebase. Varianta vlastního vývoje vycházela na čtyři až šest měsíců inženýring práce a k tomu průběžnou údržbu bez konce. Ukázalo se, že celkové náklady na to řešení nekoupit byly zhruba 10× vyšší než náklady na jeho pořízení, jakmile započítáte obchody, které by jinak nevyšly. Dnes trvá přidání nového jazyka jeden den – a produktový manažer to zvládne sám. Ještě před osmnácti měsíci by to znělo absurdně.

"Oceňoval jsem, jak Lingo.dev přišli, pochopili naše problémy a navrhli řešení. Nemuseli jsme budovat lokalizační infrastrukturu – vyřešili to perfektně. Enterprise pricing byl férový a jsme s jejich inženýry ve sdíleném Slack kanálu. Obrat u edge casů je v řádu hodin."

– Nick Bazley, Staff Product Manager, Laurel

Kdy by měla SaaS firma investovat do lokalizace?#

Nick Bazley je Staff Product Manager ve společnosti Laurel, kde posledních šest let vede produktové týmy při globálním škálování produktu. O lokalizaci přemýšlel zhruba rok, než na ni skutečně došlo.

"Věděli jsme, že to budeme muset dřív nebo později udělat," říká Nick. "Jenže kdy? Kdykoli jsme o tom mluvili, závěr byl vždy stejný: bude to XXL projekt, bude to trvat věčnost a nebudeme mít jistotu, jaká bude kvalita výstupu."

Laurel rostl a posouval se od zákazníků ve středním segmentu k globálním enterprise firmám. Začal se opakovat stejný vzorec: získat zákazníka v jednom regionu, prokázat hodnotu a pak přijde požadavek na expanzi do dalších regionů.

Jak obchodní tým rozšiřoval působení po Evropě a customer success řešil požadavky na expanzi, Nick viděl, že se blíží problém.

"V době, kdy bylo potřeba se do toho pustit, nás bylo asi 50. Budovat si vlastní lokalizační infrastrukturu by byl velký zásah – půlka týmu by na měsíce vypadla, přitom je spousta dalších věcí, které potřebujeme pro zákazníky stavět."

Proč lokalizační infrastrukturu koupit místo vlastního vývoje?#

Laurel stál před dvěma možnostmi: koupit, nebo postavit. Vlastní vývoj by s velkou pravděpodobností znamenal práci na několik kvartálů, interně odhadovanou jako XXL projekt – čtyři až šest měsíců inženýring času. "Není chytré brát na sebe náklady, čas a úsilí spojené s budováním vlastní lokalizační infrastruktury. Rozumná volba pro firmu v naší fázi růstu byla koupit nejlepší řešení na trhu a místo toho se soustředit na vývoj naší core platformy."

V téhle debatě se rozhodnutí nakonec lámalo na čtyřech věcech: rychlosti uvedení na trh, škálovatelnosti po spuštění, přizpůsobitelnosti a kvalitě.

"Nejsme experti na lokalizační infrastrukturu. Nevíme, jaká bude kvalita. Proč tohle riziko podstupovat, když někdo jiný vybudoval celý byznys kolem lokalizačního inženýringu?"

Jak vyhodnocovat lokalizační platformu oproti legacy TMS#

Nick si trh zmapoval rychlým hledáním přes Perplexity Pro, prošel první výsledky a narazil na legacy TMS. Samostatné hledání na Googlu přineslo ještě několik dalších možností a Laurelův Head of Engineering mezitím nezávisle narazil na Lingo.dev.

Obě varianty pak vyhodnocoval paralelně.

"Ten legacy TMS na první pohled vypadal jako opravdu uhlazený a solidní byznys," říká Nick. "Ale když jsme se podívali pod povrch na to, co mají a co jsme potřebovali my, byla z hlediska rychlosti a kvality, o které jsme usilovali, jen jedna správná volba."

"Oceňoval jsem, jak Lingo.dev přistoupili k věci – pochopili naše problémy, co se snažíme udělat, a přišli s řešeními. Enterprise pricing byl férový. A právě příslib rychlosti a kvality byl hlavním faktorem rozhodnutí. Co opravdu vyčnívalo, byl přístup. Jsme ve sdíleném Slack kanálu s inženýry, kteří platformu skutečně staví. Když narazíme na edge case, obrat je v řádu hodin. Skoro to působí, jako by byli součástí naší organizace."

Jak přesná je AI lokalizace pro právní a účetní terminologii?#

Uživatelé Laurelu jsou profesionálové z právní a účetní oblasti. Německé UI, které použije špatné slovo pro "billing rate" nebo "matter", nevypadá jen špatně – podkopává důvěru v celý produkt. Právní a účetní terminologie musí být naprosto přesná.

Nick testoval kvalitu se skutečnými zákazníky. První verze šla k severským zákazníkům a jednomu francouzskému zákazníkovi. Severský tým neměl žádnou zpětnou vazbu. Francouzský zákazník, rodilý mluvčí, našel jen dvě nepřesnosti: tým je okamžitě přidal do glosáře. Od té doby se v nizozemštině, portugalštině, španělštině atd. neobjevily žádné problémy.

Kvalitu jsme během šesti měsíců testovali ve 12 jazycích s rodilými mluvčími z řad zákazníků. Celkový počet nahlášených terminologických problémů: dva, oba vyřešené ještě ten samý den doplněním glosáře. Ukázalo se, že lokalizační engine s nakonfigurovaným glosářem vytvářel konzistentnější právní terminologii, než by přineslo budování překladové logiky od nuly – protože engine vynucuje termíny napříč všemi jazykovými páry současně, což manuální proces nedokáže zaručit.

"Už nějakou dobu jsme se nemuseli do glosáře vracet a nic upravovat," říká Nick.

Jak dlouho trvá přidat nový jazyk do SaaS produktu?#

Když customer success manager nahlásí, že zákazník potřebuje v UI portugalštinu, takový požadavek dřív skončil na roadmapě, dostal prioritu, čekal na sprint a zabral týdny.

Teď Nick vytvoří ticket, odkáže na předchozí ticket pro přidání jazyka jako na šablonu, nasměruje na něj AI Tooling a čeká. Tooling pak přidá jazyk do configu, aktualizuje přepínač jazyků a otevře PR. Inženýr provede kontrola, PR se nasadí a Lingo.dev se postará o průběžnou lokalizaci na autopilota.

"Jeden den je end to end – od sepsání ticketu po dokončení PR. Neznamená to, že na tom pracuji celý den. Většinu toho času dělám jiné věci."

S AI coding nástroji a lokalizační infrastrukturou Lingo.dev může Nick přidat jazyk bez inženýring kapacity.

"S Lingo.dev teď může ve firmě kdokoli přidávat nové jazyky a ladit naše lokalizační engines. To je dost pozoruhodné."

Jak rychlost lokalizace ovlivňuje tempo enterprise obchodů?#

Byznysový argument nestojí na úspoře inženýring času – i když i tu přináší. Jde o to mít jistotu, že dokážeme rychle reagovat na nové příležitosti k expanzi.

"U enterprise zákazníků se příležitost k expanzi může objevit rychle," říká Nick. "Naši zákazníci získají určitou trakci v nové pobočce a chtějí se tam rozšířit, pokud dokážeme rychle dodat produkt v jejich jazyce. Musíme být schopni reagovat bez problémů touto rychlostí, abychom mohli dál růst."

Laurel začal s pěti severskými jazyky a francouzštinou, aby podpořil svou první evropskou expanzi. Od té doby si obchod a customer success vyžádaly portugalštinu, španělštinu a nizozemštinu – a teď probíhají jednání o mnoha dalších jazycích s tím, jak expandujeme napříč globálními pobočkami.

Spočítali jsme to: během šesti měsíců po integraci Laurel přidal sedm jazyků v reakci na požadavky zákazníků na expanzi. Každý zabral méně než den. V modelu, kdy bychom si všechno stavěli sami, by těchto sedm jazyků spotřebovalo přibližně 28 inženýring sprintů – kapacitu, která místo toho šla do core produktových funkcí.

Měli byste lokalizační infrastrukturu vyvíjet, nebo koupit?#

Když dostal otázku, co by řekl VP Product v podobné firmě – enterprise B2B, profesionální uživatelé, globální expanze, inženýring tým se skutečnou produktovou prací – Nick ani na chvíli nezaváhal.

"Já bych šel na 100 % do dodavatele."

To, co by při vlastním vývoji podcenili: "Komplexita a kvalita. Nevíte, jaká ta kvalita bude. Proč to riziko podstupovat?"

To, co by pokazili při výběru dodavatele: neporozuměli by dostatečně dobře vlastnímu problému, aby vybrali toho správného. "Opravdu porozumět problému, který řešíte, a vybrat správného dodavatele pro ten konkrétní problém – to je zásadní."

Co testovat nejdřív: "Rychlost a time to market. A pak, jakmile máte hotové počáteční nastavení, jde o rychlost a škálovatelnost."

Kolik ve skutečnosti stojí čekání#

Počáteční nastavení bylo z velké části na straně Laurelu – připravit tech stack. Pak už to bylo jednoduché: den na jazyk, žádný inženýring sprint, žádné vyjednávání o roadmapě.

Alternativou byly tři až čtyři měsíce inženýring práce na vývoj, průběžná údržba napořád a kvalita, kterou nemohli zaručit v jazycích, kterými nikdo v týmu nemluví.

Nick to shrnuje jednoduše: "Lokalizační infrastruktura není projekt, který dokončíte a jdete dál. Je to průběžná věc – pokaždé, když škálujete, pokaždé, když vstupujete na nový trh, pokaždé, když přidáváte novou funkci. Musí to být snadné. Nechci se pořád vracet za inženýringem a žádat o další sprint, abychom dodali vše, co potřebujeme."

Co to znamená pro produktové týmy expandující na nové trhy#

Zkušenost Laurel odpovídá vzorci, který vidíme napříč B2B SaaS firmami s mezinárodní poptávkou ze strany enterprise zákazníků: lokalizace se z požadavku na funkci stává brzdou růstu. Otázka už nezní „měli bychom lokalizovat?“, ale „jak rychle dokážeme říct ano dalšímu trhu?“

Přístup Laurel určovaly tři faktory: tým si nemohl dovolit vyčlenit kapacitu inženýringu na infrastrukturu, která není jejich hlavním produktem. A kvalita právní a účetní terminologie musela být ověřitelná, ne jen předpokládaná.

Přístup localization engineering chápe jazykovou podporu jako konfigurační vrstvu, ne jako inženýringový projekt. Produktový manažer tak může přidat nový jazyk bez sprintu, bez kapacity inženýringu a bez koordinace s překladatelským dodavatelem. Pro týmy, u nichž tempo expanze na nové trhy přímo ovlivňuje růst tržeb, je tahle provozní změna rozdílem mezi využitou příležitostí a promarněnou šancí.

Laurel vyvíjí AI pro odborníky z oblasti práva a účetnictví. Svůj produkt nasazuje ve více než desítce jazyků – a nový dokáže přidat během jediného dne. Jejich lokalizační infrastruktura běží na Lingo.dev.

Často kladené otázky#

Jak dlouho trvá přidat nový jazyk do SaaS produktu?

Laurel přidá nový jazyk přibližně za jeden den, od začátku do konce. Produktový manažer vytvoří ticket s odkazem na předchozí přidání jazyka, zadá ho AI coding agentovi a inženýr zkontroluje PR. Bez dedikovaného sprintu, bez koordinace s dodavatelem. Původní alternativa – vybudovat lokalizační infrastrukturu interně – byla odhadovaná na čtyři až šest měsíců, než by bylo možné spustit první jazyk.

Měl by startup lokalizační infrastrukturu vybudovat, nebo koupit?

Staff PM ve společnosti Laurel Nick Bazley porovnával interní vývoj s nákupem hotového řešení. Jeho závěr: „Nejsme experti na lokalizační infrastrukturu. Nevíme, jaká bude kvalita. Proč to riziko podstupovat, když někdo postavil celý byznys na localization engineering?“ Odhad interního vývoje počítal s XXL projektem, který by na měsíce vytížil polovinu týmu inženýringu.

Jak přesná je AI lokalizace u odborné terminologie?

Laurel testoval řešení po dobu šesti měsíců ve 12 jazycích s rodilými mluvčími z řad zákazníků v oblasti práva a účetnictví. Celkový počet terminologických problémů: dva, oba vyřešené ještě ten samý den doplněním do glosáře. Lokalizační engine zajišťuje konzistenci glosáře napříč všemi jazykovými páry zároveň – něco, co manuální řešení ve velkém měřítku zaručit nedokáže.

Jak rychlost lokalizace ovlivňuje enterprise prodejní cykly?

Zkušenost Laurel je jasná: enterprise zákazníci, kteří požadují podporu nového jazyka, očekávají odpověď v řádu dnů, ne měsíců. Nick Bazley tuto dynamiku popisuje takto: „Příležitost tu nezůstane dlouho. Pokud to nedokážeme otočit do týdne, okno se může zavřít.“ Po přechodu na lokalizační infrastrukturu přidal Laurel během šesti měsíců sedm jazyků – každý za méně než jeden den.

Jak vypadá srovnání nákladů na vybudování vs. nákup lokalizace?

Srovnání Laurel: krátká integrační fáze a průběžné náklady podle využití oproti čtyřem až šesti měsícům času inženýringu na vývoj, k tomu údržba na neurčito a navíc kvalita, kterou nedokázali garantovat. Sedm jazyků přidaných za šest měsíců by podle modelu interního vývoje spotřebovalo přibližně 28 inženýringových sprintů – kapacitu, která místo toho šla do funkcí hlavního produktu.