Introducing Interfaces: Turning Workflows Into Usable GTM Plays

For the last year, nRev has been doing one thing exceptionally well.

We’ve been building workflows.
A lot of them.

Workflows that automate outbound, surface intent signals, enrich accounts, classify personas, personalize messaging, and stitch GTM systems together in ways traditional SaaS simply can’t.

And along the way, a pattern became impossible to ignore.

Many of these workflows were reusable across customers.
But almost every time, they needed a small tweak.

Change the ICP.
Update a competitor list.
Modify a region.
Adjust a signal threshold.

So users did what they had to do.

They opened the workflow builder and edited the flow.

It worked.
But it wasn’t the future we were building toward.

The Problem With “Forms as Input”

At first glance, this feels solvable with forms.

Just add a form at the start of the workflow, right?

Not quite.

Forms break down quickly.

They:

• Duplicate the same inputs across multiple nodes
• Force users to configure entire nodes just to change one value
• Increase cognitive load with every added step
• Still require users to enter the builder, even when they shouldn’t

In short, forms treat workflows like technical assets.

We wanted to treat them like products.

The Bigger Insight: Workflows Are Too Powerful to Be This Hard to Use

Most GTM teams don’t want to:

• Manage 25+ tools
• Debug APIs
• String together brittle workflows
• Reconfigure logic just to test an idea

They want to:

• Try ideas quickly
• Reuse what already works
• Focus on outcomes, not infrastructure

That’s when Interfaces became inevitable.

What Are Interfaces?

Interfaces are a new way to run workflows without touching the builder.

They sit on top of existing workflows and expose only what actually matters:

• The few inputs that change
• The outputs users care about
• A clean way to run, stop, resume, and review results

Think of Interfaces as the consumer layer for workflows.

This is what allows:

• Plays to be truly plug-and-play
• Non-technical users to run complex GTM automation
• Teams to experiment without fear of breaking logic

Why Interfaces Are Fundamentally Different

1. Workflow Variables, Not Repeated Inputs

Instead of filling the same criteria across multiple nodes:

• Declare a variable once
• Reference it across the entire workflow

Example:

• ICP criteria used in 3 different nodes
• One variable, reused everywhere

Change it once.
The entire workflow adapts.

This is the difference between configuring and operating GTM.

2. No More Node-Level Cognitive Overload

Earlier, changing one idea meant configuring entire nodes.

Now:

• Only the required fields are exposed
• Users don’t see 12 fields when 1 will do
• Complexity stays hidden where it belongs

The workflow remains powerful.
The interface remains simple.

3. Run Workflows Without Ever Seeing the Builder

This is the real shift.

Not every user should:

• See workflows
• Understand logic
• Touch configurations

With Interfaces:

• Builders build once
• Everyone else just uses the play

This is what makes nRev usable beyond power users.
And it’s what makes Plays actually scalable inside teams.

A New Addition: Proving Value Before Integrations

As we rolled out Interfaces, another truth became clear.

Even the best workflows can hit friction early.

Consider a powerful play that:

• Listens to a Slack message
• Parses a free-text query
• Finds and classifies relevant people
• Responds back in Slack

The value isn’t Slack.

The value is finding the right people from a simple text input.

But to try it, users still need:

• A Slack install
• Bot permissions
• Admin approval

That’s friction before value.

So we extended Interfaces further.

Start and End Nodes: Try the Play, Skip the Friction

With Interfaces, you can now:

• Replace trigger nodes with Interface inputs
• Replace output nodes with Interface results

Same workflow.
Same logic.
No integrations required for first-run value.

Behind the scenes:

1. Nrev asks a question in the interface
2. The user responds in plain language
3. AI structures the input into a compatible dataset
4. The workflow runs as-is
5. Results are shown directly in the interface

Multiple start and end nodes are supported.
Tables stay intact.
Nothing gets “demo-ified.”

This lets teams:

• Experience real value instantly
• Understand what the play does
• Build confidence
• Integrate later, when it actually makes sense

Two Clear Experiences: Builder Flow vs Consumer Flow

We’ve intentionally split the journey.

Builder Flow

For advanced users who:

• Define workflow variables
• Design interfaces
• Control logic and structure

This happens inside the builder.

Consumer Flow

For everyone else who:

• Enters inputs
• Runs workflows
• Views outputs
• Tracks credit usage

No builder.
No risk.
No friction.

What You Can Do With Interfaces Today

• Run GTM plays with just a few inputs
• Combine first-, second-, and third-party signals
• Experiment with activation patterns safely
• Review outputs with AI-generated summaries
• Resume failed or stopped runs
• Understand credit usage transparently

Yes, this works for live workflows too.

Why This Matters for the Future of GTM

We don’t believe the future of GTM is:

• Bigger SaaS platforms
• More features
• More rigid best practices

We believe it’s:

• Smaller, composable systems
• Proven automations
• Faster experimentation
• Less technical overhead

Interfaces are a key step toward that future.

They turn workflows into products.
They turn complexity into invisible infrastructure.
They turn GTM into something teams can actually move fast with.

What’s Coming Next

This is v0. Sign up and try it today and stay tuned for the upgraded version.

Final Thought

Only about 20% of any SaaS product truly fits a customer.
Yet customers pay for 100%.

Interfaces are our way of changing that.

Build once.
Reuse endlessly.
Prove value early.
Experiment freely.

This is how GTM becomes autonomous.