Skip to main content

QIMA Turned a France-Residency Mandate Into Its Standard Client Intake Pattern on Files.com

Files.com gave QIMA a France-hosted FTP endpoint it could connect to its own automation and reuse as more clients moved to machine-to-machine delivery.
QIMAFiles.com

QIMA inspects products, audits factories, and tests consumer goods for brands and manufacturers. Its operations span 85 countries, and its platform connects that work to the clients that depend on it.

A business like that runs on data moving between QIMA and its clients. Inspection results, audit findings, and test reports flow out. Client and product data flows in. And QIMA's largest clients did not want to deliver that data through a browser. They wanted their own systems to send files into QIMA's platform automatically, machine to machine.

Manual File Intake, and a Client That Set the Terms

In 2021, client data files reaching QIMA's platform were handled as a manual file-transfer process. There was no credentialed route a client's systems could deliver into, so every file a client sent passed through a person's hands before QIMA's platform could use it. For a company whose product is the platform, that put manual handling between the client and the thing the client was paying for, on every delivery.

Then one enterprise client made the terms explicit. It agreed to send its data to QIMA automatically. But it would only deliver over FTP, and it required that its data be stored in France. QIMA had no FTP endpoint and no France-resident infrastructure to host one, and without both, the automated integration could not happen at all.

They already agreed that we will need a FTP in France in next few days to store their data.
Cyril Lakech, VP Engineering, QIMA

The constraint was structural. QIMA controlled neither end of the requirement: the protocol was the client's choice, the jurisdiction was the client's mandate, and the timeline was the client's schedule, which ran in days. Building and operating a regional file-transfer service in-house would have been a project, not a configuration, and QIMA's engineers had a platform to build.

An Intake Layer QIMA Did Not Have to Build

What the fix had to do was specific. It had to give clients an inbound endpoint speaking the protocols their systems already used. It had to store that data physically in France. It had to issue credentials per client, and it had to expose everything it received to QIMA's own automation and internal systems. And it had to exist in days, not at the end of an infrastructure build.

QIMA selected Files.com to provide that intake layer. France-hosted storage on Files.com satisfied the client's residency mandate, so the question of where the data lived became a property of the folder rather than a data center QIMA had to stand up. The same site exposed FTP and SFTP endpoints, so the client's systems connected with tooling they already had.

The rollout was staged at the client's pace. The client tested QIMA's platform manually first. QIMA then ran the opening batches of the integration itself and confirmed the files landed and processed correctly. Only after that did QIMA release FTP credentials to the client, and automated production delivery began.

We have done the first few batches of integration with our customer and it works quite well.
Cyril Lakech, VP Engineering, QIMA

QIMA's Engineers Built the Orchestration on Top

For QIMA, Files.com became the layer between client systems and its platform: credentialed on the outside, programmable on the inside.

Inbound files do not sit in a folder waiting for someone. QIMA runs a dedicated no-code engineering team, and that team built the processing on top of the intake. Flows built in Make connect to Files.com over FTP, SFTP, and the REST API to read files on the automated path, process them, archive them, and push the resulting data into QIMA's internal systems. Parabola supports additional flows that pull from FTP. A client delivers a file, the platform gets the data, and no one touches the path in between.

That architecture is what turned one integration into a pattern. The endpoint, the folder, and the credential are per client. The automation behind them is general. Bringing another client onto automated intake means provisioning a credential and a folder, not standing up another system.

Automated Intake Reached 1 to 2 TB a Month

With the Files.com intake in production, QIMA replaced hand-carried client files with a credentialed, automated route into its platform. By 2022, the deployment was moving roughly 1 to 2 TB of client data a month.

  • QIMA won the mandated integration. The client's systems have delivered automatically over FTP into France-resident storage since 2021, with the residency requirement met from the first batch.
  • Routine client files reach QIMA's platform with nobody handling them. The flows read, process, and archive files on the automated path and push the data into QIMA's internal systems.
  • Client file intake through Files.com carries materially more of QIMA's business than it did four years earlier, and the named user base has grown steadily since launch as more clients came onto the automated path.

A Mandate That Became the Pattern

Before 2021, a client file reached QIMA's platform because someone moved it there. Today an enterprise client's systems deliver straight into Files.com, QIMA's automation carries the data the rest of the way, and the person who used to sit in the middle of that path has better work to do.

The larger change is in what QIMA can say yes to. A client that dictates its own protocol, its own jurisdiction, and its own schedule no longer triggers an infrastructure project. Files.com already operates the endpoint and the region; QIMA adds a folder and a credential and connects the automation it already runs. What began as one client's condition for one integration became the standard automated route by which client data enters QIMA's platform.