WEEK 1

1. Vendor Management from the LSP perspective

Unlike client-side vendor management, which typically focus on managing LSPs, this course explicitly takes a vendor-side perspective. In other words, we are learning how an LSP manages its own vendors, including freelancers, subcontractors, and occasionally other LSPs.

An LSP often acts as both a service provider and a buyer at the same time. While responding to client needs, the LSP must also procure linguistic and technical services downstream. Vendor management, therefore, is not just operational coordination but a core business function that directly affects cost, quality, scalability, and client trust.

This represents a clear shift from the client-side vendor management perspective that I am more familiar with, and it requires rethinking many decisions through a new set of logic and assumptions. I found this change in perspective both challenging and interesting.

2. The Procurement Cycle

The need often originates from the client, not the LSP. The LSP then interprets that need, evaluates whether it can be fulfilled in-house or in another forms, and decides whether external resources are required. Only after this internal evaluation does procurement truly begin.

I think this reinforced an important mindset shift. Vendor management is not about defaulting to outsourcing. It starts with asking the right questions internally before spending money externally. This distinction is critical.

The approval step forces accountability. It requires someone to justify why an external vendor is necessary, whether the cost makes sense, and whether alternatives have been considered. This step protects both financial health and working efficiency.

On vendor-side, especially when working with freelancers, relationships are often task-driven rather than relational. Formal contracts may exist, but sometimes the engagement relies on simpler agreements, email confirmations, or established trust. This does not mean structure is optional. Even in informal setups, there must be clarity around scope, deadlines, rates, and payment expectations.

The final stages of the procurement cycle focus on delivery and review. Once work is delivered, the LSP must assess whether the outcome actually solved the original problem. Choosing to work with the same vendors again offers benefits such as consistency, reduced onboarding time, and potentially better pricing. However, renewal should be a deliberate choice based on performance, not convenience.

WEEK 2

1. Clarifying “Needs” Comes Before Vendor Management

One of the strongest messages this week was that vendor management does not begin with sourcing. It begins much earlier, with clarifying what the actual need is. For example, even a simple request like “translate this” usually hides multiple unknowns, including purpose, audience, format, delivery expectations…

From the vendor-side perspective, the LSP carries the responsibility of turning an unclear request into something that can be executed. That clarification work is what makes procurement possible in the first place. Without it, any vendor decision is built on assumptions rather than requirements.

2. Vendor-Side Needs Are Already Shaped

Client-side needs often start as open questions. Vendor-side needs usually do not. By the time a request reaches vendor management, it has already been filtered through the LSP’s service offerings and internal workflows.

In reality, vendor managers are frequently procuring for internal stakeholders such as PMs. The client’s request is no longer the need itself. The need is to enable delivery in a way that is reliable, repeatable, and aligned with how the LSP operates.
This distinction helped me understand why vendor management feels more structured and constrained than client-side decision making.

3. “Translate This” is Not a Complete Instruction

One of the pre-class exercises highlighted how misleading a simple instruction can be. Before assigning work, the LSP must understand what kind of content it is, how it will be used, and what success looks like for the client.

The key step is not execution but interpretation. We are not passing instructions downstream as it I, we are converting a vague request into a set of procurement-ready conditions. That conversion step is where many quality and delivery risks are either eliminated or introduced.

4. The Right Translator

The discussion around the “perfect translator” made it clear that perfection is not the goal. Fit is. A translator may be highly skilled (e.g. PhDs game testers) but unavailable, slow to respond, or unfamiliar with the required tools.

In vendor-side work, availability and reliability often function as gating factors. A theoretically ideal match does not exist if they cannot take the job or meet the timeline. Selection is therefore about trade-offs, not optimization.

I believe this section framed vendor selection as a practical decision under constraints, not a search for the best possible profile.

5. Vendor Decisions Accumulate Over Time

We also discussed on the longer-term impact of vendor management decisions. Relying on the same few high-performing vendors can create bottlenecks, while constantly sourcing new ones may increase risks. Each vendor decision contributes to the shape of the overall vendor ecosystem. Some choices optimize for speed. Others invest in future capacity.

Good vendor management requires balancing both, rather than defaulting to one approach.

WEEK 3

1. Vendor Management Is Also About Being Found

Up to now, we have focused on how an LSP defines needs and evaluates vendors. This week we looked at the other side of this equation. Our vendors are not only being evaluated. They are also evaluating us.

