Before You Buy Another Tool: Process, Five Metrics, Agreed Definitions

Emily Goh · 2026-11-05

On 5 November I hosted the first Fireside & Firefights, live on LinkedIn, with Leore Spira, a Revenue Operations and GTM Strategy Leader and one of Gohvio's founding advisors. We went back to basics: what comes first, before the dashboards, the workflows and the AI. Here are the key takeaways and the questions we covered. Watch the full hour on LinkedIn, or the short clips on the Fireside page.

Key takeaways

1. Fix the process before you buy the tool. Usually it's the process, not the tool.
2. Start with five metrics, not a hundred. A few agreed numbers are enough to make decisions.
3. Agree what each number means and who owns it before you choose the system. The system question gets easier once that is settled.
4. Involve the team before you buy anything. They are the people who will use it every day.
5. Write down who can delete data, and keep complex changes off Fridays. Leore learned it the night she deleted the pipeline.

Q&A with Leore

Leore's answers are condensed and lightly edited from the recording.

How do you tell a process problem from a technology problem or a people problem?

Usually it starts with the process. When a team keeps buying technology, it is often making up for a process problem. When the process still isn't fixed, people feel the friction, and it starts to look like a people problem. So I work in order: build the process, bring in the right technology, build the integration, create the data and the transparency, and only then provide the metrics.

How many metrics should a RevOps team start with?

We don't need to start with tons of metrics. I keep a list of more than 100, but at a new company I pick three to five, ten at most, depending on the stage. The obvious five are win rate, average deal size, average sales cycle, pipeline generation and conversion rates. That gives you enough transparency to make decisions, prioritise processes, choose tools and plan the budget.

When leadership, sales and finance read the forecast differently, where do you start?

Usually I start with the definitions and ownership. Once we agree what a number means and who owns it, deciding which system holds it is much easier. If the system can't support it, we can shift the ownership. If the owner doesn't want to own it, we allocate the resources to support it. ARR, close dates and subscription dates can mean different things inside one company, and that happens everywhere.

How do you get a team to adopt a new tool?

I never bring a tool if the team is not involved, because they are the end customer. I pick one or two champions. They help choose the use case, join the demos, set the success criteria and later help onboard new hires.

What was your biggest fire?

I deleted the pipeline. I had a backup from the day before, so I stayed up all night putting the data back into Salesforce, checked every opportunity against my notes before the forecast meeting, and told my VP of Sales what happened. Since then I am very strict with data management policies, especially now with AI tools. And I don't do anything complex on Fridays.

Will AI replace RevOps?

I don't think AI will replace us. I think it will be a multiplier. But AI can't build the foundation on its own. You still need a strategic person who can design the process and run the forecast in a way that gets results.

My take

Different teams can mean different things by "ARR" or "closed won". That is allowed. What can't happen is nobody knowing. Write each meaning down, name the owner, and the argument changes from "whose number is right?" to "which definition are we using?"

What to do on Monday

1. List the tools you bought in the last 12 months and the process problem each one was meant to fix.
2. Write down your five metrics. If you have none, start with Leore's five.
3. Give each metric one sentence of meaning and one owner.
4. Write down who can delete or export records.

Where Gohvio fits

Gohvio helps with the definitions step and with checking records against them. You upload your own guardrails, the definitions your teams actually use, as a document. A person approves them, and each change is recorded with who changed it and when. Gohvio then checks your CRM data against those guardrails and shows what is broken, what it does to pipeline and forecast, and the rows behind every finding. It is read-only: it reads your CRM and does not write to it.