An EHS Software Company Took the Human Out of Customer Data Intake by Building Files.com Into Its Product

An EHS software company makes cloud software for environment, health, safety, and sustainability management.

Several of its programs run on customer employee data. An internal team delivers an HRIS-integrated capability: customers supply datasets about their own workforce, and the company's application processes them. That means the product only works if files keep crossing a boundary, out of HR systems the company does not control and into the AWS infrastructure where its application runs.

Every Dataset Passed Through a Person First

For years, that crossing was made by hand. Customers delivered their datasets to an on-premise SFTP server, and every dataset waited on a person at the company to move it into the application.

Onboarding was heavier still. Early in a new customer's onboarding, large datasets move back and forth, in batches of hundreds of files at a time. Those, too, waited on a person to move them into SharePoint, where the onboarding work happens.

The cost was not any single transfer. It was that intake capacity equaled people. Every upload waited on a person, and every new customer added handling work instead of reusing a pattern.

Why a Person Stood in the Middle

The manual step existed for a reason. The application's storage is Amazon S3 inside the company's own AWS environment, and S3 speaks none of the protocols a customer or an HRIS export can use. Handing outside parties a path into backend buckets was never an option, and each customer's data had to stay strictly separate from every other customer's. So a person stood in the gap: the only bridge between an external transfer surface and the application's storage.

That held for a limited customer base. It could not hold as that team's customer base expanded, because every new customer on a manual path meant more handling. The company needed an intake layer that gave every customer its own login and folder, spoke SFTP so an HRIS system could feed it directly, kept customers fenced off from one another, and delivered every file straight into the company's own S3 with no middle copy and no middle person.

The company built that layer on Files.com. The company had already retired its on-premise FTP servers onto the platform; this time it put Files.com inside the product itself.

The Folder Is the Bucket

Each customer of that capability gets a folder and a login under the company's own domain. During onboarding and in steady state, they sign in and upload their datasets: CSV and JSON files, plus supporting PDFs.

Behind those folders sit Files.com Remote Server Mounts pointed at the company's S3. The folder is not a landing zone that forwards files somewhere else. It is the bucket, presented through Files.com. The moment an upload completes, the file is in the application's storage, and the application processes it. Storage of record stays in the company's AWS; Files.com is the transfer and control layer in front of it.

Customer HRIS systems connect the same way. An HR platform that can export over SFTP points its integration at Files.com and delivers employee data into the same per-customer structure, so the feed runs from the customer's HR system into the company's application with nothing manual in between.

The onboarding exchange runs on the same platform. Instead of a person moving a batch of hundreds of files into SharePoint, a Files.com Sync moves each batch between Files.com and SharePoint on its own.

The estate this runs on is substantial: dozens of remote server connections, most of them S3 mounts, driving hundreds of thousands of API transactions against Files.com every day.

From a Person Per Upload to a Pattern Per Customer

With the integration in production, the company replaced per-customer manual handling with a repeatable intake pattern built into the product.

• Human handling is gone from customer data intake. A customer uploads, and the file goes directly into the application. Nobody at the company handles it on the way in.
• Onboarding file exchange runs itself. The batches of hundreds of files that used to be moved by hand now flow through a Files.com Sync into SharePoint.
• Intake capacity stopped scaling with headcount. Adding a customer now means a folder, a login, and a mount rather than another person's workload.
• The on-premise SFTP server that fronted intake is retired, along with the rest of the on-premise FTP estate it belonged to.

File Transfer as Part of the Product

The company did not deploy Files.com beside its product as internal plumbing. It made Files.com a component of the product: the layer that takes customer data in and lands it in the application's own storage, with every customer kept separate along the way. A SaaS company whose product runs on customer data does not have to build and staff that layer itself.