You’re looking for vendors… They are looking for you too.

Vendor management is bidirectional. Freelancers assess whether an agency appears legitimate, professional, and trustworthy before agreeing to collaborate.

2. Where Can Agency Be Found

We discussed practical places where agencies can be discovered. This includes professional networks such as LinkedIn, company websites, linguist platforms, industry directories, and community spaces.

The pre-class video added some useful info (https://www.youtube.com/watch?v=NuH2AV02p70). Some general gig platforms such as Fiverr, Upwork, and PeoplePerHour were mentioned as less recommended. In contrast, translation-specific platforms like ProZ and TranslatorsCafe remain important spaces where linguists actively look for agency partnerships. Tools and platforms such as Smartcat, Zingword, LinkedIn, and TeamTranslator also function as discovery channels.

From the agency’s perspective, I also listed five elements that I believe are most important when it comes to increasing visibility:

(1) Strong Linkedin presence:
The agency page should be complete and credible, and PMs or vendor managers should have clear, active profiles. Translators often search people as well, not just companies.

(2) Active and searchable profiles on linguist-specific platforms:
Linguist-specific platforms like ProZ matter because linguists actively use them to find agencies. The agency profile should clearly state domains, language needs, and how to get in touch.

(3) SEO and Google presence:
Having an up-to-date Google Maps profile and a searchable website helps translators who look up agencies by name, location, or keywords like "agency name + language."

(4) Active participation in linguist communities:
This includes conferences, meetups, groups, and professional associations.

(5) Clear vendor onboarding path on the agency website:
The agency website should have an obvious careers section with a simple way for linguists to register and apply for a job.

3. Reality of Scams

Unfortunately, free work requests, nonpayment, CV theft, impersonation, and “pay to work” schemes are quite common in this industry.

But the key insight is that mistrust is rational. From the linguists’ perspective, an unknown agency represents potential financial risk. That means vendor managers must actively react through transparency and professionalism.

At the same time, agencies face scams as well. Fake translators, stolen CVs, impersonation, and machine translation passed off as human work all pose operational threats. Vendor management therefore operates in a dual trust environment. Both sides are cautious, and both sides have reasons to be cautious.

4. Professional Communication -> Risk Mitigation

Do not:

• Commit significant grammatical errors in the email
• Ask the linguist to move to a less formal channel for follow-ups (Telegram )
• Use your own email address, free email (gmail, etc.)
• Ask people to start registering / subscribing, etc.
• Expect an answer asap

Do:

• Get outreach emails properly written
• Get you and your company’s names and titles right
• Refer to easily verifiable information (names and roles on LinkedIn, company website, etc)
• Get to the point

Template:

WEEK 4

1. ISO Standards

This week introduced ISO 17100 and ISO 18587, which was new to me in terms of how they define translator and post editor qualifications. ISO 17100 sets minimum requirements for linguists, including graduate level qualifications or a defined number of years of professional experience. ISO 18587 extends this logic to post editing, requiring post editors to meet the same qualification standards and to work within a structured feedback loop that improves MT engine performance.

2. Qualifications are a bundle of signals

We talked about “vendor qualifications” as a set of dimensions, not a single score. The obvious ones are language pair, specialization, and experience, but the discussion made it clear that we also need to look at signals that reduce delivery risk:

• Baseline signals: degree, years of experience, relevant certifications
• Fit signals: domain alignment, prior similar work, portfolio quality
• Operational signals: responsiveness, availability, time zone overlap, tool literacy, process discipline
  An interesting point that Harry mentioned in class is how experience should often be treated as a threshold, not a “more is always better” ranking factor. From a vendor manager’s perspective, that is practical. You set a minimum bar for safety, then you optimize for fit and reliability instead of blindly paying a premium for seniority.

3. Rates matter, but they are not the only lever

Rates are important because this is a for profit business, but in real vendor side operations, they rarely function as the single deciding factor.
Sometimes the decision is driven by speed and availability. Sometimes it is driven by specialization. Sometimes it is driven by volume, where lower per word rates come with guaranteed output. The key point here for me is that rate conversations are contextual. You are not just buying words. You are buying a delivery outcome under constraints.

4. Intake workflow

The second half of class focused on building an intake process. I list a few key details:

• Do not rely on CVs alone. You are looking for requirements, actions, and evidence, not just a resume.
• Testing should be selective. Not everyone needs a test, especially if you are doing lightweight, low risk work.
• A Zoom call can help reduce scam risk, but it is not common for small, low value jobs. The point is to be intentional about why you add a step, and what risk it mitigates.
• Talent pool and multiple exits are normal. “Not now” is different from “never.” Some translators may not be a fit for the current project but still belong in a future project.

WEEK 5

1. Before Contracting

Before contracting comes payment negotiation. One side proposes a rate, the other counters, and eventually both agree. However, the underlying logic is more operational than emotional.

Rate negotiation is often handled by the PMs because they are the closest to project profitability. They understand client rates and freelancer rates, and therefore the margin. They also know when they can concede and when they cannot. This is where vendor management intersects directly with financial responsibility.

The tips discussed in class were practical, so I note them down here:

• Understand the work you are assigning.
• Know your walk-away price.
• Be clear on what you can concede.
• Ask for small concessions.
• Make sure your internal stakeholders are aligned.

2. Pre-class exercise:

We looked at the ATA freelancer contract guide as a reference point. One interesting was when we reviewed contract clauses that felt unfamiliar, such as choice of law, non-indemnification, severability, and modification clauses. Harry pointed out that these clauses make sense legally, but most of us would not have thought to include them. We are not lawyers, but we still need to recognize what these clauses are protecting. That distinction was important.

3. Legal Requirement

A large portion of this week’s class focused on legal definitions, especially California Assembly Bill 5 (AB5) of 2020. CA Assembly Bill 5 (AB5) of 2020 defines a contractor using the ABC test:

• A means the freelancer is free from control in how the work is performed. We assign deliverables, not methodology.
• B means the freelancer performs work outside the usual course of the hiring entity’s business.
• C means the freelancer operates an independent business providing similar services to multiple clients.
  Notes: Even in the absence of a written agreement, actions and communications between parties may serve as evidence of contract formation. It means that email confirmations, agreed rates, and delivery acceptance can all carry legal weight.

4. Tax

Another operational layer is tax compliance. The LSP must report payments for services. Accountants determine what documentation is required based on the freelancer’s tax status. US freelancers provide W-9 forms. Non-US freelancers provide variations of W-8 forms. The vendor manager’s role is not interpret tax law themselves, but to ensure the right documentation is collected and stored.

5. Enterprise Preferences & Sanctions

We also discussed enterprise-level preferences. Some companies prefer to work with freelancers in specific regions due to trade zones, data regulations such as GDPR or LGPD, or tax complexity. Larger LSPs with multiple global branch offices may process payments through specific legal entities for compliance reasons.

If a freelancer is located in a sanctioned country, the correct action is escalation to Legal, not improvisation. Do not proceed without approval. This actually made vendor management feel less operational and more regulatory than I previously assumed.

WEEK 6

1. The real intake workflow

A few details that felt very practical in the intake workflow:

• You usually test before interview because tests are easier to administer at scale.
• Interview before test can happen when budget is tight and you cannot afford paid testing.
• You should follow up at least once, because non response is not always disinterest. Sometimes it is just timing.
• Send the NDA before tests so you are not leaking sensitive material.
• Send tax forms only after someone has passed and is actually ready to work, not at the first contact.

I liked how this reframed intake as a funnel with cost control. Every step you add has a purpose. The workflow should reflect that kind of tradeoff.

2. The 4 Cs

The pre class onboarding framework introduced the 4 Cs. At first it feel like “a lot,” but it is useful because it forces you to cover the right categories instead of improvising every time.

What was helpful is that the 4 Cs map to what an LSP actually needs a new freelancer to know:

• How we operate as an agency
• How projects run in our organization
• How our workflow works from handoff to delivery
• How to navigate tools, people, and escalation paths

All of the focus was not making onboarding “beautiful”, but making it easy to execute and hard to mess up.

3. Onboarding

One point I had not thought about before is that parts of onboarding are not owned by vendor management. Some of the workflow can and probably should be handed off to project management or linguistic services once the vendor is active.

That division makes sense. Vendor management is strongest at building the pool, holding the gate, and establishing the relationship. PMs and linguist leads are closer to day-to-day delivery and can provide ongoing guidance and feedback.

4. Four major areas to evaluate performance

The second half of class introduced performance monitoring in four major areas and asked two practical questions: how do we measure performance, and who measures it.

The key takeaway for me is that performance monitoring is not just “quality scores.” It is a broader accountability model. It also needs clear ownership. If everyone is responsible, no one is responsible.

The discussion also made it clear that a single final score is not enough. If two vendors both land at the same overall score, you still need dimensional visibility to understand risk and fit. In practice, that means a spreadsheet that shows more than one number, and ideally a way to visualize strengths and weaknesses by category.

Luckily, our group's research has shown that this problem can actually be further solved by using a more refined evaluation model.
(https://drive.google.com/file/d/1rmultD1REGWjBC7LPVV8fyuUCVZDYWkD/view?usp=sharing)

WEEK 7

1. “Who Measures” Matters More

One idea from this week’s class that I found especially important is that measurement itself is work. Someone has to collect the data, interpret it, and turn it into something usable. If every data point is being gathered by the PM, then the PM ends up spending all day collecting performance signals instead of actually managing projects.

This is a very operational point, but it matters a lot. We often discuss evaluation frameworks as if they are free once the categories are defined. Actually, they are not. Every metric has an owner, and every owner has limited capacity. So performance monitoring is not just about what to measure, but also about whether the measurement model is sustainable.

2. Root Cause Analysis

RCAs are usually kept simple and often rely on the Five Whys approach. Start with the obvious symptom, then keep asking why until you reach something more fundamental.

What I found interesting is that RCAs are often requested by clients rather by vendor-side PMs. That makes sense. If something went seriously wrong, the client wants both an explanation and some assurance that the problem will not repeat. On the vendor side, however, RCAs create more work, and sometimes they may expose the fact that part of the failure came from the enterprise itself.

3. Performance Improvement Plan

This week’s main topic was performance improvement plans (PIP). In the freelancer and contractor context, a PIP is not something you do automatically. In fact, most LSPs do not even use them consistently with freelancers. The reason is simple: if a freelancer relationship is no longer worth keeping, you often do not need a formal PIP to end it. In many cases, you can simply stop assigning work, unless the contract explicitly guarantees volume.

In this setting, a PIP is not mainly a termination tool. It is more of a salvage tool. You use it when the freelancer is still broadly valuable. A PIP only makes sense when there is still a reason to invest.

4. Not Every Problem Should Trigger a PIP

A really helpful distinction this week was between salvageable issues and non-salvageable ones. Harry gave examples showing that some issues are clearly severe enough to justify immediate termination, while others are serious but still fixable. A data breach is obviously not a case for fixable. But a more understandable mistake, where the freelancer made a poor judgment call without malicious intent, may still be something the LSP tries to address through warning, clarification, and tighter expectations.

This makes the threshold question very important. Before writing a PIP, we need to ask whether the issue is actually improvable and whether improvement would solve the business problem.

5. A Good PIP Needs Clear Goals, Action, and Monitoring

The whiteboard exercise made the structure of a PIP feel much more concrete. The three major parts were goals and expectations, action plan, and monitoring and feedback.

For example, if someone keeps missing deadlines, it is not enough to say “improve time management.” We need a time-bound expectation, some reasonable understanding of the likely cause, and a concrete way to check whether the behavior is actually changing. The same logic came up in the discussion of data breach scenarios. If the enterprise also contributed to the issue through weak systems or unclear rules, that enterprise-level fix needs to be separated from the freelancer-level performance actions. Otherwise, it will end like using one single plan to solve two different problems at once.

If the cause is mixed, the actions must also be separated cleanly.

WEEK 8 SPRING BREAK

WEEK 9

By this point in the semester, we had already discussed sourcing, contracting, onboarding, and performance. This week made it easier to see how those pieces fit together as one system.

1. What drives LSP growth

A major topic this week was that the industry is clearly branching out. LSPs are expanding into services like AI-training, MT-related offerings, multimedia, interpreting, content and data services, consulting, and even operational support.

This changes what kinds of vendors an LSP needs, how those vendors are contracted, and what internal capabilities the LSP has to coordinate. A company that offers DTP, video editing, AI training data, or consulting is no longer managing only linguists. It is managing a much more mixed external workforce.

2. Freelancers and vendors are not the same

One of the most useful parts of this week was the distinction between freelancers and vendors. Before this class, I probably would have treated the two as overlapping enough to discuss together most of the time. But they are often structurally different.

Freelancers are more likely to be linguistic, more individual, more flexible in assignment, and involved in smaller scale production. Vendors are more likely to be small or medium businesses, less linguistic, more rigid in job assignment, and closer to larger-scale production. That difference matters operationally.

Harry also pointed out that you usually have many freelancers, each serving a small portion of your clients, and only a few vendors, each serving more clients and often under a more formal contract.

3. “Branching out” only works if you can actually staff the service

The whiteboard activity moved the discussion from strategy into execution. During our group’s discussion, we found that it is easy for an LSP to say it offers something new. But it is much harder to map what actually needs to happen under that offering, and who needs to be hired to deliver it.

Once you move beyond simple translation, the work quickly becomes multi-role. A single offering might require linguistic work, non-linguistic work, technical setup, QA, consulting, data handling, or support and coordination. At that point, vendor management stops being a matter of “find a translator” and becomes a service design problem.

WEEK 10

1. Business Management System (BMS)

This week focused on business management systems.

A CAT tool helps linguists do the actual work. A TMS helps PMs manage translation projects and workflows. A BMS sits closer to the business side. It helps manage vendors, clients, finance, and operational data across the whole LSP.

What stood out to me is that LSPs have a very unusual operating model. Even a relatively small LSP can have hundreds of freelancers in its database. That is very different from most client-side companies, which may only work with a limited number of vendors.

2. BMS tools sound useful, but they are still not universally adopted

Most LSPs already have a preferred CAT tool and usually some kind of TMS setup. Once that foundation is in place, adding a BMS is not just adding functionality, but also adding another system that has to work with everything else. That means the question is not “is this useful,” but “is this useful enough to justify cost, integration work, and process change.”

A BMS is competing against spreadsheets, partial TMS functionality, accounting tools, and whatever internal systems that the company already relies on.

3. XTRF vs Plunet

Neither tools above are used to assign translation tasks in the same way a TMS does. Their core value is on the business side: tracking freelancers, managing financial data, handling accounts, and connecting operational systems that would otherwise stay fragmented.

4. Integration

Compared with UI or pricing, what I personally care more about is integration and how well a system connects with the rest of the stack.

This comes from my own experience. In my previous work, we built a lightweight project management platform without BMS-level capabilities, so we had to rely on spreadsheets and manually created different connectors to bridge TMS, CMS, and other internal office automation tools. While this seemed flexible at first, it quickly led to issues such as fragile data sync, too many manual steps, and no clear single source of truth. Many problems were not about operations itself, but about how information moved across systems.

Looking back, it is clearer to me that many of these challenges already have more mature solutions. A well-designed BMS is not just a management tool, but an operational layer that can connect CAT tools, portals, and accounting systems through APIs and webhooks. It helps standardize how requests become quotes, quotes become jobs, and jobs move through vendor assignment and delivery tracking without relying heavily on manual work. That’s the most useful part.

WEEK 11

1. White label and managed services are not the same thing

This week’s class focused on different ways of working with third parties, especially white label and managed services.

White label is more about branding. One company provides the underlying service or product, while another presents it under its own name.

Managed services are more about operational ownership. The provider is not just supplying part of the work, but taking responsibility for running an ongoing function.

2. The outsourcing decision matrix

Before deciding whether to outsource something, the company needs to know what is core to current operations and what is important for the future. Something may be easy to outsource today, but if it becomes strategically important later, the company may want to retain it or build a stronger partnership around it.

The examples around MT, Generative AI, traditional translation, and localization consulting made this feel very practical. Services can move over time depending on how the market changes and what the business wants to become.

3. Managed services vs Outsourcing

A useful clarification for me was the difference between managed services and outsourcing. Outsourcing is usually about handing off specific tasks or projects. Managed service goes further. It involves ongoing support, maintenance, reporting, and process ownership. In other words, outsourcing gives you execution help, while managed services give you a more complete operating dimension.

In localization, for example, an LSP might outsource a specialized part of a project, but it can also provide managed services to a client by effectively running the client’s localization works on an ongoing basis. That requires much more trust and operational maturity.

4. Retainers

The section on retainers also felt very practical. A retainer works well when the work changes from month to month, but there is always some ongoing need. This seems especially useful for specialists like terminologists, SEO consultants or i18n experts. The value is not just in payment structure, but in predictability. The client keeps access to expertise, and the specialist gets more stable work.