Revenue teams often ask for better dashboards when the underlying process is still unstable. Eli Kaufman's approach starts one level lower: get the architecture right before asking the reporting layer to tell a coherent story.
His path to that conviction moved through Fenway Park, ticket sales, Madison Square Garden, a personal reset, and a deliberate move into sales operations and technology. The route was nonlinear. The lesson is precise: reliable insight depends on reliable operating foundations.
Frontline sales made the architecture real
Eli's early career inside the Red Sox organization included writing Fenway Park announcements and eventually selling tickets. He understood the venue, the product, and what different buyers valued.
That context helped him close complex, high-value season-ticket agreements. It also showed him that a CRM record is only a compressed version of a much richer sales process.
When Eli later moved into operations, he brought that frontline perspective with him. Stages, activities, and fields were not abstract reporting constructs. They represented real buyer movement and real seller behavior.
A difficult reset created a new operating path
After Eli's mother died unexpectedly, returning to an activity-heavy sales environment made the mismatch between the work and his priorities impossible to ignore. He asked where the organization had unmet needs and was directed toward sales operations.
He taught himself Excel and data analysis, began filling gaps, and eventually faced a larger career decision: continue inside sports or move into technology.
The transition required learning new systems quickly. A manager gave him responsibility for Salesforce and access to experienced RevOps guidance. That combination, trust plus exposure to a full-funnel operating model, accelerated the shift from reporting support to systems architecture.
Fix the scaffolding before the surface
Eli now describes several nonnegotiable foundations:
- A sales process that reflects how opportunities actually move
- Explicit entry and exit criteria for each stage
- Timestamps for stage changes
- Reliable routing and ownership
- Consistent data definitions
- Visibility from early intent through renewal
Without those elements, a dashboard can be visually polished and analytically misleading.
For example, conversion rates mean little when sellers interpret stages differently. Sales velocity cannot be trusted when stage movement is not timestamped. Forecast analysis breaks when exit criteria are subjective. More reporting does not solve those problems; process design does.
The first 90 days should begin with learning
Eli advises new operators to be a sponge before proposing major changes. The existing system may be messy, but it usually contains evidence of earlier constraints, decisions, and political realities.
A new leader should map stakeholders, learn how teams work, and understand why the current design exists. That does not mean preserving poor architecture. It means distinguishing accidental complexity from complexity created by a real business requirement.
This listening period also creates trust. Teams are more likely to support a redesign when they believe the operator understands the work being changed.
A team of one must create strategic bandwidth
At Sweep, Eli operates with substantial technical and stakeholder demand. That creates the familiar solo-RevOps tension: urgent requests can consume the time required to prevent future requests.
The path out is not simply working faster. It is building reusable foundations, documenting decisions, setting clear intake rules, and automating recurring work. Each improvement should create a little more capacity for the operator to advise the business.
That advisory role is where RevOps becomes most valuable. CEOs and CROs may have access to dashboards without having a complete view of conversion mathematics, pipeline quality, renewal risk, and the assumptions connecting them.
Documentation protects the operating model
Hard stage criteria and written process definitions reduce stage drift, sandbagging, and reporting fiction. Documentation also prevents architecture from becoming dependent on one person's memory.
The goal is not a static manual. It is a shared explanation of how the system is intended to work and why. When the motion changes, the documentation changes with it.
That makes future iteration safer because the team can identify which assumption is being altered rather than layering another exception onto an unexplained system.
The practical lesson for RevOps teams
Before building the next dashboard, test whether the underlying process can answer four questions:
- Does every stage have an observable meaning?
- Is ownership clear at every handoff?
- Can the company measure movement accurately?
- Do teams use the same definitions?
If not, reporting is downstream of the problem. Fix the architecture first.
About the guest
Eli Kaufman leads Revenue Operations at Sweep. His career spans sports entertainment, ticket sales, sales operations, CRM administration, and full-funnel RevOps architecture.
