Session Notes: Freight Quote Tool — Requirements Working Session
2026-06-17 · Nate St. Pierre, Briana Riordan, Karen, Cindi
Overview
Immediately following the power-user walkthrough, Briana stayed on (with Karen and Cindi participating) to work through the freight quoting tool with Nate in a product-manager role. The goal was to pin down exactly how the tool should behave, resolve open questions, confirm what's in and out of scope for this first version, watch a few real quotes run, and capture the technical credentials needed to wire it up to a live UPS connection. Nate worked down a prepared question list and captured the answers as they went, so the requirements could be handed straight to Pete to finish building. The team also walked through how they quote freight manually today on the UPS website, which served as the reference for what the tool needs to reproduce.
The working version shown is an early, rough first pass ("quick and dirty V1") — not production-ready — used to confirm the shape of the tool and surface gaps. The numbers shown were test values, not live rates.
How the Tool Works (Shape Confirmed)
The tool lets a user either look up an item or enter specs manually. For a lookup, it reads against a product spreadsheet that RCB keeps updated and uploads into a designated folder. The user picks a part number, enters a quantity, and provides the destination zip code (with a checkbox for residential, defaulting to commercial). The tool then returns the available UPS rates, sorted from lowest cost up — which matches how RCB typically works, since UPS Ground is usually the default they're looking for. Briana liked how fast the rates came back.
Cartons, Dimensions, and the Source Spreadsheet
A key clarification was how quantity becomes carton count. The product spreadsheet lists units per carton, the full-carton weight, and the carton length/width/height. So if an item comes 12 per carton and the order is for 15 units, that's two cartons. The team agreed the tool should do this math automatically — referencing units-per-carton against the order quantity and rounding up to the next whole carton — rather than making the user calculate and enter it by hand. UPS prices freight based on the carton weight, dimensions, number of cartons, destination zip, and residential-vs-commercial status, so the tool needs all of those to return a real rate.
There was discussion about which export to feed the tool. The demo used a sample export Briana had provided earlier; the team confirmed it doesn't matter which system the export comes from as long as it's consistent and clean. The likely choice going forward is the Antera export, because not all products live in the other (Sage) export. RCB will make a clean, well-defined export the authoritative source, containing only the fields the tool actually needs. Karen is managing the product records and exports and will determine the exact field set. Cindi noted that some products aren't in every export, which is part of why the field set and source need to be settled deliberately.
For items that don't have dimensions in the sheet, the agreed behavior is that the tool auto-fills dimensions where it has them and simply leaves them blank where it doesn't — the user then keys them in by hand, with no error message or placeholder cluttering the field. A blank is the signal to fill it in.
Scope Decisions
Several boundaries were set to keep this first version simple and focused on the roughly 95% of normal, everyday quotes: - Multi-part orders: Out of scope for now. For a shipment with multiple different products, the team will just run the tool once per product and add the results up. - Non-parcel / LTL freight: Not needed. The tool only needs to handle standard carton/parcel shipments. - Markup: The tool returns clean, actual UPS costs only. RCB applies their own markup and any other transformations on their end, in their own spreadsheet — the tool deliberately stays out of that so there's less to break. - Output: Everything the tool touches gets written cleanly to a spreadsheet in a designated folder. Each quote adds a new row to a running log (rather than overwriting), giving RCB one ongoing source of truth they can use, clear, or pull from as they like. - Residential vs. commercial: The tool doesn't decide this — the user does, via the checkbox. The default is commercial.
Failure States and Edge Cases
The group talked through what happens when something's missing, and agreed not to over-engineer for unlikely failures, trusting that trained staff will fill in the required fields as part of doing the job. Because UPS itself requires complete carton information (weight and all three dimensions) to return a rate, a quote with missing information will simply be blocked on the UPS side rather than returning a wrong answer. The team agreed the tool should pass back a clear message in that case rather than failing silently.
One known edge case was noted but deliberately left un-engineered: occasionally, when entering a zip code, UPS asks the user to also pick a specific city from a dropdown. Briana, who has used the UPS tool manually thousands of times, confirmed this happens rarely. It's been logged as a known possible failure state that the tool will not specifically guard against for now, and RCB is aware of it.
Declared Value
A requirement surfaced during the walkthrough that the early version hadn't captured: RCB routinely enters a declared value on quotes. The team worked out that declared value is simply the item price times the quantity. The agreed fix is for the source spreadsheet to include the item price, so the tool can calculate declared value automatically (quantity × price) and pass it along to UPS. There's an open detail for RCB to settle: some products have price breaks by quantity, so the team will need to decide which single price to use for this calculation; the consensus was that a reasonable, consistent choice will be close enough.
Output Fields
The team confirmed the data they want back from each quote: the name of the service, the days in transit, and the cost in US dollars. If UPS also returns a "guaranteed" yes/no indicator, RCB would like to keep that as well; they don't need any of the other extra fields the UPS website displays.
Live Test and Credentials
Briana shared her screen and ran a real quote on the UPS website so Nate could see the manual process end to end and confirm the tool matches it — for example, quoting four cartons of a product to a destination returned the full range of UPS service levels and prices (Ground through Next Day Air). She also noted a default option to always prepay shipping charges, which should be the tool's default if needed.
To enable the live connection, Briana provided the UPS developer API credentials and confirmed the UPS billing account directly to Nate during the session (handled securely, not by email). One final step remains on RCB's side: confirming that the rating capability is switched on for the UPS app — Nate emailed Briana step-by-step instructions for finding and enabling it.
Follow-Ups
- Karen: Produce one clean product export with the agreed fields (ideally the full ~5,000-product list), plus a smaller backup export of the three chosen test products, and send to Nate as soon as possible — the build work depends on getting this quickly. Include units-per-carton and item price so the tool can calculate carton counts and declared value.
- Briana / Karen: Decide the three real test orders and produce their real UPS quote results to serve as the answer key for validation.
- RCB to provide: the folder paths for where the uploaded master list lives and where the output spreadsheet should go; the final list of fields for the output; and the decision on which price to use for declared value where price breaks exist.
- Briana: Confirm the UPS rating capability is enabled on the app (instructions emailed).
- Nate / Pete: Finish wiring the tool against the live UPS connection and the clean product list, aiming to have something testable by end of day.