Judgment, Grounded.

The Other Business

The client operates several hundred franchise locations across the United States, selling batteries, lighting products, and device repair to retail consumers. The retail stores are easy to understand. Walk in, buy what you need, leave.

The wholesale bid business runs on a different model. The same company competes to supply hospitals, government facilities, and large corporations through formal bid processes. These are not walk-in orders. A single contract can represent hundreds of thousands of dollars in product. The company bids against competitors to win them.

That business had no infrastructure to support it.

No Map, No Margin

Bids came in through a mix of email, disconnected forms, and institutional memory. There was no validation on what got submitted. No routing to the right approvers. No record of what happened to a bid after it left the field rep's hands.

There was also no analytics.

When a field rep needed to price a contract, the questions that mattered were also the hardest to answer. How much inventory is available for the SKU in this bid? What does that represent in weeks of supply? Is this customer a real buyer, or are they shopping for a better price from their current supplier? What margin is required to make this order worth prioritizing over existing wholesale commitments?

Some answers lived in systems that did not connect to each other. Others lived in the experience of people who had been doing this long enough to develop instincts.

Leadership could not see what was in flight. Budget owners worked from periodic email check-ins. Win and loss data existed, but no one had assembled it into anything useful.

Decisions were made. Contracts were won and lost. The reasoning behind each one was undocumented and impossible to improve on.

Start With the Decision

Before touching Salesforce configuration, before designing a single table in BigQuery, the engagement started with a more fundamental question: who needs to decide what, and what information do they need to make that call?

The answer required working through the bid process role by role. Field reps. Coaches. Pricing managers. Corporate approval teams. Each role made different decisions. Each decision required different information.

The sessions were remote. The approach was deliberately tangible anyway. Virtual sticky notes. Process maps built in real time with the people who actually owned each step. The goal was not to document a process. It was to understand what decisions people were already making, and what would have to be true in the data for those decisions to be grounded.

That mapping produced a clear picture: the strategy each role was accountable for, the decisions required to execute it, the questions that drove those decisions, and the data sources that could answer them.

That picture is what the engineering team built toward.

What We Built

The Salesforce configuration handled the operational layer. Bid submissions with validation. Routing through coaches and pricing managers. Escalation paths for exceptions. Win and loss capture at resolution.

Getting data out of Salesforce required more groundwork than the configuration itself. The team mapped each custom object in the new bid workflow, identified which ones were accessible through the client's existing ETL tool, and built custom connectors for the objects that were not. Each step in the process needed to be captured reliably before any of it could be analyzed.

That data landed in BigQuery. The structural question was how to model it. The client already had a mature data warehouse: product analytics, profitability models, finance tables, historical sales data. Building a standalone bid analytics model would have meant rebuilding logic that already existed and had already been validated.

Instead, the bid data was structured to conform to those existing models. A new bid record could join directly against the product catalog, margin tables, and sales history without additional transformation. The analytical work inherited years of prior investment.

That foundation powered two purpose-built interfaces in Looker.

The bid manager view addressed the questions that had gone unanswered on every previous bid. For any open opportunity, a manager could see current inventory for the relevant SKU alongside a weeks-of-supply calculation that accounted for retail and wholesale demand already committed. Margin was visible at different price points, pulling directly from the client's existing profitability models. Customer bid history showed whether this account had converted on past bids or consistently used them as negotiating leverage with other suppliers. Hard pricing floor constraints were surfaced before negotiations started, not after.

The leadership view replaced the email check-in. Every active bid was visible in one place: current status, margin tier being offered, and the portion of bid budget already committed across the portfolio. Win rate data, which had existed in disconnected records, was now assembled and filterable. Leadership could see not just what was in flight, but how the overall bid program was performing.

Judgment, Grounded

The rep pricing a hospital contract still makes a judgment call. That is not the part that changed.

What changed is what the call is based on. Current inventory. Historical margin at similar volumes. Whether this customer has bought through past bids or used them to extract concessions from other suppliers. How many other active bids are drawing from the same SKU pool.

Leadership no longer has to ask what is in flight. That information exists by default.

Both outcomes trace back to one decision made at the start: understand what people need to know before designing how to capture the data. A pipeline built to answer the wrong question creates false confidence. Getting the question right is not preliminary work. It is the work.