BeLazy is famed to have good, personalized, proactive support. However, the fact is that less than 10% of the connection-related errors that are reported get a bug fix.
Why is that? Bugs that can’t be fixed usually belong to two categories: errors within other systems where we have no say and errors we can’t understand.
I’ve written this article to explain the limits of our understanding when it comes to bug fixing and advise how you can report errors properly, to help us find a quick solution. If you’re not interested in our explanations, click below to jump into the suggestions right away.
Where can issues occur? - BeLazy is a complex system...
1- It mostly takes, but sometimes even generates jobs on the translation management system or vendor portal (customer system). This system can act up, be down, a project can be taken by someone else, etc.
2- It’s more complicated when we connect to these systems via the published APIs. For most vendor portals (except for Symfonie and Transline Transact) we use the internal APIs but for Memsource, or localization tools like Lokalise, Phrase, or Transifex we use the documented APIs.
This is generally great news, but not always for us.
it may lack functionality: In Symfonie, the API does not show everything that appears on the screen, while Phrase API does not tell us whether a job has an advanced or basic workflow. Resolutions to lacking functionalities are always workarounds that create prerequisites or the other party developing something.
it may have bugs: for example, the wrong price is returned.
it may happen that the system's user interface works but the APIs are down.
If we use the website-internal APIs or web scraping, we use the same interface you use. If we use published APIs, and there is an issue, all we can do is report it to our partner and wait for a quick fix.
3- Then we have BeLazy. We aren’t perfect either.
4- We also have “red flags”, BeLazy’s error handling feature. We throw a red flag whenever we find an issue. But sometimes we come across issues that we can’t handle, or red flags that provide an explanation that is different than the real issue. When we find something wrong on the source-side that can affect the user, we develop a new red flag.
5- Finally, there is the business management system: XTRF, Plunet, Protemos are all integrated with APIs. They can also be feature-limited or have bugs. For example, XTRF classic project APIs don’t allow file download whereas smart project workflows can’t be extended via the API. In Plunet, for example, certain settings such as the Admin-level “who is the project manager” override our setting up the project manager. Believe me when I say that we have done a lot of thinking to work around these limitations or unexpected results.
How is a bug fixed?
A well-documented bug report is a must for fixing bugs. It helps developers identify the source of the problem. Once we know what the problem is, fixing it is fairly easy in most cases.
Because our logging system is pretty sophisticated — every item has an identifier and a timestamp — digging up this information requires a developer, and may prompt us to go through many instances of messages. It can take between 30 minutes to several hours to dig up the history of one single project.
Thankfully, users know that we need context to solve problems, so most of the time we do receive screenshots. Sometimes, we even receive additional information such as the name of a project affected by a particular issue. Yet, there’s often not enough evidence for us to know where things went wrong.
The problem with a system like BeLazy is twofold:
1- First, fixing an issue is rather easy, nothing like exporting a 500-page Word document that you are stuck with and you need urgent help. If BeLazy did not generate the right analysis, a project manager can add it in 5 minutes, and we all know that PMs have always been great problem solvers. But it is exactly this which makes it very difficult for us to identify what BeLazy did and what a project manager did.
2- The second and more important aspect is that BeLazy’s activity is time-bound. Just because a system is throwing an error at 5:25:22am, it does not mean it will throw the same error if you retry the operation 5 minutes later. The system may have been down for a restart, or it was used by too many users and could not handle the request, etc.
Another important aspect is that configuration is everything. We need to know the incoming project information, your BeLazy mapping rules (especially the workflow configuration or the auto-approval rules) at the time of the issue (if you send me a screenshot now, you may already have edited it), and your relevant BMS configuration.
So, all in all, the more you can tell about the problem, the less we need to guess.
Narrated videos: The best way to report errors
A narrated video is the best way to report an issue and explain what you expected, why you expected that way, and what actually happened.
You can record a video with free tools like Loom, but if you are using Windows, simply press the Windows key + G and you’ll be able to record your browser. If you’re a MAC user instead, pressing Shift + Command + 5 opens up the screen grabber where you can record your video.
Loom will upload your recording directly to the cloud (but be careful with the length!), whereas if you’re using the other tools you will need to upload it yourself. You can use Google Drive or Wetransfer to do so.
What to pay attention to when recording a video?
If you suspect the system is about to throw an error, start the recording. If the issue only comes once and there was a red flag, it's probably not a big nuisance. If the error comes again and you’ve got similar conditions (same connection, the same type of job from the same customer, etc.) report it immediately. If the error does not come, you’ll just delete the video.
Show the source system and how you see the project there. Remember, we may not use systems like Junction or Symfonie on real projects, so please explain things like you would to a clever and tech-savvy PM who never worked with this tool.
Show BeLazy’s interface, and open up the project view to see the full detailed information.
If necessary, show anything in the BMS that may be relevant. For example the project you want to bundle a job into in the case of a bundling issue.
Accept the project right there on the spot! That way we see the timestamps.
Wait until the project is created or delivered, and show the Red flags section highlighting that no red flag was created.
Open the project in the BMS, and highlight what you expected and what did not work.
If you have problems with vendor reassignment or delivery, also show all of this. Show when you are reassigning the vendor or uploading the files / closing the tasks, and click Synchronize for the connection in BeLazy. It may take a few minutes even after clicking Synchronize for an assignment or a delivery to happen, so keep recording for about 5 minutes.
If a project was supposed to be accepted but wasn’t, show that in the original system.
If a project is available in the original system but isn’t showing in BeLazy, show the project details.
If you want to achieve something but the result is different (most typically this will happen with bundling), please go over your expectations for that project in detail and contrast them to the actual result.
If the project was created in the BMS, but something is not the way you want, click on Edit automation for the connection and show every configuration there, with a special emphasis on opening up the workflow settings with the little arrow next to them.
Remember that we need to see the whole process dynamically, from beginning to end, so don’t be shy even if the video is longer than foreseen. You can help us by saying things like “now we wait” so that we don’t expect you to speak until something happens.
Besides the video, what we need is just the project or the opportunity ID from BeLazy. Just the way you can see on the screenshot below, open up the project from the list with the little arrow, and click on Copy BeLazy project/opportunity ID for support.
