Fraser Replaced WeTransfer With a Branded Files.com Front End for Its Azure Demo Pipeline

Fraser Advanced Information Systems is an independent office technology dealer and managed services provider that has served businesses across Pennsylvania, New Jersey, and Delaware for more than 50 years. Unusually for an equipment dealer, Fraser runs its own in-house development group, Fraser AI Labs, which builds production software around the company’s operations.
Production print sits at the top of Fraser’s line, and those sales do not start in the showroom. They start with the prospect’s own files. Before a customer visits for a color-calibrated demonstration, they send Fraser the artwork and documents they want to see printed on the press they are considering. The first thing a production print prospect ever does with Fraser is send it files.
Fraser needed those files to feed an automated demo-preparation workflow. Although its own developers could have built the customer-facing intake layer, the company deliberately chose Files.com instead.
A Consumer Transfer Tool at the Front of Every Production Print Deal
Fraser’s production print team collected those sample files with the free version of WeTransfer, and the tool behaved like what it is: a way for one person to send a file to another person. Each sample file landed in one salesperson’s email. Notifications went to that individual address, not to a team and not to any other application. The upload page carried no Fraser branding. There was no way to segment customers, and no administrative or programmatic access to anything that arrived. The only way to act on an incoming file was for whoever happened to receive it to handle it by hand.
“It’s not necessarily a business-to-business type of product.”
The cost showed up in two places. The first was the sale itself. Midmarket and enterprise prospects asked compliance and vendor-verification questions, and Fraser’s own security posture was governed by MSP Verified Compliance, a blend of CMMC and NIST controls. A free consumer transfer link was not an answer Fraser could give those buyers about how their data would be handled.
The second was everything Fraser wanted to build behind intake. Demo preparation was entirely manual: pre-sales specialists researched each prospect, went back through their notes and email history, and assembled every demonstration by hand. Fraser was standing up an automated demo-preparation workflow to take that work over, and the workflow needed files it could actually reach. Software cannot read a salesperson’s mailbox. As long as intake ran person to person, the pipeline had nothing to feed on.
A Development Lab That Decided Not to Build the Front End
The replacement had a specific shape before it had a vendor. It had to be customer-facing with zero friction: a prospect had to be able to submit files without creating an account or registering for anything. It had to carry Fraser’s brand on Fraser’s own domain. It had to stand up to the compliance and vendor-verification review that midmarket and enterprise buyers run. And behind the friendly page, it had to be fully programmable: registration details captured as structured metadata, files routed into Azure Blob Storage, everything reachable by API.
Fraser is exactly the kind of company that could have built that. Fraser AI Labs writes production software. The decision not to was deliberate.
“For this particular application, it didn’t make sense for us to develop it ourselves because it’s customer-facing, and I don’t want to have to worry about the security, the ongoing maintenance and support, even if it’s really just a front end.”
A public upload surface is a standing security obligation for as long as it exists, and it would sit directly on the compliance posture Fraser sells against. Fraser selected Files.com to be that front end.
A Branded Portal on the Homepage, Synced Into Azure Blob Storage
Fraser built a single intake point that its own developers controlled end to end, with Files.com carrying the public-facing surface.
Prospects reached a Fraser-branded portal on a Fraser subdomain, linked from the top navigation of the company homepage and carrying Fraser’s logo and colors. Built on a Files.com Inbox, the page accepted uploads from anyone: a prospect completed a short registration form and dropped their files, with no account to create and nothing to install.
That form made the intake programmable. Its answers drove the folder structure, naming, and metadata of every file, so a sample arrived labeled with who sent it and why, not as a mystery attachment. Webhook and email notifications went to the team rather than to one person’s mailbox.
From there, Files.com synced every upload into Azure Blob Storage. Files landed in storage Fraser already operated, where the company’s own code could pick them up, combine them with other data, and return a packaged demo set to the salesperson.
The controls that answered a vendor-verification review were set on the same intake point. Uploads were geofenced to the continental United States, file extensions were restricted to the types Fraser expected, every submission passed through a clickwrap terms agreement, and administrators could see all of it.
Intake Became Part of Fraser’s Public Sales Infrastructure
The portal is now part of how Fraser presents itself to buyers. A production print prospect’s first interaction with the company runs on Fraser’s brand and domain, through a governed team process rather than a free consumer transfer page.
Sample files now arrive in Azure Blob Storage automatically, already labeled with their registration data and reachable by Fraser’s code. Salespeople can receive a packaged demo set without attachments first being forwarded, filed, and matched to submission details by hand.
Fraser can also give midmarket and enterprise prospects a concrete answer to compliance and vendor-verification questions: intake is geofenced, extension-restricted, clickwrap-gated, and logged in line with the CMMC and NIST controls under which Fraser operates.
Drabouski presented the portal himself at the company’s quarterly sales meeting, introducing it to the wider business as a new piece of how Fraser sells, not as an IT change.
A Front End They Bought, a Pipeline They Own
A customer-facing intake point did not have to be an in-house build. Fraser had its own development lab and chose to buy the front end anyway, because Files.com carries the security, maintenance, and public-facing surface while Fraser keeps programmatic control of everything behind it.
The front door is bought. The pipeline is theirs.
Related Customer Stories
Software & Technology
GoDaddy Registry Replaces Its Amazon EC2 SFTP Server With Self-Service Zone File Distribution on Files.com
The registry separated vetting and entitlement from account creation, giving hundreds of approved outsiders self-service access without putting them in GoDaddy's identity systems.
Read story →
Software & Technology
Zillow Retires Ombud for Files.com to Send KYC Documents Across Six Countries
Browser-based links let recipients Zillow could not train securely view or download each sensitive document according to its own retention requirements.
Read story →
Software & Technology
Redis Gives Every Support Ticket Its Own HTTPS or SFTP Intake Route With Files.com
API-driven, write-only intake lets customers deliver diagnostics through their firewalls while Redis keeps no standing credentials for external uploaders.
Read story →