Adams Outdoor Advertising

The everyday problem: building a proposal meant working around the tool rather than through it. Account executive name, email and phone were retyped on every single proposal. Inventory line items came back in an order nobody could predict — and in several markets the order a proposal is presented in genuinely matters commercially. Maps and supporting creative were assembled by hand, outside the builder.

The root cause, which mattered more: none of that was user error. The Proposal Builder worked; its architecture was rigid. Adding a slide, changing an order, or pulling in outside content all required a workaround, so the people using it every day built their own. A tool that has to be worked around is a tool that quietly sets the ceiling on how fast a sales team can move.

The wider context: Adams was already mid-transformation — replacing twenty-year-old software and rolling out AI role by role across roughly 350 people, while carefully managing how much change any one team absorbed at once.

Three custom extensions now run in production inside the platform their sales teams already use, rather than as separate tools alongside it.

And the rebuild now under way is not our reading of what Adams needs. Their own Sales Operations team wrote the scope from the user's side — what the tool should do, not how to build it — so the changes being made are the ones the people who build proposals every day actually asked for. The larger items are sequenced behind their real dependencies rather than promised early.