A Furnished-Apartment Operator Replaces S3 Downloads and Email Attachments With Trackable Files.com Links

A global furnished-apartment operator manages homes for stays of a month or longer. It leases homes from landlords, furnishes them, and rents them to relocating professionals, corporate clients, and travelers, managing each home on the landlord's behalf. The network spans tens of thousands of homes across several continents.

That model puts the operator permanently between two parties who will never log in to its systems: the landlord who owns the apartment and the guest who lives in it. When an apartment is damaged, evidence has to travel to both. Before-and-after photos and video document a broken pipe or a damaged floor for the landlord, and sometimes go to the guest as well. Every one of those exchanges crosses the boundary of the operator's own platform.

Across four teams, that evidence moved through a manual S3-download-and-email routine, and the operator wanted a record of what happened to each file after it was sent. Files.com replaced it with logged links while S3 remained the system of record.

Every Damage Claim Started With a Download and an Email

The media lived in Amazon S3, and the only way to get it to an outside party was by hand. An employee opened the bucket, downloaded the photo or video, attached it to an email, and sent it. Admins, customer experience agents, support staff, and accountants all ran this same routine, over and over, across a portfolio of tens of thousands of homes.

The cost landed in two places. The first was time: a repetitive manual chore spread across four teams, sitting in the middle of every damage conversation. The second was the record. The operator wanted to know whether a landlord or guest had opened the files it sent, and an attachment gives the sender no way to check.

Landlords and Guests Were Never Going to Get Accounts

The obvious fixes were closed off. Landlords and guests worked entirely outside the operator's admin tooling, and provisioning accounts for them was never on the table. Meanwhile, the media's system of record was S3, and the operator needed a governed, trackable way to share files with outside parties. Solving the problem meant either building that delivery layer in-house or putting one over the existing buckets without moving the data.

That shaped the requirements. The operator needed to deliver photos and video to recipients who hold no account and never will, keep a record of what happened to each file after it was sent, and leave S3 exactly where it was as the system of record. The operator selected Files.com to be that layer over its existing storage.

Files.com Mounted Over the Buckets That Were Already There

Using Remote Server Mounts, the operator connected its S3 buckets to Files.com as remote servers. The mounted folders are a real-time window onto the media in S3: nothing was migrated, nothing is stored twice, and the buckets remain the system of record. Files.com sits on top as the delivery and governance layer.

On top of the mounts, staff use Share Links to send damage evidence outward. A landlord or guest follows the link to a web page, previews the photos in the browser, and downloads the files, with no account and no software required. Each link carries an access log, so the operator can see who opened the file.

Files.com has since been wired into more of the operator's storage estate, and share links have spread into everyday team file sharing beyond the damage workflow that started it.

A Layer Over the Storage, Not a Migration Away From It

Today, a damage conversation opens differently. Where an accountant once pulled a video out of a bucket and attached it to an email, support and accounting now send a Files.com link and can check that it was opened. Every photo and video the operator shares now carries its own access log.

The larger point is what the operator did not have to do. It did not migrate its media, retrain its teams on new storage, or build a delivery system in-house. Files.com went over the top of the storage the operator already had, and the download-and-email workflow disappeared underneath it.