Thesis

Effective AI needs a working process, a clear source of truth, and someone who owns how data flows.

Examples / 03Span / 2017 to presentCompanies / Salesforce · Coinbase · AAA

I learned this the hard way: building integrations at Coinbase, then putting guardrails around the lead-to-quote agent at AAA. This holds up as technology evolves from workflows to agents.

The work

Three examples.

Three products from three eras of technology. Pick one to see the thesis at work.

Pick an example.

AAA · 2025 to present

The Smart Quote Agent

Branch sellers built every quote across 20 screens. I built an Agentforce agent that takes a lead to a finished quote in a single prompt. It now has 511 weekly active users.

I could easily have copied the lead creation form and the lead conversion experience into a chatbot. Instead I started from what the seller was actually trying to do: get a quote in front of their customer as fast as possible, so they'd have something concrete to react to.

92%
faster quotes
511
weekly active users
20→1
screens to a single prompt
23%
higher sale price for inside-sales users
Thesis check
  • Working process. I cut every step that wasn't getting the seller to a quote, and the chat asks for the minimum required info. Optional details are never asked for, but they're used when the seller gives them.
  • Source of truth. The chatbot works under the same permissions as the screens, so it can only change what the seller could change themselves.
  • Data flow. Its records are technically created by an API user, which would have assigned them round-robin like website leads. I caught that early and built the mechanism that assigns them to the seller chatting instead.
Coinbase · 2020 to 2023

Code red: the case creation flow

Customers were waiting over three weeks for an initial response to their support case, and our reputation was taking a hit. The CEO declared a code red and assembled a dedicated response team from every impacted group. I joined with my integrations team and scoped us to case creation while other teams took case resolution. We worked around the clock, and no change was too small if it moved the backlog.

I had the team inspect the creation flow: what data was sent on the case creation call, and what the validation step actually needed. The bottleneck was a user validation calling our master data management system, the source of truth for customer data. Calling into our internal database to validate core customer information was taking forever, so I decoupled the two. Cases were created first and the verification ran in parallel.

That became our architecture pattern. File uploads needed an Opswat virus scan before entering a Coinbase system, so I had the team run the scan in parallel too instead of letting it block case creation.

When the team started load-testing Salesforce to find its upper limit, I redirected them. Chasing the theoretical max wouldn't answer the real question. We tested against 10x our peak volume and our forecasted growth instead.

86%
decrease in initial response time, from 21 days to 3 days
2wks
case-creation fix shipped in one sprint
Thesis check
  • Working process. I understood that creating a case didn't have to mean assigning it right away. I was comfortable enriching the record after the fact when others weren't, and I assured them the assignment rules wouldn't fire until the case was ready to be worked. We fixed the technical issue while keeping the business process intact.
  • Source of truth. I kept the master data management check but stopped letting it block creation. I set load targets from 10x real peak volume and forecasted growth, not a theoretical max.
  • Data flow. We made the data flow asynchronous. The case record was created first and appended after the fact, instead of making creation wait on every check. That unblocked the critical bottleneck and let us scale in unprecedented times. I set the rule going forward: anything that adds a step or blocks a case from getting created would be flagged as an anti-pattern during architecture reviews.
Salesforce · 2017 to 2018

Campaign Insights: Pardot's first machine learning

I owned the Campaigns product line in B2B Marketing. Salesforce had just acquired a team of machine learning engineers and data scientists in Tel Aviv, and I flew there to roadmap with them directly. We started from one question: what data do we actually have, and what could we build with it?

We built Pardot's first machine-learned capability: Campaign Insights. While a campaign was running, it surfaced what was resonating: which titles were engaging, which send times worked, how it compared to similar campaigns. No dashboards to build.

I ran the beta on real customer data and sat in feedback sessions on whether the insights and the UX resonated, then iterated from there. It launched in September 2018 as a new license. In its first year, my feature was attributed tens of thousands in additional revenue.

1st
machine-learned capability in Pardot
2018
launched in September
Thesis check
  • Working process. Marketers needed to act mid-campaign, not analyze after. I built for the in-flight decision instead of another retrospective dashboard.
  • Source of truth. We started from the data we actually had, and I validated the models against real customer data in beta before launch.
  • Data flow. I decided what flowed into the model. The most useful information for marketers was tied to their audience, so I pointed the insights at Account and Contact details carried through Campaign Membership: title, location, industry, company size, etc. I also tied the data to sales closing from that specific campaign, so the insights stayed relevant to the running campaign instead of generic across all time.
Contact

Let's talk.

christina.r.petersen@gmail.com