An Email Marketing Platform Turns Files.com SFTP Intake Into a Sellable Integration for Universities

An email marketing software company serves marketers who run email at complicated organizations: universities, nonprofits, franchises, and multi-location businesses. A central marketing department controls templates, approvals, and shared assets while individual departments, campuses, or academic colleges send their own campaigns from pre-approved templates. Higher education is the heart of the business: universities use the platform to reach prospects through the admissions process and to stay in front of students, alumni, and faculty.

An email platform is only as good as the contact data inside it, and that data lives in the customer's systems, not the vendor's. Customers with developers push it in through the platform's API. But the company's chosen market is marketing teams, and a university admissions office or a franchise coordinator does not have developers. What those customers can reliably do is produce a file.

The company built the intake layer on Files.com instead, and sells it as a feature of the platform.

The Customers Least Able to Build an Integration Hold the Most Guarded Data

The files in question are CSV contact lists full of personally identifiable information: student records, donor and member lists, customer contacts. And they recur, because lists change constantly. A one-time upload solves nothing. The company needed a standing path that takes a recurring file from a customer with no technical staff and lands its records in that customer's account, automatically, every time.

Two things made that hard. First, the data comes from hundreds of separate organizations, and each one's lists must stay entirely apart from every other's. Second, the least technical customers are also the strictest reviewers. Public universities require a vendor security assessment before student data may be uploaded to anyone's system, so an intake path simple enough for a marketing coordinator still had to survive a university IT security office.

That gave the intake layer a specification before it had a name. A private directory per customer, with a credential belonging to that customer alone. Uploads over SFTP for the customers who script their exports, and a browser for the ones who don't. Encryption on files at rest. Provisioning that runs as part of the platform's own customer onboarding, with no engineering effort per customer. And a compliance record strong enough to answer a security assessment. Building that in-house would have meant the company owning a multi-tenant SFTP estate: the server, the tenant isolation, the credential lifecycle, and a fresh security package for every university review. None of that is the company's product.

A Directory and a Credential for Every Customer, Created by the Platform's Own Onboarding Flow

Files.com became multi-tenant intake infrastructure inside the product. When a customer buys the service, the platform's onboarding automatically creates the customer's account and dedicated directory. Each customer sets its own password at provisioning, so the credential is the customer's from the start.

From there the exchange runs itself. The customer drops a CSV contact list into its directory, over SFTP or through the web interface. Files.com applies GPG encryption and decryption automatically as files move through the folders, so lists are protected at rest and nobody on either side runs a script or touches a key. On a schedule, a job on the platform side reaches into the directory, finds the file, and imports the records into that customer's account. One university keeps its lists current this way with thousands of records loaded every night.

The same directory works in the other direction. When a customer needs metrics or reports that aren't available inside the application, the Professional Services team places them in that customer's directory, where the customer's existing credential picks them up. One walled space per customer carries the whole relationship.

File Intake Became Something the Company Sells, Not Something It Engineers

With Files.com in production underneath the service, taking a customer's data by file stopped being integration work and became part of the product.

• A customer with no development capacity gets a real, recurring integration: records leave its own systems and appear in its account with nobody keying data or emailing spreadsheets. The large majority of the company's university customers move their contact data this way.
• Onboarding the next customer is a provisioning event, not a project. The directory and credential are created by the onboarding flow itself, so the service is sold, switched on, and in use without engineering time per customer, and the service keeps growing.
• Student data clears the review that gates it: uploads land in an isolated, encrypted, single-tenant directory, and when a university security office demands a vendor assessment, the company's customer teams answer it with Files.com's SOC 2 Type 2 and penetration-test documentation.
• The estate stays visible without anyone auditing it by hand. A scheduled report from Files.com's AI reporting tool lands with the service's director and its solutions architect, showing where data is growing across hundreds of tenant directories.

Day to day, one solutions architect administers all of it: hundreds of customer directories, each holding another organization's personal data, while the company's engineers own only the provisioning integration.

The Integration Is Now Part of the Sale

Today, the company sells file-based integration in the same conversation where it sells the platform. For a SaaS company, "just send us a file" becomes a governed, sellable part of the product the moment every new customer's directory and credential are provisioned automatically on the day they sign.