🔒 Private — prepared for Briana and Cindi (RCB principals). Not for staff.
Overview / Session Notes / Briana — AI State of Play

Session Notes: Briana — AI State of Play

2026-06-01 · Nate and Briana · ~30 minutes

Overview

This session was a focused conversation about where RCB Awards currently stands with AI tools — what they've tried, what's working, what's stalled, and where the interest is. Briana led, approaching it from the front-office perspective (customer service and order entry) rather than the production floor. She described three specific areas she's been actively thinking about or experimenting with: email template drafting, freight quoting, and pricing updates. The conversation also touched on order volumes and the limits of the Microsoft ecosystem.

Email Templates and Customer Service Communication

Customer service email is a significant daily time sink. Orders, questions, artwork revisions, and status inquiries all come into the shared inbox, and the team handles each one individually. To help manage this, RCB has built a 30-page document of email templates — standard responses to the most common situations, particularly in the wholesale channel where the same questions tend to recur.

Currently, when an email comes in, a team member reads it, determines what kind of response it needs, locates the appropriate template in the document, copies it, customizes it, and sends it. They also manually categorize each email (new order entry, art revision, urgent status request, etc.) as part of managing the inbox.

Briana wants to use AI to short-circuit the most repetitive part of this process: reading the email, identifying what it needs, finding the right template, and drafting a starting point for the reply. She was clear that the goal is not to have AI send anything automatically — she wants a draft that a human reviews before it goes out.

She attempted to build this using Microsoft Copilot and Power Automate. The experience was frustrating: Copilot pointed her toward Power Automate, she built a flow, it didn't work, troubleshooting led to more Microsoft products (Copilot Studio, Azure), more subscriptions, and more complexity — and after a couple of hours she gave up. She subsequently tried using Claude in Excel, found it meaningfully better than Copilot for that kind of analytical work, and has largely moved away from trying to build within the Microsoft toolset.

Freight Quoting Tool

Every project requires a freight quote before it can be finalized. The manual process goes like this: take the part number, quantity, and shipping address from the purchase order; look up the product's case dimensions in the product reference; log into UPS; enter the case dimensions, number of boxes, and destination zip code; run batch rates to get ground, two-day, three-day, and overnight pricing; then apply RCB's markup formula (which accounts for packaging, time, and labor) and provide the quote to the customer.

Briana estimated this takes about four minutes per project. They also field phone calls asking for freight quotes on top of the written requests.

She built a working version of this in Claude: she could drop in the purchase order, and Claude would log into UPS using her credentials, retrieve rates, apply the markup, and output the quote. It was working. Where things broke down was in the next step — she wanted to make it something the whole team could use without requiring each person to have their own Claude subscription. Claude began helping her build a standalone executable (.exe file) to solve that distribution problem. At the same time, she had provided Claude with her UPS login credentials, fetched a UPS API key, and given it access to SharePoint — and at that point she said it started to feel like too much access was being granted to get comfortable with, so she stopped.

Nate noted that this is a legitimate build, not a one-day fix — the right approach would be a small application that anyone on the team can access, that handles the UPS API call securely, and that applies the markup formula in a documented and auditable way.

Pricing Update Process

RCB sells approximately 500 products. Product pricing depends on vendor costs (which fluctuate), plus labor, freight, artwork, and order entry allocations that RCB factors in through their own formula. When a major vendor changes their prices — which happens a few times per year, usually with a couple of weeks' notice — RCB needs to update their pricing across multiple systems: their internal order management system, Sage (the promotional products industry platform where distributors see their catalog), and at least one other distributor channel, each with different import template formats.

A team member named Karen, who has an electrical engineering background, has been leading this project for nearly a year. The work involves: taking the vendor's new Excel price sheet (which can have 10,000 or more line items, of which roughly 1,000 are relevant to RCB), identifying the changed prices for RCB's products, calculating the deltas, applying RCB's markup formula, and outputting the results in three different import templates. Karen recently finished building a piece that handles the transformation from the master pricing sheet into those three export formats. Before that piece existed, a full price update took approximately a week. Now it takes around 10 hours.

Briana described the business cost of not keeping up with pricing changes: last year, drinkware prices went up twice and then came down. Because the decrease wasn't caught and applied promptly, RCB's drinkware products were overpriced on the distributor marketplace for several months — customers were declining them in favor of competitors — and they lost what Briana described as a substantial amount of market share before catching and fixing it a couple months ago.

The current system has two significant problems. First, only Karen understands how to run it — Briana cannot operate it independently, and if Karen were to leave, it would need to be rebuilt from scratch. Second, it's been used only once since the recent piece was added, so it's not clear yet whether it's fully reliable in practice.

The ideal state Briana described: drop the vendor's updated price sheet into a folder, and have the system identify what changed, flag significant changes (a small increase that doesn't need immediate attention versus a large one that does), and automatically populate all three import templates so they're ready to upload.

Order Volume Context

Nate asked about order volume to understand the scale of the front-end workload. Each inside salesperson is managing approximately ten active projects at a time. Across the team, order entry runs between roughly ten and fifteen orders per day, though "order" spans a wide range: a simple reorder can move through the system in fifteen minutes, while a new customer with artwork changes and stock complications can take weeks of back-and-forth. Most orders are toward the smaller, faster end of that range. The friction is unpredictable — smooth orders are quick, but stock-outs, artwork problems, or new customers requiring mock-ups and pricing discussions can extend the cycle significantly.

Follow-Ups

  • Briana offered to share the Breakwater brand brief with Nate.
  • The shared inbox and order entry workflow were flagged for a separate, detailed walkthrough (covered later in the day).
  • Karen's data and pricing work was noted as a topic for deeper conversation — Nate wants to understand the current system in detail before forming a view on what to do with it.