Over the last couple of months, I have heard several stories that show careless use of technology to solve challenges in translation vendor management. I have always thought of technology as a solution enabler for well-agreed and well-formulated problems, but now I can’t help but wonder if it is also something that could start a cold war between language service providers (LSPs).

The root of the problem

A few respectable single language vendors (SLVs) claim to have an increasingly big problem: some of their customers, the multilingual language vendors (MLVs) with whom they have long-standing relationship, started to introduce job auctioning portals and projects are taken before they can respond.

In the portals, each registered translator has to log in as soon as they receive an email notification on a new available job, since jobs are offered simultaneously to multiple vendors. If you log in too late, you will miss the job opportunity and even if you did some work, you won’t receive any compensation.

At BeLazy we have assessed such systems at two large multilingual vendors (both in the top 10 LSPs in the world measured by turnover) and discovered that projects in certain language combinations were taken in less than a minute, on average.

What was my conclusion as a technology expert? It is hard for me to believe that anyone can be that fast accepting jobs manually. Somebody wrote a robotic process automation script and they are now hauling in all the work from the portal.

Why is this a problem?

I have not interviewed the multilingual vendors, nor those individuals or companies that are claiming the jobs automatically. However, I have talked to SLVs that are frustrated because they are losing business with their long-standing customers.

My view is that such automation defeats the purpose of having these outsourcing portals. As a matter of fact, a representative at a large MLV once told me that they were seeing an exponential growth of failed deliveries when more than a certain number of projects had been awarded to one vendor. 

Single language vendors are only capable of handling a limited number of projects successfully, but all of them struggle with scaling up. If this is the case, it’s very likely that if a robot takes all the projects on behalf of one supplier, there will be problems with the delivery schedules and quality.

We are looking at two distinct problems here: the first is related to project placement while the second to project delivery. Automated project placement simplifies the life of project managers: once a project is placed, PMs don’t have to pay much attention to it until delivery. Project delivery is what matters to the multilingual vendor’s client — the content owner: they couldn’t care less about when the project was started as long as it is delivered according to the pre-agreed deadline.

But what do they want to achieve?

These portals can work reasonably well with freelancers that work for a relatively similar fee and work even better with an in-house translator team. However, they struggle with single language vendor companies, particularly if the SLV automates job claiming and then outsources most of the jobs to freelancers.

In this last scenario, there is a problem with traceability in the translation chain. The project placement task is simply delegated to another project manager and thus the portal owner is left totally uninformed without knowing who is actually doing the translation work (No project manager at an SLV can check with a third person in the same amount of time as an individual translator can take the project, but the PMs will still accept the project if they know that within a short time frame they’ll be able to assign the project to a translator).

I believe that trying to solve every single problem with technology can sometimes defeat the purpose of actually using automation smartly. There are situations where problems can be better solved through proper leadership: formulating strategies, understanding how the strategies affect players, allowing debates on the strategies and alternative solutions, and by mitigating the risks.

By now, everyone in the translation industry knows that multilingual vendors are under pressure, as their clients expect fast placements. There is also a cost pressure as well, nobody will deny that. The best partners in the world are those that deliver solutions to problems, rather than objections. But those solutions should be coming from a mutual understanding of the situation and a mutual commitment to the solution.

The partners along the supply chain should sit around the table to discuss the issues that affect both the multi-language vendors and the single-language vendors, and agree on possible solutions and timelines. It may lead to some partnerships being canceled if there is no room for flexibility. But maybe the solution is somewhere else, not in the partners screwing each other behind the smoke screen of technology.

At the beginning of this section, I said that these outsourcing portals work reasonably well with freelancers. That is true from a technology perspective, but from a human side of thing, the message behind this type of solution is “you’re so replaceable”. One way to address this might be to bring together the competing freelancers and come to an agreement on taking the jobs. Not everybody flourishes in a competitive situation. Managers who agree to such solutions usually do, but one question I like to ask such managers is whether they’d feel comfortable starting their own business and starting from scratch. If you are a competitive manager but not entrepreneurial, understanding that not everyone is competitive and money-oriented is quite easy.

The technology Cold War

During the years of the Cold War, American-Russian competition entailed big investments in science and technology to prove one party’s superiority over the other. The countries were rushing ahead in fear, terrified that their enemy’s weapons would destroy them if they didn’t move fast enough in the direction of progress. For science and technology, this was a glorious period, but also a risky one. It ended with the Russians seemingly defeated and the collapse of their political model.

Thirty years later, Russia has been accused of fighting back and tampering with the US elections. Even if the US had been crowned as the Cold War winner, everybody understands that Russia still holds power and intellectual capacity, and messing with them could have fatal consequences. The right solution back then would have been diplomacy, an open negotiation rather than a fight.

I think this analogy illustrates the translation industry auctioning portals and suppliers who use automation to defeat the very purpose of them.

MLVs are trying to cut prices because they are under price pressure but choose the technology which may turn out to be an expensive way of doing it. Let’s assume that prices are not fixed by MLVs in these auctions (so far I have not seen projects offered for at, say, 7 cents a word instead of at the rates in the vendor’s price list) and one supplier automates a lot of project approvals. The MLV has spent thousands of euros for developing and maintaining the portals, and the ‘hoovering’ SLV has spent another 2-10 thousand on their technology. In fact, they are back at a situation that could have been agreed amicably in a single meeting: that all projects of a certain type are awarded to this SLV vendor. The investment in such an agreement might have cost hundreds instead of thousands of euros.

BeLazy’s stance

Wars are good for those who manage to exert power over the other one. Truces are generally made in a meeting room. Independent states usually carry the diplomatic power of liaison.

At BeLazy we are in a very delicate situation, we are a partnership company. SLVs invest in our technology to achieve project automation, but both them and us need the MLVs’ goodwill to achieve this at a reasonable cost. Whenever MLVs change their portals, we need to invest extra efforts to follow up with the changes – it also means our integration for SLVs aren’t available at all times. Technically speaking, we are also capable of developing the kind of job-taking automation that we have described in the previous section, but we are hesitant to do so.

Some weeks ago, we released the Auto-approve functionality that allows our customers to set up rules for automatic project acceptance and creation. This functionality triggers whenever the connection is synchronized (by default every 30 minutes). This is our most distinctive feature, but we already see so many other possibilities, especially when it comes to job allocation to freelancers and in-house translators. Right now, BeLazy is the only translation-focused platform in the world that handles work done by multiple entities for multiple companies. We can become the missing link for effective and efficient job placement. However, we don’t want to become a marketplace for cheap and unreliable translation.

We can help multi-language vendors better than anyone else if goals are clearly communicated and strategies are precisely formulated. We have talked (and are still talking) to several single-language vendors to understand their position and help them increase their margins with our technology. Information, knowledge and the protection of each other’s interests are the reasons why in an industry with low barriers to entry, such as translation, profits are not zero. Traditional economics holds the hypothesis that in a perfectly competitive environment where resources are perfectly allocated (a scenario similar to what the MLVs auction portals could become), every player’s profit is zero.

  • Multi-language vendors: If you are thinking about a bidding portal, talk to us before you implement it. We may be able to give you data such as availability or delivery times with the consent of your vendors. 
  • Single-language vendors: Don’t be afraid to raise concerns relating to bidding portals, and tell us how you feel and what your dilemmas are. We can represent you to the vendor management of MLVs.

We look forward to hearing your thoughts on this topic. We also look forward to defining with you how vendor management strategy and goals should be formulated.

APIs Updates