How I work
These are the principles I actually work by. Most of them came from a mistake, a customer, or a time on the floor with an operations team.
Principles
Prevent the contact. Don’t just deflect it.
The best customer-care interaction is the one the customer never needs. Deflecting a call to a chatbot moves the work around. Fixing the reason for the call removes it.
Count real resolution, not reported containment.
A conversation that ends without a person is not always a solved problem. Sometimes the customer gave up. I count a contact as resolved only if the customer doesn’t come back, give up or get escalated, and I read the conversations to check.
Set a baseline before taking credit.
Before I say a launch worked, I want to know what would have happened without it. That means comparison groups where we can have them, and the words “associated with” where we can’t. Sometimes the honest line on a slide is that no launch can be credited yet.
Read the raw records before concluding.
Dashboards summarize. Conversations, calls and records show what actually happened. When a draft says it knows the cause, I ask how it knows, and I check what the data field really means with the people who own it.
Don’t grade your own work.
Before a number goes up to leadership, someone or something that didn’t produce it checks it. I re-check experiment results before they drive decisions, and my own estimates get an independent check.
Ship small, behind a switch you have tested.
New features go out to a small share of customers first, behind a kill switch that has been tested in production. Each ramp is earned. When something goes wrong, the switch goes off in minutes and the root-cause analysis follows within a day.
Fix the system, not the symptom.
When the same problem comes back, the design is wrong. I’d rather change where a decision is made, or which system is the source of truth, than patch the same approach again.
Build the capability once. Let every channel use it.
One flight-status service for chat, voice and messages. One Hertz service for every AI assistant. One proven setup reused across Hertz, Dollar and Thrifty.
Go to the floor. Use the service yourself.
I train frontline teams myself, book my own pickups and run my own test bookings. The best requirements I’ve written came from standing next to the people doing the work.
Keep a person within reach, and make no promise the system can’t keep.
Every AI channel keeps a one-step route to a person. And the AI never promises something, like a transfer, that the system can’t deliver.
AI should reduce effort, not add novelty.
I wrote this about our voice agent, and it applies to everything: “our goal wasn’t just to ‘add AI to voice.’ It was to remove friction from one of the most common customer needs.”
Lead with the verdict, bad news included.
Leadership gets the answer first, then the reasons, then the gaps. If a plan can’t hit its target even at full execution, I say so in the first line.
How I run things
- I report to senior leadership every week on the metrics I own. Every number traces to a source, and when we can’t credit a result to our work, the slide says so.
- I build the operating machinery as well as the product: launch logs, incident runbooks, experiment trackers and a weekly note in three parts: wins, watchouts and what’s next.
- I run vendor partnerships with one shared definition of success. With Decagon that means quarterly reviews, a joint roadmap, incident response and one agreed definition of what counts as resolved.
- I train frontline staff myself, and I spent four days at an airport using the service as a customer and working alongside operations.
- I lead a team of four product managers across the US and India, covering Customer Care, the Hertz app and Hertz Premier Curbside.
How I use AI in this work
I use AI to do the legwork and to check my own reasoning, and I keep the decisions. The tools, and the rules behind them, are on the Lab page.