API-driven translation workflows

Bryan Montpetit 00:06 We're going to have a code presentation that's being done by Daniel Gray, the CRO at whenever translations. And Daniel Italia enter the VP of Operations at whenever translations. So they're going to be presenting the API driven translation workflows. There we go. Daniel gray is coming in. And Daniel tell you enter. All right. I don't know. Hey, Brian Hart. Thanks. How you doing? Good. Thank you. Excellent. And Hello, Daniel. Hi, how are you? Alright, thanks. I appreciate the fact that you guys have the same name. So I can't screw it up. Very different on you. And I haven't seen you guys present before. It's just the first time that you're doing a ko presentation. It is excellent. We're looking forward to it. I'm sure it's going to be awesome. I don't know if it's a good cop, bad cop type of scenario. But we'll I'll let you I'll let you present. And again, we'll come in towards the end of the presentation, and we'll field some questions for you. Very good. Thanks, everyone. Daniel Italiaander 01:10 Yes. Should I start? Yeah, please. Excellent authority. Excellent. Okay, thank you. So hi, everybody. I'm Daniel Italia, founder VP of Operations at one hour translation. I'm based out of Tel Aviv. And today the two Daniels will speak about the API's API's and how they can be leveraged to the localization industry. First of all, a little, speak a little bit about what API's actually are, and go over a few milestones in the development of those API's. I myself come from the FinTech industry, financial technology industry, I'll give a few examples of how API's really catapult the debt industry forward. And then we'll share our vision of how API's can can be leveraged in the localization industry. So first, a few words about API's in general. So API stands for Application Programming Interface. And essentially, an API allows systems to talk with one another. It's a handshake between two systems that allow systems to exchange information, even give instructions to one another. The concept of API's has been around a long time already. But only in the last decade or so a tremendous explosion took place regarding around its usage. And really, it became a source of revenue and business model on and off itself. So we're looking at the development of the API. It really started in the beginning of the 2000s, with three commercial companies that started publishing their API's. Starting with Salesforce, who has been using their API's a fundamental part of their business from day one. Another company that in the in the context of API's needs to be mentioned as eBay, which also rolled out their API in the beginning of 2000s, first only to a select number of licensed eBay, eBay partners and developers. But ultimately, it became the standard way of how their goods are sold in the web. And we cannot get around to obviously Amazon. They also published this soon in in 2000, their API which allows developers to incorporate Amazon content features into their own websites. The second wave of development took place in the mid 2000s, when the social the big social giants really adopted the API's starting with Flickr in 2004. And then followed in 2006, by Facebook and Twitter, and they really used also API's really as as a set as a source of revenue. Now, as I said, I come from the financial technology, you know, world's a company called Payoneer, that allows vendors and sellers all over the world to get their to receive their their funds, their payments, frictionless. Actually, a lot of our translation translators are getting paid via Payoneer as well. And and two examples that I've seen during my career that really catapulted the debt forward was the API integration between Payoneer and accounting and bookkeeping software. So what it allowed was, previously when a company approved a payment in in accounting or booking system, then that same company needed to go to the bank or to actually make that payment. With an API integration. It was now possible to approve that payment in the accounting or bookkeeping system and immediately have the payment executed on the payment on the pay on your platform. And another example, from that world is a place where A integration between banks and the digital wallet of failure allowing really funds to flow freely between financial products of the banks and the pay on your digital wallet. So for instance, somebody can have funds on his debit card or credit card or bank account, and would like to top up his pay or near balance or the other way around, withdraw from the, to the to the bank. And that all is done with API's between those systems, allowing for frictionless flow of funds. So, So there I've seen firsthand how those API's really developed at the industry very quickly. And I believe that that, that in the localization industry, there are also many, many examples, scenarios and ways in which we can leverage those API's to really, you know, move further. Still, data flows. So for instance, are two examples that I wanted to bring a particular one are smart quotes. So we're working towards the way whereby we envision getting materials from our clients via API, send it to translation, memory analysis, and based on deliverability of translation memory in real time, being able to give a quote back to our clients with regard to the cost of that translation, that is a process that today needs many hands and touches many teams. And by leveraging the API, we believe we can reach a lot more efficiency in depth flow. And another another example of the API m in the localization industry, is the integration, that's something that we're actually have an for to develop is integration with helpdesk software, for instance, Zendesk. So we are now able to get support tickets that are in a foreign language from Zendesk via API's submitted to us distributed to our translators, translated, and then being sent back via API to that same helpdesk software, allowing our clients to allow our clients to do business globally and give support to their clients wherever they are in the world. So so that's a little bit of an idea of, of API's, in general, how we envision that in terms of operation, and Daniel, maybe you can take it from there and share your vision as well. Daniel Gray 07:31 Thanks, Dale. So just by way of introduction, my name is Daniel gray. And I've been fortunate enough to be in the industry in the localization industry for I think about 20, some odd years. What I love about this concept of API driven workflows, is for a lot of folks that are listening either real time or might listen to the recording, you're either on the customer side or the supplier side. And our conversation today is really to share our learnings with both sides of the fence. And the slide that I'm sure it is really about, as Daniel was talking about, it's really about engagement models. How do we make it easy for customers to interact with us as suppliers, for whatever translation, and we have a couple of different engagement models. One engagement model is self service, which is really nice. It's kind of like shopping on amazon.com, where you can basically just self serve for the procurement of localization or translation services. I like thinking about it in terms of evolution is translation as a utility, kind of like cloud computing. So the concept of engagement models, I think, is really what underscores this concept of API driven workflows. For one hour translation, the ability for a customer to use different engagement models, one engagement model can be self service. Another engagement model can be somewhat of the traditional project manager, the project manager engagement. What we are finding, however, at the at the smaller side of the fence to the larger side enterprise side of the of the spectrum, is the concept of setting up an API driven workflow. That setup once done that allows for velocity and scale, unlike anything, or any other option, even the use of transition management systems. We are also integrating with multiple translation management systems from an API perspective. In other words, if you set up the tracks, and you set up the right workflow, and the next slide will will illustrate an example of that workflow. Once you set up that workflow, in terms of an API call and moving content from the customer side, through to the translation and production side and then back to the customer. What we're finding is massive improvements and efficiencies. From a philosophy or production perspective, cost efficiencies and we'll talk a little bit about both the benefits to a customer, as well as the benefits to a supplier. Now, I don't think the concept of API driven workflows is all that tectonic. Nevertheless, what we are finding is from small customer to medium to large customer. The concept of setting up an API driven workflow on the supplier side creates stickiness on the customer side just makes it a lot easier and faster and less human hands on the assembly line, to move translation content through the from the customer through the translation, production assembly line, and then back to the customer. So again, I think the big takeaway from this slide for the audience, be it that you're on the customer side, or the supplier side is there are benefits to both sides, and most importantly, providing different engagement models for customers, be it self service, project management, project manager, API, or a combination thereof. And we actually have customers that vacillate between those engagement models, being able to do self service for translation as a utility. And for much larger engagements, being able to move content through an API driven workflow. So with that said, let's take a look at an example. API driven localization workflow, before I go in and call make some call outs on this workflow. This is a representative workflow. It's some semi generic, and it's used for illustrative purposes. But it's a good example of how we work with our customers to custom build or custom set up the workflow, you can see that there are three swim lanes from the client, to the localization production, to quality assurance as three basic swim lanes. But the nice thing about this workflow is, it is custom set up with the client. Number two, being able to go into the workflow and triage any challenges that are coming up with production, I'm going to make a couple of call outs as this slide builds. But what I have found both from a sales point of view, a customer services support point of view, is documenting the workflow is really a simple and yet eye opening experience both for the customer as well as for the supplier. I personally use this artifact with my customer. And with my operations team. And the concept is anytime I might have a problem on the assembly line, I'm actually troubleshooting the problem and isolating the problem or the challenge to a step or set of steps on the workflow. And then I can go in and like a series of levers make modifications to the workflow, which may be talent related. It may be process related, it may be system or technology related, but it's allowing us to more quickly triage, identify isolate problem areas, be it I'm getting bad feedback on linguistic quality, or I'm having a turnaround time challenge. Usually, it makes it so much easier to triage, troubleshoot, identify, isolate the challenge on the assembly line by having the workflow document. So let's build a slide and just to make a couple of call outs. And I'm guessing that for the suppliers on the call, a lot of this is possibly what you do. And for customers, maybe this is also what you experienced. But the first thing I would call out is as a supplier, we have a talent pool around the world. Beyond that talent pool, which we certify. One of the nice things that we tried to do is then further go from the certified metadata pool to a batch set of workers that are account specific. We have found that that has been extremely helpful. We are able to tie production and deliverables to talent ID so now I can actually identify Do I have a talent issue? Because my deliverable is paired with the talent that actually worked on that deliverable. And then on the upside is production, Team consistency, account knowledge, improved productivity, because now I have a set of quote unquote badged workers or translators or other talent that is dedicated to that account. So that's one of the advantages of setting up that API workflow batching the talent and pairing the talent to the workflow. Next is in terms of linguistic sign off, and one of the big things that I'm a proponent of here when our translation and in general is what is the ruler that We are using if we use the metaphorical ruler, how do we measure quality, one of the things that we are doing is making sure that with our customers, the ruler that we use to measure quality, and the ruler the customer uses to measure quality is one of the same. But again, with the API driven workflow, we are out of auto routing localized content to the QA, swim lane of the QA step, we are doing statistical sampling of each translators, IDs deliverable, that go through QA. So once again, I may not do 100% QA of 100% of the content. But I'm doing a significant amount of statistical sampling of deliverables per translator ID and therefore for the totality of the team, because I'm trying to rate both my talent in that API driven workflow, as well as rate the quality of the deliverable performance and deliverables being made to the customer. So now I can actually measure translator, performance as well as I can measure total deliverable performance. So that's a that's a big one, in my opinion, in my experiences, how do you get that ruler normalized from the supplier to the customer? And then how do you lift performance metrics off the assembly line, and not only share them with the customer, but be able to condition train incent the translation talent that's working on on the on the workflow? How do you incent them to either performed better, if not reward them for over performance? So I've already mentioned the concept of normalizing that ruler, and I've mentioned the concept of reportable and trackable performance coming off the assembly line. But even more than that, especially as suppliers, we want to get to either monthly or quarterly business reviews being able to report back KPIs or key performance indicators to the customer on how we're performing. Being able to provide metrics by language by deliverable. And by translator, we have found that level of ownership and accountability has been wonderful for us as a provider as a factory, and for the customer in in order to enable the customer to better understand their ROI be able to report internally and up to their stakeholders on their multimarket performance. So this is paying significant dividends for us. And I have really enjoyed working with customers setting up these API workflows, the velocity, the scale that's going through, another big call up is we're actually doing more volume with typically less human hands on the assembly line than when I started back in the industry. 20 some odd years ago, where there were armies of project managers and project coordinators, just a lot of this stuff was managed manually, Excel file tracking FTP, handoffs, email, it was really, it was really, really interesting time. Today, what I'm finding if I just do a juxtaposition and compare the before and after, the amount of volume and velocity that's going through for localization is happening, far greater than anything I ever worked on in the past. And yet, with less human hands on the assembly line, less human hands, means less cost and less human error possible on the assembly line. It's not perfect, but boy, have we seen an improvement. And so I will finish with some highlights that I think are helpful, both from a customer side or customer point of view, as well as from a supplier point of view. So I chose to highlight, of course, some really impressive metrics. What I'd like to share contextualize here for the audience is when our translation, which is about 12, or 12 years old, was born as a digital company, offering a platform for self service translation. So you do have a lot of customers that have smaller translation requirements, faster turnarounds, smaller volumes. And that is great for the self service side. As far as the API side, even with very large engagements that can still come through in smaller packages. The nice thing is scale. So for customers, you can move a lot of small packages for medium or large packages through an API driven workflow. But for us, a highlight a showcase of this is processing a particular project that was 2 million words across six language cars. And this was done in a 90 day period. Now again, with the advent of machines Translation via post editing the light post editing full, of course, we're producing again, a lot more throughput than we did again in the past. But what's amazing is those tracks that pipeline between customer and supplier is facilitating right is making it easier to move the content from customer to supplier through the factory and back to the customer. In terms of cost efficiency, on the supplier side, we are seeing massive improvements in cost less human hands on the assembly line means less cost. So we are seeing from a cost overhead perspective, massive improvements in our cost efficiency. And I think that those improvements for us, they're passed on to the customer. As far as operational efficiencies concerned, as I mentioned, what are translations to give you a sense of realism is a about 100, full time employees, of course, operating with a very large global certified pool of talent. But nevertheless, operationally we are pushing millions and millions of words are able to push millions and millions of words through the factory, because the API workflow sets up those tracks or that pipeline, and then it becomes almost a wash, rinse, repeat. As far as quality is concerned, what I love is being able to move from subjective to objective, quality measurement. And so be at a scale of one to five, one to six and setting up that framework with the customer on how you're going to measure quality, what's working well for us is getting to a normalized or standardized ruler, and being synchronized with the customer on how we're measuring quality and how they're measuring quality. Once we get to that, if we decide collaboratively that that past threshold is a four, well, in this case, with this particular customer, we're achieving a four to a five, that doesn't mean that we don't deliver below four, when we do once again, you can get back to the workflow and troubleshoot that and identify Do you have a talent issue, a systems issue a process issue. Lastly, and I'll finish on this point, and then we can open it up for questions. But the basic concept is automate route delivering report. And I love the concept of wash, rinse, repeat, make it predictable, we make it easy on the customer. Some of our customers have one API, some of our customer has have multiple API's. But all in all, I think that there's a benefit to the supplier ecosystem, as well as the customer ecosystem. So I want to thank everybody for spending a little bit of time with us, Brian, over to you for questions. Bryan Montpetit 22:41 And thank you to both Daniel's I really appreciate the all the information it was it was wonderful. Naturally, as these presentations do, especially when we talk about API's, there are questions. So the first one that was from ever, how do you guarantee when our translations isn't limited to a certain volume and office hours? Are there translations provided by in house translators or empty? Daniel Gray 23:06 So it's a great question, Daniel, I'll take a first stab at that. And then you can feel free to comment. So, again, one of the things that when our translation was born on was this digital platform of making translation, the consumption of translation into utility and self service. So granted, you can't push a couple million words in through one hour translation, or I don't think any supplier in one hour. But the basic concept is for very small packages, yes, we use both in house as well as external translators, just like most, if not the entire industry. leverages that. And yes, we are kind of like Amazon, there are basic thresholds for same day delivery next day delivery, two day delivery. But and then lastly, production methodologies, we use a combination of either human translation, machine translation, raw machine translation, heavy or light. So that really depends on the quality threshold that the customer needs. Some customers are okay with just raw empty, depending on what they're doing with the content. Others need the highest of quality. So we pair the production methodology to the quality output. I think that's really the key there. Daniel, I don't know if you have anything additional you want to Bryan Montpetit 24:21 know. Okay. That was great. And if Daniel, if you wouldn't mind, just stop sharing your screen. I'd appreciate it just so everybody can see the you know, who's answering the questions. That'd be very kind. Thank you very much. We also have another question from Santiago Torres. Can you give a few examples of some of the L QA metrics you use? Daniel Gray 24:48 Daily, would you like to take a stab or I can go ahead and take off from that one first. I'll take that one first, Brian. All right. So Are there are since there are some standard frameworks that we have used with our customers, I'd be actually happy to share that Brian with you guys, and then maybe be able to share it with the community. But to keep the response short and sweet, we try to use standard frameworks. So from spelling to style to tonality, technical accuracy, those kinds of categories, and then a rating of say, one to five, or one to six, it allows us in Daniels managing the factory, it allows us to pull those performance metrics off the assembly line, and be able to report those performance metrics. What is key here is making sure that we're aligned with the customer, I have found too many times the way that customers ICRA country review, the ruler that they use is different than the ruler that we're using. So one of the first things I do is make sure we're normalizing that ruler, so that when we report a 4.5 is the same thing as the customer. I think it's less important to me, what the framework is, what are the categories? And what's the scoring? Once you normalize on that, you know, it's it works well when you're not normalized on that my 4.5 could be a customer's 3.2, or vice versa. Bryan Montpetit 26:15 Great. I think that's a great point, I think a lot of people fail to realize that the denormalizing that across, you know, into the country reviewers is so important in terms of maintaining the customer feedback and actually using it effectively. So thank you for that. One additional question, which is more related to the criteria for the customers themselves. But can you give some examples of the quality criteria your customers agreed to? Daniel Gray 26:39 Yeah. So once again, it's it ends up falling into this, let's call it semi standardized structure of spelling, grammar, style, tonality, technical accuracy, etc. Our customers, even fortune 500 customers and with, you know, with a lot of experience in localization, are still coming to us. And I'm sure they come to other suppliers, asking, Well, what should our ruler look like? So what I have found, Brian, and I certainly welcome Daniel in common as well. But I have found I will come to the table and share with the customer. What has worked for us what the industry uses as an average, but from customer to customer, it has changed. The nice thing with us as a supplier, I'm sure the same for other suppliers is we do try and be as customer focused and customized as possible. So there's no one silver bullet, but there is kind of a baseline or nucleus that we work from. And then there's a little bit of modification. Now I would say that what I have also found is one customer's threshold for passing could be a three or 3.5. And another customers threshold for passing is five or nothing. So it differs, it differs from customer to customer and content category to content category. But once again, there's this kind of base framework, and I'd be happy to share what what we use, I'd also be happy to hear from others what they use. Daniel Italiaander 28:11 Maybe I can add to that that one play type of customer. Customer adjustment that we do in terms of quality measurement is the sampling rate. So we have a certain sampling rate to to guarantee the quality of our factory, so to speak, but then there are clients that require a higher level of sampling. And that is something that we can facilitate and do so. Bryan Montpetit 28:36 Great, thank you very much. We're at time. But I do want to invite you guys to check out the community afterwards, because I know that some people are going to be asking some additional questions because we didn't get to all of them, unfortunately. So we even have people asking if they can reach out to the Daniels directly to ask questions about API's and whatnot. So again, I'd like to really thank you guys for your time. I really appreciate all the information, the transparency in which you spoke. It's very kind of you and very much appreciated that you spent time with us today. So thank you to both of you. Daniel Italiaander 29:08 Thank you. Thank you. Thank you very much.