Field Notes: How to Negotiate With Your TMS

A common frustration is surfacing among localization teams: many feel their Translation Management Systems are over-promising and under-delivering. The complaint is fairly consistent, and it is not tied to any one vendor. Expectations often get set during the sales process, and then reality arrives with product gaps, friction, and capabilities that did not fully materialize. Some of this is simply a feature of enterprise software generally. But some of it reflects the tool not keeping pace with operations that have outgrown it.

This episode is not for everyone. If your setup is straightforward, a few content types, a handful of languages, and your tools do what you need, that is good news, and there is no reason to change course. But for the growing number of teams who feel they have hit a wall, the options are limited: stay and manage the gaps, which is what most people do; migrate, which means asking leadership to replace an expensive system they likely approved fairly recently; or build their own solutions, which requires engineering resources that are hard to sustain long term. There is no clean exit, and being honest about that is a useful starting point.

What emerges instead is a more strategic approach. Rather than waiting for a perfect TMS, the move is to separate the gaps that genuinely hurt the business from the ones that are merely inconvenient, then approach the manageable ones like a product manager: documenting use cases, building a clear business case, and turning a vendor complaint into a product conversation. And in an era where AI has lowered the barrier to building, that documented business case is rarely wasted. It either moves the vendor or prepares you for the next step.

Key Insights

• The perfect TMS does not exist, and some workarounds are permanent. No single platform will solve every use case for every company. The real question is whether the gaps are manageable or whether they are holding the business back. Strategy begins with that distinction.
• Think like a product manager, not a frustrated customer. Document the painful use cases, build a requirements list with scope and business impact, and open the conversation as a product discussion. Ask whether other clients share the need, and volunteer to be a beta tester to help influence the roadmap.
• Spend influences attention, so smaller teams should lead with the quality of their arguments. Vendors tend to prioritize R&D around their largest accounts. Teams with smaller spend can still gain traction by framing a request as the vendor’s opportunity, explaining why building it would benefit the product and other clients, not just themselves.
• Building your own solution is more accessible than ever. AI has lowered the barrier to entry considerably. Some teams are filling product gaps or modernizing operations by building internal tools, including custom LLMs trained iteratively with native-speaker linguist corrections until the output is production-ready.

More “Field Notes” Episodes

Explore more topics in our Field Notes series, where we break down complex localization concepts, ideas, and experiments for industry professionals. Check out our other discussions here.

Field Notes – Episode 13:  How to Negotiate With Your TMS

Below is an automated transcript of this episode

Stephanie Harris-Yee: [00:00:00] Hello, I’m Stephanie, back here with another episode of Field Notes with Giulia Greco. So Giulia, we were chatting at a recent event, and you brought up this interesting point that so many localization professionals on the client side are frustrated with their TMSs right now.

So no matter what they’re using really they feel like the TMS vendors are not innovative enough or not moving fast enough or solving the problem gaps. What is all this about? It seems like a thing that we’ve seen a lot recently.

Giulia Greco: Yeah. Yes, it’s, You’re correct. And so maybe before we dive into this topic, I wanna say something upfront. For the audience that’s listening or watching this, and whose TMS is working just fine, this episode probably isn’t for you, and that’s great, like genuinely great. If you’ve got a relatively straightforward setup, just a few content types, a handful of languages, and the tools that you have do what [00:01:00] you need them to do, that’s amazing.

Keep going. But if you’re one of those people who feels that you’ve reached a point where your operation has outgrown what the tool can handle, and a lot of people are there right now, that’s why we were having that conversation, then yes, this conversation right now is for you. Because

what I keep hearing over and over, and this is, at events, in private conversations, in those hallway chats where nobody’s on the record, is that people are so frustrated. They feel like their TMSs are over-promising and under-delivering, and it doesn’t matter who they are using. This is not specific to one specific vendor.

The frustration is the same regardless of who they’re using. And I think that part of this is about expectations that got set up during the sales process. You know, vendors sell the dream, buyers buy the dream, and then reality hits, and you’re like, “Wait, [00:02:00] this is not what I was told this would be,” or, “I didn’t realize that there was gonna be this product gap or this friction.”

And you know, some of that is just enterprise software being enterprise software. It’s not unique to TMS platforms in any way. But some of it is genuinely about the tool not keeping up. So you’re stuck. If you’re in the situation, you feel stuck, and you can stay and deal with it, which is what most people do because it’s the path of least resistance, or you can choose to migrate, which good luck telling your leadership you need to rip out and replace a system that probably they just approved budget like last year or two years ago, and it’s expensive and it’s disruptive and it could be politically terrifying in your own organizational culture to do a change of that magnitude.

Or you can start building your own things on the side, which sounds exciting until you realize most teams don’t have the engineering resources to [00:03:00] sustain that long term. Maybe you have them for a little bit, but not like in perpetuity, let’s say. So there’s no clean exit to this problem, and I think that’s actually the honest that is actually the honest starting point here.

I don’t have a tidy answer for people who have this problem, and neither does anyone else, and I think that’s okay

Stephanie Harris-Yee: Okay, so there’s no perfect option one, one way or the other. Where do you even start if you’re one of these people who is in this issue?

Giulia Greco: By being honest about what a TMS actually is and isn’t. So the reason why there is no one-size-fits-all TMS that will solve every use case, every business needs every company has. It’s frankly unrealistic, and if someone has that expectation, I’m sorry, but I think it’s a little bit misplaced.

