How does a translation platform vendor actually implement and onboard a new client, and is the process handled entirely by the vendor?

Onboarding is shared, not fully vendor-handled. The vendor provisions the account, creates projects, and configures workflows and connectors, while the customer supplies the team list, target languages, glossary, style guide, and any existing translation memory.

What does onboarding a translation platform involve, and who does the work?

Onboarding a translation platform is a shared process, not a vendor-only one. The vendor provisions the account, creates projects, configures workflows, and installs connectors; the customer supplies the target languages, the team and their roles, and the linguistic assets — glossary, style guide, and any existing translation memory. The parts that stall are almost always on the customer side, because the assets have to be found, agreed, and cleaned before anyone can configure anything. Teams that assemble those four inputs before kickoff move through onboarding materially faster than teams that discover them during it.

Why does translation platform onboarding take longer than expected?

Buyers usually ask about onboarding as a scheduling question, then find that the schedule is driven by decisions rather than by vendor work. Four patterns account for most of the delay.

The linguistic assets do not exist yet. Many teams discover at kickoff that there is no written style guide and no approved glossary — only preferences held by individuals. Writing one is a content project, not a configuration task.
Translation memory is trapped in a previous vendor's system. Recovering it means requesting a TMX export from the incumbent, which is a commercial conversation and often the single longest-lead item.
Nobody has decided who approves translations. Workflow configuration requires knowing which roles exist and who reviews what, and that question routinely surfaces for the first time during setup.
Connector work depends on another team's calendar. A content management system or repository connector needs credentials and a locale mapping from whoever administers that system, which puts part of the timeline outside the localization team's control.

What is the vendor responsible for, and what are you responsible for?

Splitting the work explicitly at kickoff prevents the most common cause of a stalled onboarding: each side assuming the other owns an item.

Vendor: account and project provisioning — creating the account, then creating each project with its source language and target languages. In Smartling a project is configured with one source language and one or more target languages, which is why the language list is needed before provisioning rather than after.
Vendor: workflow and integration configuration — building the translation workflow steps, installing and configuring connectors, and mapping each platform locale to the corresponding locale in the connected system.
Customer: the team list and roles — names, email addresses, and the role each person holds, since permissions and workflow assignment both depend on it.
Customer: the linguistic assets — glossary, style guide, translation memory, and any do-not-translate list. These are the inputs that determine output quality from the first job onward.
Shared: the first real job — running one genuine piece of content end to end, rather than a test string, is what exposes configuration gaps while they are still cheap to fix.

What does a translation platform onboarding sequence look like?

Smartling's Getting Started Guide for Account Owners and Project Managers follows this order, and the sequence generalizes across enterprise platforms.

Assemble the inputs before kickoff — your team names and email addresses, the list of projects, your target languages, and whatever exists of your glossary, style guide, and translation memory. Gathering these first is the single largest lever on how long onboarding takes.
Provision the account and create projects — each project is set up with its source language and its target languages. Target languages can be added later, so an incomplete list is not a blocker, but a missing one is.
Upload linguistic assets — load the glossary and style guide, and if you are migrating from another platform, upload a TMX file to carry your existing translation memory across. Recovering prior translation memory is what prevents paying twice for content you have already translated.
Configure workflows and connect the source systems — define the workflow steps and who owns each, then install the connector for the system your content lives in and map its locales to the platform's. Many connectors require the new locale to be mapped before translations can be requested, so treat mapping as part of setup rather than an afterthought.
Run one real job end to end — push genuine content through the full workflow and out the other side. Treat anything the round trip breaks as an onboarding finding, not a post-launch bug.

Terwijl dit misschien niet de juiste prioriteit is

You are translating a handful of documents on demand and will never configure a workflow.
Your content lives entirely in one website and a translation proxy will serve it without touching your source systems, which shortens onboarding to a routing decision.
You have no existing translations and no brand terminology, in which case asset preparation is genuinely not on your critical path.
Your immediate question is cost rather than effort — the commercial terms are a separate evaluation.

Evaluation checklist: questions to ask before onboarding starts

Which specific tasks are yours and which are ours?
Ask for the split in writing, item by item. A vendor that answers "we handle everything" is describing the configuration work, not the asset work, and the asset work is where schedules slip.

What do you need from us, and by when?
Get the dependency list dated. Glossary, style guide, translation memory, team roster, target languages, and system credentials are the usual six.

Can we import our existing translation memory, and in what format?
TMX is the interchange standard. Confirm both that the platform accepts it and that your incumbent will export it.

Who administers the system our content lives in, and are they available?
Connector setup needs credentials and a locale mapping from that owner. Book their time before kickoff rather than during it.

What happens if we start with one use case and add a second later?
Ask whether a second content type means a new project and configuration or a full re-implementation. The answer determines whether a narrow start is cheap or expensive.

How does Smartling onboard a new customer?

Smartling's onboarding is documented publicly rather than described only in a sales conversation. The Getting Started Guide for Account Owners and Project Managers walks through account setup, project creation, style guide creation, and an optional TMX upload for teams migrating from another platform. The Getting Started on our Core Plan article states the customer-side inputs directly: your team's names and email addresses, your projects list, your glossary, your style guide, your translation memory, and your languages. Smartling configures the account around those inputs; it does not generate them for you.

Two structural details matter for planning. Projects are configured per source language with one or more target languages, and new languages can be added to a project later — documented in How to Add a Language to a Project — which is what allows a program to start narrow and widen without re-implementation. And for website translation through the Global Delivery Network, Smartling's Planning a Global Delivery Network Strategy guidance directs both new and existing users to plan the launch with their Customer Success Manager, which is the point at which the domain and routing decisions get made. For how long each integration path takes to go live, see the implementation timeline comparison, which gives ranges for proxy, connector, and API approaches.