The Odom Corporation Gives In-Store QR Codes a Governed Public Home on Files.com

The Odom Corporation is a privately held beverage bottler and wholesale distributor with roughly 2,300 employees across Alaska and Pacific Northwest markets. Its portfolio spans Coca-Cola products and third-party beer and beverage brands.

A portfolio that wide creates a field problem. The people standing in front of those products in retail accounts are sales reps and shoppers, and the information about any specific product has to reach them right there, at the shelf—without putting public content outside Odom’s control.

A QR Code in the Aisle, With Nowhere Governed to Point It

A sales and marketing executive at Odom started placing QR codes in retail locations. The idea was simple: a rep or a shopper scans the code on a display, and a PDF opens with information about that specific product.

“a PDF that lives somewhere in our space but is essentially open to the public.”

Simple, except Odom had no way to publish a file to the public. Staff files lived in SharePoint and OneDrive, behind the company login and built for internal collaboration. Partner files moved through an on-premises FTP server, a Windows 2003 machine that some partners reached over VPN tunnels into the internal network. Both surfaces existed to keep files away from strangers. Neither could hand a PDF to an anonymous phone in a store aisle.

The codes were already going into the field, so the gap had a clock on it. External sharing needs the sanctioned estate could not meet had already been leaking into consumer file-sharing accounts that IT neither controlled nor could see. The QR program needed a governed alternative before product content followed the same path.

Public to Any Phone, Writable by Almost Nobody

The requirement had a tension in it. The content had to be genuinely public: any phone that scans a code opens the file, with no login, no account, and nothing to install. At the same time, the content had to stay tightly held: only authorized staff writing, behind the company’s own sign-in, on a platform IT actually operates. And nobody wanted a website project for what is, in the end, a folder of PDFs.

Odom put the workload on Files.com and made it the first thing it built on the platform.

One Public Folder, Governed Like Everything Else

Using Files.com public-read folders, Odom created a single folder of product PDFs. Each file received a public URL, and the QR code printed for a display pointed to that URL. A scan opens the PDF in the phone’s browser.

Write access runs the other way entirely. It is restricted to the staff who maintain the content, and they sign in through Odom’s Microsoft Entra ID, with MFA and conditional access enforced, the same as every other internal user on the site. Every change to the folder lands in the Files.com audit log.

Live in Stores, on a Platform IT Controls

With the folder live, the QR program went into the field against a governed URL instead of a consumer sharing link.

• QR codes are in stores now, scanned by sales reps and shoppers, opening product PDFs served from a platform Odom’s IT team operates and can answer for.
• Odom’s entire public file surface is exactly one folder: readable by anyone with the URL, writable only by authenticated staff, with every change on the record.
• Publishing the next product sheet is dropping a PDF into the folder and printing a code against its URL. There is no website project and no per-document request to IT.

The Public Edge of a Locked-Down Platform

A file transfer platform is usually bought to keep files away from the public. The first workload Odom put live on Files.com did the opposite, and gave up none of the control the platform is built around to do it. Today Files.com carries Odom’s partner file exchange at one edge and hands a product PDF to any shopper’s phone at the other. For the marketing team, getting product information to the field is no longer a workaround waiting to happen. It is a folder they can write to, and a URL anyone in the world can read.