A certain level of workarounds will likely always be needed. That’s just the reality of working with any enterprise tool. The question becomes, [00:04:00] whether the gaps are manageable or whether they’re actively holding you back. And once you make that distinction, you can start being strategic about which gaps to push on and which ones to live with.

Stephanie Harris-Yee: Okay. So for those gaps that you’ve looked at it and these are the really hurting ones what do you actually do about them?

Giulia Greco: I would start thinking like a product manager, and I mean that literally. So what do I mean by that? Document the use cases that are a headache for you. Build a list of requirements that clearly explains here’s what we need, here’s why we need it, here’s what happens internally if it doesn’t get built, here’s the scope, how much time and effort you estimate it would take to solve this.

And then you once you’re armed with this, you open the conversation with your provider, not as a complaint, as a product discussion. You say, “Here’s a gap that we’ve identified. Here’s our business case for it.” And then you ask the smart questions. Are th- are there other client… Do you have other clients expressing the same need?[00:05:00]

Is there a critical mass here? Because if multiple clients are asking for the same thing, it’s much more likely to land on their roadmap. And then, here’s this part is important, you have to volunteer to be part of the solution. Ask to be a beta tester. Offer to provide structure feedback. This is how you start influencing your partner’s direction.

What I’ve seen over and over is that too many clients sign, sign with a vendor and then assume things will just happen without their input, without a continuous in-step strategy for the relationship. But a vendor relationship is really a function of how much time and energy you put into it. If you invest in it, you’ll have more sway when it matters

Stephanie Harris-Yee: Okay. So if you’ve done that, you had these conversations, some changes are made, that’s awesome. What happens in the case where maybe you don’t have that pull or they’re still not listening to your suggestions when you’re talking with your TMS vendor?

Giulia Greco: Then you need to be honest with yourself about why. And I’m going to [00:06:00] say something that everybody knows but gets rarely said out loud because it seems frankly rude. Your level of spend with a vendor determines how much attention you get. I’m just gonna die on this hill. It’s just business.

Yeah, it’s business, right? So vendors will focus their R&D roadmap on the needs of their biggest clients. Why wouldn’t they? If you’re a top-tier account, you probably have a dedicated, account manager, and your vendor wants your input, and they want to pitch you their ideas. They want to keep you happy because you are their most important client, or one of their most important.

You’re not gonna be at their product meetings, but you are on their short list of clients whose opinion matters. Like, your feedback carries more weight than a client who has a tiny spend. If you are an average or a low spender, and many localization teams are, that changes the equation, which is exactly why the product manager approach matters even more for you.

If you can’t [00:07:00] influence through volume, you influence through the quality of your arguments. And so beside trying to find the critical mass about, you know, am I the only client who’s feeling this gap, who’s having this issue? And likelihood is that you aren’t, so you know there’s comfort in numbers. But also, you need to learn how to articulate the value of your request for them, for the vendor, not just why it matters to you, but why building it would benefit their product and their other clients.

And that takes good storytelling. That takes clear documentation and the ability to frame your need as their opportunity.

And you’ve done all, all of that. You submitted the request, you built the business case, you volunteer for betas, you invested in the relationship, and they’re still not moving, then I’m here to say don’t despair ’cause you haven’t wasted your time.

You’ve actually built a documented business case that you can take to your leadership to justify a migration or to justify investing in building something [00:08:00] yourself. So the exercise is never wasted. It either moves the vendor or it arms you for the next step.

Stephanie Harris-Yee: So what about those teams that do decide to, after this whole process, we just need to build our own solution?

Giulia Greco: Hmm. This is where it gets really interesting because the barrier to entry for building has never been lower. AI obviously has changed this completely, and I’ve been genuinely impressed by some companies. I’m not going to name names, but they have started building their own solutions internally, either to fill product gaps in their TMSs or to modernize and speed up the language operations entirely.

So there’s one example that I think is brilliant. It’s a company that built their own LLM to translate their documentation into a particularly difficult language, and the way they did it was very intentional, very informed by localization principles. They started small. They had the LLM translate only a subset of [00:09:00] content.

They then took that output and had it corrected by their vendors’ linguists, who are native speakers of that language, and then they fed the corrected version back into the LLM, and they iterated over and over until the output was close to perfect. Once it was, they put it into production. At that point, you either don’t need the vendor for that language anymore, or you keep them for spot checks and occasional support, but you’ve just significantly reduced your localization budget for that content type.

Of course, it means now you’re relying on a company-wide AI budget or a similar setup, so the cost doesn’t disappear, but it shifts, and you’ve taken control of a problem that your TMS wasn’t solving for you. And by doing so, the, there’s also the, the side effect, welcome side effect, that you’ve demonstrated that you have adopted AI to a proficient level, which in many companies is mandated and is measured, and it impacts your

performance [00:10:00] rating.

Stephanie Harris-Yee: So what would be the, maybe the one takeaway for someone who’s sitting here with this frustration right now?

Giulia Greco: I would say stop waiting for the perfect TMS. It doesn’t exist, and it’s not coming. Accept that workarounds are part of the landscape and focus your energy on the gaps that are actually hurting your business, not the ones that are just annoying. Document those gaps like a product manager, work your vendor relationship, really invest in it, because the teams that have influence with their providers are the ones that showed up with clear arguments and a willingness to be part of the solution.

And if that doesn’t work, you now live in an era where building your own solutions is more accessible than it’s ever been. The creativity lives in the mess. That’s where the interesting, the interesting work is happening right now.

Stephanie Harris-Yee: Okay, Giulia. Thanks so much, and yeah, looking forward to our next conversation

Share this post