An Employee Recognition Software Company Replaces Custom HR File Integrations With Files.com and Scales Without Headcount

An employee recognition software company builds the platform HR organizations use to run recognition, incentive, and milestone programs across their workforces.

None of that works until every employee has an account. A recognition program covers a workforce only if the platform knows who that workforce is, and the source of truth is not the software company. It is each customer's own HR system of record. Every deployment starts the same way: employee roster data has to travel from a system the customer runs into a platform the company runs, and keep traveling as people are hired and leave.

Every Customer Arrives With a Different HR System

The company maintains connections with the major HRIS platforms its customers run: Workday, SAP, BambooHR, Ultimate Software (now UKG). But a direct connection is not available for every customer. Plenty of employers, including long-standing customers, deliver their rosters the way their HR and IT teams always have: as an exported file, pushed over SFTP by whatever client and on whatever schedule suits them. One customer sends a file every day. Another sends one every six months.

The company can standardize its own side of that exchange. It cannot standardize its customers. The counterparties are the HR and IT departments of large employers, each with its own export tooling, its own transfer client, and its own calendar, and none of them will change any of that to suit a vendor.

Left unsolved, that makes every file-based customer an integration project. Someone has to stand up transfer infrastructure, handle each incoming file, and load it into provisioning, per customer, forever. Each of those projects sits between a signed customer and a launched program, and the number of them a team can carry sets a ceiling on how fast enterprise customers come aboard and how many the team can support.

What the company needed was one intake surface in front of its provisioning pipeline: something any SFTP client could push to on any schedule, that kept each customer's employee data isolated under its own credentials, and that told the company's systems the moment a file landed, so processing ran without polling and without a person. It had to work with no per-customer engineering. Building it in-house meant operating multi-tenant SFTP infrastructure, which is nobody's core work at a recognition company.

The company built that intake tier on Files.com instead.

A User Account, a Credential, and a Webhook

Files.com gave the file feed a standard shape. The company created a Files.com user account for each participating customer, with credentials scoped to that customer's own drop folder, so one customer's employee data was never visible to another's. The customer's HR team connected over SFTP with whatever client it already used and pushed its export on its own cadence.

The moment a file arrived, Files.com made the handoff. A webhook on the upload event called an API endpoint the company runs, and the company's code retrieved the file and processed it into employee account creation and updates inside the product. For a customer that uploads daily, the file is retrieved and processed in seconds. Nothing polls, nothing waits on a person, and the provisioning code sees one uniform event stream no matter which customer pushed the file or how.

The user account estate that pattern produced is large, and the company keeps it reviewable. A regular export through the Files.com CLI lists every user account with its status, login dates, and permissions, so access reviews run from a report on a schedule.

Onboarding a Customer Became User Account Creation

With the intake tier on Files.com, the company replaced a per-customer integration project with a repeatable pattern.

• Bringing on a new file-drop customer means creating a Files.com user account and issuing credentials. There is no infrastructure to stand up and no transfer code to write, whichever HR system the customer runs.
• Customer files are ingested and processed into employee accounts automatically, in seconds, with no one in the path.
• One pattern absorbs every schedule customers bring, from a file a day to a file every six months.
• The estate scaled without headcount: every customer account is administered from one console rather than one integration at a time.

The pattern also became something the company can offer outright: an ad hoc connection service for companies that want to deliver data by file drop-off, built on the same Files.com intake tier rather than on a queue of one-off builds.

The Intake Tier Is Part of the Product

Today, an employer's HR stack is not an obstacle to joining the platform. Where a direct HRIS connection exists, the company uses it. Where it doesn't, the customer's HR team gets a credential and a folder, keeps its own tooling and its own calendar, and its roster flows into the recognition program automatically. The customer that can only send files, once the expensive version of onboarding, is now the cheap one.

The company did not adopt Files.com as back-office transfer tooling. It made Files.com a tier of its own product: the layer that turns any employer's HR export into provisioned users. For a SaaS company whose product runs on customer data, the file feed does not have to be the exception engineered around one customer at a time. Built once on a managed intake tier, it is the standard path handed to every customer who needs it.