Perk Moved Tender Contracts From WeTransfer to Governed Files.com Share Links

Perk, formerly TravelPerk, is a corporate travel and expense management platform serving businesses across Europe and the United States. When a company puts its travel programme out to tender, Perk's bids team responds with tender contracts and questionnaires. Those files are too large for email, and they go to the very companies deciding whether Perk can be trusted with their corporate travel and spend data. Getting large documents to a prospective customer, securely, is built into how Perk wins business. Perk needed to bring that delivery under the security team's control without changing the email-based workflow that made WeTransfer easy to use.

Tender Documents Were Leaving Through a Tool Security Could Not Govern

The bids team's answer to "too large for email" was the one that takes hold on its own at most companies: WeTransfer. Nobody selected it as policy. It was simply the easiest way to get a big file to a customer, and it worked, which is exactly how a consumer sharing tool ends up carrying the commercial documents of deals in progress.

The cost sat with the security team. Matt McKay, Perk's Security Operations Manager, could not centrally require a password, expire a link, restrict who opened it, or see what happened to a file after it left the company. Every tender that went out repeated the same exposure: client-facing contract documents travelling through a service outside Perk's governance.

The gap stood out more as the rest of the group's file exchange came under control. Files.com had entered the group through an acquisition, and McKay had taken the site over and hardened it to his own standard: enforced two-factor authentication, locked-down protocols, permissions scoped team by team. Tender sends through a consumer tool were traffic still running outside that boundary.

As Easy as the Tool It Replaced, or It Would Not Stick

Any replacement had to clear the bar WeTransfer had set. The bids team is not a technical audience; their work lives in email, and the job is getting a contract in front of a customer, not operating a transfer tool. McKay's requirements were plain: as simple as possible for the people sending, simple for him to administer, and secure. One requirement was specific. The link had to go inside the normal email a bids manager was already writing, not arrive as a separate message from a separate system. A sanctioned path with more friction than the unsanctioned one does not stay adopted; the consumer tool would win again on the same terms it won the first time.

Perk selected Files.com Share Links to carry the sends, on the site the security team already ran.

A Share Link Pasted Into the Email They Were Already Writing

A bids manager uploads the tender contract or questionnaire, generates a Files.com Share Link, and pastes it into the outbound email. The customer clicks and downloads in the browser. There is no account to create and nothing to install, on either end.

The governance travels with the link rather than depending on the sender. McKay set access control, password protection, and expiry centrally, so every link carries them and no sender can skip them or has to think about them. Activity on a link is recorded on the site, so whether a customer collected a file is a lookup rather than a guess. McKay tested the workflow with colleagues before handing it to the bids team.

The Same Send, Now Under the Security Team's Control

With Share Links carrying the tender sends, Perk replaced an ungoverned consumer channel with a delivery mechanism its security team controls, and the bids team's job did not change to get there.

• Every tender document leaves under password protection, access control, and an expiry date, set centrally by the security team rather than chosen send by send.
• The sending workflow is the one the team already had: write the email, paste the link. Customers download in a browser with no account and no software.
• What went out, and who downloaded it, is on the record in the site's logs instead of inside a consumer account nobody at Perk owned.
• None of it is specific to one team. The policies live on the Files.com site, making the same governed path available to the next team that needs to send a large file to a customer.

Displacing Shadow IT by Matching Its Friction

WeTransfer took hold at Perk because it was the easiest way to do the job. It was displaced the same way: not by a policy telling the bids team to stop, but by a governed link that fit inside the email they were already sending.