Scenario 6: Vendor portal work with a link to the end-client’s translation management system


By far the most complicated scenario and one that is common only for language service providers working for other – usually bigger – translation companies. It comprises two sub scenarios: The first with extracting packages and the second one with reassigning vendors (we won’t go over in detail as it is already covered in scenario 4 and scenario 5).

When there are translation packages involved, the Automator’s online CAT tool may yet create another sub scenario with the complexities described in scenario 3.

In this scenario, the translation job arrives in the client’s system such as Welocalize’s Junction portal, but the translation work takes place somewhere else, like the customer’s Smartling instance.

Another typical case is the use of Plunet or XTRF to set up a project in an online CAT tool such as memoQ or Memsource, and requiring the vendor to work in it. In this sub scenario, the systems and workflows are the same, except that both platforms are owned by the client (and not the end-client).

In the first sub scenario, the vendor portal only provides the Automator their user credentials and the project identifier in the translation management system. They will have to log into the other system and retrieve the packages or assign the project to their translator.

In the second sub scenario, there is an integration between the vendor portal and the translation management system, and the Automator sets up user assignments in the vendor portal. As a side note to large LSPs, it is important to notice that such setups make automation harder, as they increase the number of supported systems.

This scenario shows the level of complexity that large translation providers (MLVs) with their own technology add to the supply chain.



In this case, liaison between the client and the Automator (the two translation companies) is almost always a must. The client needs to formalize the way they subcontract work (e.g. avoid additional instructions or files via email) and how they connect the two systems. 

There are often situations where this is implicit and there is no sign of the other system in the vendor portal other than mentioning it in the instructions, without further details. However, there are many situations where this was inconvenient: instead of a “TMS type”, “TMS URL”, “TMS user name”, there are plenty of cases where a reference Word file explains what system is being used and how to do deliveries, but there is no easy identification of the project in question – it was human guesswork.


This kind automation is technically viable, yet challenging due to the multitude of workflows in question. It requires discussion and an automation goal for each party in the process to come up with a solution that works for everyone. 

Instead of simply providing technical solutions, which is easy with simpler and commercially available systems, in this case, we take the lead in facilitating a discussion between large translation companies and their subcontractors (SLVs).


Client’s translation management system

Client’s TMS or Client’s CAT tool

Automator’s BMS, possibly Automator’s CAT tool

If you have projects that fit this description, get in touch with us or sign up for BeLazy now!


Our vision is to enable efficient continuous localization across the supply chain  → Learn

Lost? Check out this concise dictionary of continuous localization → Read

Try BeLazy with your team

Other ScenarioS

Tell us more about your workflow and we will get back to you shortly