Marigold’s Emma Turns Files.com SFTP Intake Into a Sellable Integration for Universities

Emma is an email marketing platform founded in Nashville in 2003 and now part of Marigold, the marketing technology company that also operates Campaign Monitor. Emma's market is marketers who run email at complicated organizations: universities, nonprofits, franchises, and multi-location businesses. Its distinctive capability is brand governance at that scale. 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 Emma 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 Emma's. Customers with developers push it in through Emma's API. But Emma'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.

Marigold built the intake layer on Files.com instead, and sells it as a feature of the Emma 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. Emma needed a standing path that takes a recurring file from a customer with no technical staff and lands its records in that customer's Emma 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 Emma'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 Emma 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 Emma's product.

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

Files.com became multi-tenant intake infrastructure inside the Emma product. When a customer buys the service, Emma'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 Emma side reaches into the directory, finds the file, and imports the records into that customer's Emma account. One university keeps its lists current this way with roughly 8,000 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 Emma 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 Emma 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 Emma's product.

• A customer with no development capacity gets a real, recurring integration: records leave its own systems and appear in its Emma account with nobody keying data or emailing spreadsheets. The large majority of Emma'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, Marigold'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 weekly with the service's director and its solutions architect, showing where data is growing across hundreds of tenant directories.

“That allows us to see where we're seeing any kind of expansion in terms of data and determine why or if it's necessary.”

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

The Integration Is Now Part of the Sale

Today, Marigold sells file-based integration in the same conversation where it sells Emma. 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.