You’re an LSP.

Your average project manager works on 12 projects/day.

Spends 45 seconds to add data to a tracking sheet, move files, and create folders.

That’s 9 minutes per day in non-added value tasks.

You have a team of, say, 12 managers.

That’s 108 minutes per day of team admin tasks with no customer-facing value.

Week: ~540 minutes » Month: ~2,160 minutes » Year: ~25,920 minutes

At an avg. hourly fee of US$25, that’s ~$10,800/year! 👀

Last year, I had posted a rough sketch of what could be an email assistant for LSP project managers. Such an idea would remove a hidden hurdle most small translation businesses experience, which is manually structuring data that comes via email in an unstructured and sometimes ambiguous form.

This is something I always wanted to build for our managers at The Translation Team. As a Microsoft-powered business, there are multiple opportunities to build interesting workflows without relying on external platforms, so I committed to do it using Power Automate and whatever Microsoft app could be useful to meet the following goal:

Transform a customer email request into a series of accurate tasks: create a record, set a deadline and urgency, identify the requester, their company and department, the list of languages, create a folder structure, and identify parent-child relationship for updates. Any ambiguity would be handled by a small LLM.

You Need Good Data Foundations for Automation

Building an automated email intake workflow in Power Automate (what I used to orchestrate everything) sounds simple on paper: An email comes, the system extracts the request, and then routes it somewhere useful. But the moment you try to scale beyond a handful of actions, you realize the real challenge isn’t the automation logic, but the data foundation underneath it.

The automation itself was straightforward (sometimes it wasn’t, he he). The problem was dealing with the messy reality of inconsistent or missing contact information and ambiguous language. That’s when it hit me: Automation is only as smart as the data you give it.

To make an intake workflow truly reliable, you need a database that acts as the single source of truth. In my case, that meant maintaining structured tables for:

  • Contacts: Names, email addresses, and their time zones.

  • Companies: Names, aliases, domains, industry tags.

  • Branches or Locations: Names and their relationship with companies and contacts.

  • Languages

  • Services: Standardized categories the workflow can route intelligently and build specific file directories.

Without this boring foundation, the small AI models that recognize and fetch entities end up guessing. Yes, guessing is the enemy of automation.

Make Automation and Interactive Validation Process

Once the data layer is solid, and you’re building consistent services request objects, the next step is to validate them to ensure they are correct. What could be better than using Adaptive Cards on Microsoft Teams for this goal?

Adaptive Cards are a JSON-oriented design framework that Microsoft developed to build small UI components on top of other apps. Image our request object appearing as a small window on a chat, with a few options: Dismiss, Claim, Review.

Thus, managers can dismiss a request if it’s not a real one¹ (like a “Thank you!” reply from our customer or side threaded conversations), claim it (they are the owners and will take care of them, confirming it’s 100% accurate), and review it directly in the database (for tweaks or to add notes to it).

So, once they claim the request, and based on the service, the workflow will produce a workflow-like folder structure² that reflects the different statuses of the production process involved in the request (e.g., proofreading, translation, quote, etc.).

Are Agentic AI or MCP The Next Steps?

Woo-hoo! Mission accomplished. Right? Well, the sky is no longer the limit with the wide availability of agents and MCP. Now we can shoot for the Milky Way.

If you are following, this means managers could delegate (some) preparation tasks to agents, which then can send things to a TMS, fetching specific data from it to make the right choices in terms of translation memory collections, glossaries, workflow steps, and so on.

I am delighted with the outcomes of this project, and I can’t wait to share the next developments in the coming months with you.

🫓

¹There’s a guardrail sub-process to reduce them to the maximum extent possible, but it’s so long to explain that you will have to DM me if you’re curious.

²I have a small project to build flat file directories based on metadata, so we get rid of folder structures. We’ll see!