Salesforce, early Lightning days. After V1 launched, my job was to figure out which feature gaps to close first to get customers to switch from Classic. I aggregated every reason customers gave for not switching and ranked the gaps. Account hierarchies came out on top. Customers could not see how their accounts related to each other, parents and children, and that was blocking them.

The data also told me what not to build. Usage showed customers were not touching features like case routing, so those gaps were not real blockers. Account hierarchies was the only gap of its kind, blocking about 30 to 35 percent of the customer base.

The platform team had a much longer roadmap of fundamental platform work. A hierarchy UI was not their priority and would take about a year and a half. So I worked with a third-party vendor to build a Salesforce-supported AppExchange package as the bridge, and we announced it so customers could move.

The hard part was getting admins comfortable installing a package for something that would become a core feature. We identified the specific accounts and emailed their admins directly. About 18 percent of the blocked group downloaded the package and tried Lightning. We instrumented the Classic-to-Lightning toggle, so we know these were admins trying it for the first time. That is roughly 6 percent of the total base. They did not necessarily stay, but it got them to try. The execution was scrappy and we did not capture the full 30 percent.

AAA, marketing attribution. The request was simple. Turn on Salesforce campaign attribution so marketing could see first-touch and last-touch in their reports. When I looked, 36 percent of our roughly 380,000 lead records were duplicates. That is about 137,000 records. Attribution on that data would have lied to us.

So I made managing duplicates the project, with attribution to follow once the data was clean. Marketing had zero visibility into how their work tied to revenue and wanted it as soon as possible, so this was high visibility and high pressure. Once I showed them the root cause, everyone aligned fast. What I risked was the timeline. Their reaction was close to relief. They finally had a strategic partner instead of an order taker.

I worked with engineering to define what counts as a match. We set the rule that the oldest record wins, with new information appended automatically. Then I got every business unit, marketing, sales, support, to standardize on one definition. Marketing needed to trust that merged records keep the full touchpoint history.

The sellers were used to creating duplicates, and the system stopped letting them. I mapped what they were actually doing. They create a lead to start a new sale. So we routed them to the existing record to open a new opportunity instead. The real hurdle was ownership. The 14-day rule said another rep could take a record if the owner had not closed in 14 days, but it was unwritten and routinely bypassed. Duplicates made it easy to claim you did not know someone else was working the account. Now the system enforces the rule, and it turned out to be a win for the customer too. Nobody wants calls from two different reps.

This one is still in progress, so there are no final numbers yet. The payoff ahead is that marketing gets full attribution reporting for the first time.

AAA, then Arvest. When I joined AAA, the team stored nearly everything on the quote object, including the AAA membership discount. The logic was that it affected the discount, so it belonged on the quote. But membership is an account-level fact. I had them build the field on the account and reference it from every quote going forward. Static customer information gets entered once and referenced. Only the variable data, which products you are adding, gets entered on the quote.

Doing it the hard way cost us pushback and engineering time. The engineers did not disagree. They knew the data model was their ownership area, but they kept their scope to the ticket they were assigned rather than expanding it. And since the work had been implemented before them, they did not take ownership of it the way they would have if they had built it themselves. My rule is that you cannot unsee a bad pattern. Each time, I judge whether to ship now and clean up as a fast follow, or slow down and fix it first. At minimum it goes on the backlog with a date to revisit. More often than not it has to be fixed before the new work ships, because it changes the data flow.

At Arvest, the bankers were used to a single paper loan application, and the managers insisted the Salesforce build feel exactly like it. The assumption was that all the data would live on the opportunity record. I kept the single-form experience so nobody had to hop between tabs, but routed the data correctly underneath. A name typed on the loan form goes to the contact through a lookup and auto-populates. The business got the experience it wanted and did not have to care where the data lived.

I also push for referenced data to be editable where it is shown, synced both ways, so users are not hopping between objects. That only works with strong guardrails on what can be edited in Salesforce versus the core customer database. Downstream edits stay locked so the source of truth stays clean.