When choosing a business management system for their company, the heads of translation agencies most often begin by comparing functions on a service like Capterra. Another popular way to choice a system is to contact the developers with a request to fill out a specially created table in which they enter “yes” or “no” opposite the names of all kinds of functions.
Both of these approaches are based on fundamental misconceptions, which we will discuss below.
What is the name of the function?
As we have repeatedly written in articles on our blog, there are no two identical translation agencies: they are all unique, like fingerprints. The individual nature of agencies is manifested in, for example, their corporate terminology: the terms “project”, “work”, “job”, “amount to be paid”, etc. are understood differently in different agencies, as are how these concepts interlink, and this is of particular importance.
For example, in some agencies a “project” is a one-time order from a client, while in others it is something long-lasting, going on for weeks or months, and each individual order is considered part of the project; a “subproject”. Some agencies “accept work” and “give jobs”, others “receive requests” and “assign work”, and others “accept orders” and “hand over projects”. What is called “work” in some agencies is called a “project” or “assignment” in others. Some pay “fees”, others “salaries”, others make “payments”. One translation agency creates a separate invoice for each order, another collates all customer orders for the month into a monthly invoice, while others wait for a certain amount of money to be accumulated.
The difference between languages causes additional difficulties. If your native language is, for example, Spanish, and the system interface is in English, the terminological confusion is exacerbated.
Even the job descriptions of employees are understood differently. For example, in one translation agency, a project manager simply distributes files for translation, while in another he or she chooses a team and even negotiates prices with clients. There are agencies in which information about their earnings is hidden from project managers, and a separate employee deals with financial issues.
So, each agency develops its own “corporate dialect”, and yours is no different. And if you ask questions to the developer of a translation business management system, then there is a high probability he or she will understand them in a different way to you, and answer “yes” in cases where in your understanding you would have responded “no”, or vice versa.
Suppose you ask whether the system has a “work payment function”. If your question is taken literally, the answer is “no”, since the system does not provide such a function. But the ingenious developer will understand: “paid work” is what you call what in the system logic is called “paid invoice for the project”. So there is such a function, but it has a different name or the action is performed in a different way.
Most likely, the answer to your question will be “yes, there is, and we will show you how it works”. But at the same time you will gain the impression that the developer is simply avoiding giving a direct answer, although this is not at all the case.
How does the function work?
Even if you avoid confusion with the terms, the list of available functions of a translation management system does little to help you make the best decision.
The reason is that the mere existence of a function does not say anything about how it works. For example, how many mouse clicks do you need to create a project? How convenient and intuitive is the interface? Is it difficult to learn how to use the system and how much will its implementation cost? What if you need to send all your managers on expensive three-month courses to learn how to use it? How quickly does the support service respond to your questions if you still don’t understand something? You will not be able to get answers to these questions either by comparing functions, or by talking to developers.
So how should I choose a management system?
If you are seriously thinking about implementing a translation management system in your office, do not rely on comparative lists. We assure you: under each point of this list, which is one line long, you could add three paragraphs in which your outline nuances and provide clarifications.
The list of desired features is just a guide; each of them needs to be tested individually. It is important to determine whether you like the system interface, whether it is user friendly, and whether its internal logic is clear. The same operation in two different systems (for example, “creating a project”) will probably be performed differently, but this will not be reflected in the comparative list.
Be sure to test any translation project management system before you buy and implement it. As a rule, developers provide instructions to help you quickly get started. Take some time to familiarize yourself with them.
Communicate with the developers, explain to them your individual needs, and ask them specific questions. In doing so you check the “responsiveness” of the technical support service. If they answer quickly and clearly, you will not be left alone in confusion about how something works. Most likely, the function you require is available in the system, you just need to figure out exactly how it works.
Developers need to know how the workflow processes at your translation agency operate and what your exact requirements are. Usually they do not get enough feedback to help determine how to further develop their product. It is possible that, based on your recommendations, they will implement the features you need in their next program updates.