A Lab Instrument Maker Replaced Its FTP Intake With Files.com Folder Uploads That Require No Zipping

A laboratory instrument maker builds and services analytical instruments for customers worldwide.

Service is part of what the company sells. When an instrument misbehaves, the diagnosis starts with data: log files and complete data folders pulled from the instrument, sent to the maker, and analyzed by a service technician who returns a solution to the customer. The people who hold that data are instrument users, not IT staff. Getting the files from their bench to the company's service team is the first step in a fix, and that step ran through the company's on-premises FTP server. Whatever replaced the server had to absorb that complexity on the company's side: no account to create, nothing to install, and a whole directory tree arriving intact.

The Upload Step Stood Between an Instrument Problem and Its Fix

The FTP intake assumed things about the sender that were rarely true. It assumed an account, an FTP client, and the ability to compress a directory tree into a single archive before sending it. Instrument diagnostic data does not arrive as one file. It is a folder holding many sub-folders, each with several files, and the structure matters to the technician reading it. Customers who could not manage the zipping step got stuck at the front door, and every fumbled upload delayed a diagnosis on an instrument that already needed service.

The problem could not be fixed by training the senders. The uploaders were external, numerous, and different every time. The company could not provision accounts for all of them, walk each one through an FTP client, or ask a chemist to install software before asking for help. And any intake that handled only individual files pushed the archive step right back onto the customer.

The instrument maker chose Files.com as that intake.

Drag the Folder Into the Browser

Files.com gave the company an anonymous upload page: a web address a customer can open and send files through without ever creating an account. The company's IT team enabled anonymous uploads and pointed them at a destination folder the service team controls. The intake was operational the same day it was configured. The guidance the service team could give customers fits in one line: do not pick files one at a time; drag the data folder straight from Windows File Explorer into the upload window.

That drag carries the whole tree. Files.com preserves folder structure on upload, so a data folder with its many sub-folders arrives on the company's side exactly as it left the customer's lab, with no archive step and no support call about a failed one. Uploads land in the folder the company chose, where service technicians pick up the data, analyze it, and return a solution.

No Zipping, and Less Work for the FTP Server

With the Files.com intake in production, the instrument maker replaced an upload step that filtered out its least technical customers with one that asks nothing technical of them.

• The upload step no longer forces customers to zip complete data folders before sending them. Data arrives ready for a technician to analyze, and the customer's part is done in one drag.
• The intake went from requirement to working workflow, with customer guidance ready, inside a single day.
• The on-premises FTP server no longer carries customer diagnostic uploads, reducing the workload left to consolidate onto Files.com.

The Front Door Does the Technical Work Now

Today, a customer with an instrument problem opens a page and drags a folder into it. The zipping step is gone, along with the account and the client the old FTP intake demanded. What changed is where the technical work lives: Files.com absorbs it, so the least technical customer in any lab the company serves can still get diagnostic data to the technician waiting to read it.