We're building an AI that picks our translators, here's how it works

When a new translation project lands at Tomedes, a project manager has to answer one question before anything else: who is the right translator for this job? It sounds simple. It is not. That single decision draws on years of accumulated knowledge about thousands of vendors — who delivers on time, who struggles with legal content, who has handled this client before, who is already at capacity, and who showed up at midnight when we needed them to.

Industry analysis suggests that project managers at translation companies typically spend 10–20% of their time on manual coordination tasks that a proper system would automate. At Tomedes, we decided to build that system ourselves — not an off-the-shelf TMS vendor picker, but an AI tool trained to replicate the judgment of an experienced project manager. This post is the honest account of what we have built so far, what we have deliberately not automated, and where we are going next. 

Why vendor assignment is harder than it looks

Tomedes works with translators and linguistic specialists across more than 270 languages. For any given project, there may be dozens of vendors who are technically qualified. The real question is not who can do this job, but who should do this job right now, for this client, given everything we know.

A CRM record tells you the basics: language pairs, specializations, rates, last active date. What it does not tell you is whether this vendor pushed back on a tight deadline last month, whether they have delivered for this specific client before and built a rapport, whether they consistently deliver clean files that go straight to QA or files that require a second pass, or whether they are currently mid-project and unlikely to take on new work.

That gap between what the system knows and what an experienced project manager knows is exactly the gap we are trying to close. Without robust vendor intelligence, project managers have no standard way of evaluating translators beyond what's in the system — leading to repeated manual coordination by email and instant message, and an increased risk of losing critical context.

What data a project manager actually uses to decide

Before building anything, we spent time mapping out the actual decision process a Tomedes project manager follows when assigning a vendor. The list was longer than expected.

The quantitative signals are the easier ones: total projects completed, delivery on-time rate, last delivery date, active project count, language pair, subject matter specialization, client history, and rate. These live in the CRM and are relatively straightforward to surface.

The qualitative signals are where institutional knowledge matters most. These include how a vendor communicates when there is a problem, do they flag issues early or go quiet? How they negotiate when scope expands mid-project. Whether they have relevant certifications such as ISO 17100 or domain credentials for legal, medical, or technical content. Whether they have worked for this particular client before and whether that relationship is positive. Whether they are responsive on weekends for urgent projects.

These signals do not live in a CRM field. They live in email threads, in the notes a project manager writes after a difficult project, in the pattern of a vendor's replies over three years of working together. This is what we needed the AI to read.

How our AI system works today

The system we built for Tomedes operates in two stages.

The first stage is signal extraction. When a project manager opens a sales order and initiates the vendor assignment workflow, the AI scans the relevant email threads associated with that vendor. It extracts structured signals using predefined tags — things like on-time delivery, late delivery flagged in correspondence, escalation language, domain expertise mentioned in prior projects, and responsiveness patterns. The system currently identifies more than 30 distinct signals from the email record.

The second stage is ranking. The extracted signals are compressed into a structured summary and fed to an AI model, which cross-references the email intelligence with the CRM data (total job count, last delivery date, active workload, previous work for this client) and produces a ranked shortlist of the top three recommended vendors for the project. The project manager sees this recommendation alongside the reasoning behind it, not just the output.

The interface is built into the existing workflow. Project managers access it directly from the sales order tab, which means there is no separate tool to open or learning curve to navigate. The system also supports email template generation for tenders, which reduces the manual drafting time when reaching out to vendors for quotes.

Why we chose to read emails, not just CRM records

This was the most consequential design decision we made, and it was not obvious at the outset.

The instinct when building a vendor intelligence system is to start with the CRM, because the data is structured and accessible. Our CRM contains years of project records, ratings, and notes. It is genuinely useful. But there is a class of information that never makes it into a CRM field — the texture of how a vendor behaves under pressure, the unfiltered communication when something goes wrong, the informal commitments that shape a relationship over time.

My view, and the position that drove our design, is that the email inbox is the most accurate source of truth for vendor behavior. A CRM record reflects what a project manager chose to log. An email thread reflects what actually happened. A vendor who consistently delivers on time but occasionally sends a terse, difficult message when scope changes is a different risk profile than a vendor who delivers on time and communicates cleanly throughout. That distinction matters for the right projects. It does not live in any field we have ever created in a CRM.

Scanning the email record gives the AI access to unfiltered evidence. It is messier data to work with (emails are unstructured, context-dependent, and sometimes ambiguous) but it is closer to reality than any structured field we could populate manually.

We piloted this approach by scanning one month of historical email data from our operations inbox and evaluating whether the signals the AI extracted matched the institutional knowledge our most experienced project managers held about those vendors. The match rate was high enough to move forward.

What we deliberately have not automated yet

The system currently recommends. It does not assign.

This is not a technical limitation — it is a deliberate strategic choice, and Michal Blum, our CFO, was right to push for it. When we discussed the architecture of this system, there was a tension between moving fast and getting the logic right. My position was that you do not automate a decision until you are confident the logic replicates the judgment you would want a human to apply. We are not there yet.

The vendor prioritization logic is still being refined. We need to integrate more CRM data points (specifically, active project counts and total delivery history) to ensure the AI is weighing current workload appropriately and not recommending vendors who are already stretched. We also need the reasoning to be visible to project managers before they act on it, not just a ranked list. If a project manager disagrees with a recommendation, that disagreement is information. It tells us where the model's logic diverges from experienced human judgment, and that gap is where the next iteration of the system gets built.

The goal is not to remove project managers from the process. The goal is to give them better information faster, so they can make the right call in a fraction of the time. The broader shift in the industry is toward LSPs becoming consultative partners rather than transactional utilities, which means freeing project managers from administrative coordination so they can focus on the relationship and quality decisions that actually require human judgment.

Where the system is going next

The immediate next step is integrating the full CRM data layer (total projects completed, last delivery date, client-specific history, and current active workload) so the ranking logic can weigh all relevant factors simultaneously. Once that integration is stable, we will begin assessing the quality of recommendations against actual project outcomes.

The longer-term vision is AI-assisted vendor sourcing for the approximately 10% of projects where we need to go outside our existing vendor network. The system we have built can already search across external platforms for vendors who meet specific criteria, but this capability is secondary to getting the prioritization logic right for our known vendor base. We will not expand the sourcing functionality until the core assignment intelligence is reliable.

The destination is a system that replicates what a great project manager does instinctively: surface the right vendor for the right project based on the full picture of what we know about them, not just what we have formally recorded. When we get there, project managers spend less time on decisions the data can support and more time on decisions that genuinely require their expertise.

That is the version of AI we are building at Tomedes — not AI that replaces human judgment, but AI that earns the right to inform it.

Tomedes — Professional Translation in 270+ Languages
Human expertise. AI precision. Your content, handled right.
Get a free quote → · Try AI translation →

About the author

Ofer Tirosh
CEO of Tomedes
Connect on LinkedIn →