Sales Intelligence CLI

Give Gen H's sales team the same LightDash CLI + Claude Code tooling that Hal already uses for data analysis. Instead of standing in front of brokers with generic pitch decks, salespeople create custom, data-driven reports and presentations on the fly - showing a specific brokerage exactly how their firm interacts with Gen H, where the market is moving, and what opportunities they're missing.

Why This Is Different From Automated Reports

The automated report pipelines are about recurring reports that Hal builds once and run on a schedule - funder reports, network reports, ExCo MI. Valuable, but the salespeople are consumers, not creators.

This idea puts the tools in the salesperson's hands. They decide what story to tell a specific broker. They pull the data that supports that story. They generate the presentation. The output is bespoke, not templated. That's what makes it a sales weapon rather than a reporting exercise.

What It Looks Like

A BDM is preparing for a meeting with a broker network. They open Claude Code and say:

• "Pull the last 12 months of applications from brokers in the Openwork network. Show me completion rates, average case size, and product mix compared to our overall book."
• "Which Openwork brokers have gone quiet in the last 3 months who were previously active?"
• "Build me a presentation that shows Openwork their top performers, where they're under-indexing on product types they could be selling, and our pipeline outlook for the next quarter."

Claude reads from LightDash, generates the analysis, and produces an HTML presentation or PDF. The salesperson reviews, tweaks ("make the product mix chart bigger, add a slide on our new BTL range"), and walks into the meeting with something no other lender would ever produce for a single network.

The Sales Angle: Smart and Cool

Hal nailed the underlying sales insight: good sales is having a good business (which Gen H does) and then looking smart and knowledgeable. Custom data-driven reporting does both:

• Credibility: "We know your business" is the most powerful thing a lender can say to a broker. Showing up with their specific data proves it.
• Differentiation: No other lender is doing this. The reaction Hal wants - "wow, nobody else thinks like this" - is the same one the voice affordability calculator targets, but from the other direction (internal capability producing external impressions).
• Stickiness: A broker who receives custom intelligence from Gen H starts to see Gen H as a partner, not just another lender. That relationship is harder for competitors to displace.

Why This Is Easier Than the Underwriting CLI

The infrastructure already exists. Hal is already doing this exact workflow. The question isn't "can we build it?" - it's "can we make it accessible to non-technical salespeople?"

Specifically:

• LightDash is already connected. The data is there. The CLI works. The dbt models exist.
• The output tools exist. HTML presentations via frontend-slides, charts pushed to LightDash dashboards, PDFs. All working.
• No new system integrations needed. Unlike underwriting (which needs case management APIs, credit report access, broker comms), sales is data in, report out. The pipeline is short.
• The risk profile is low. A salesperson generating a custom report can't break anything. An underwriter making case decisions has regulatory implications. Sales is the safer pilot.

The Real Barrier: Terminal Anxiety

Hal identified this clearly: "there's nothing stopping sales doing what I'm doing right now but it's not obvious and it hasn't been set up and it goes through the terminal and terminal scares people."

This is a packaging and onboarding problem, not a technical one. The questions:

• Can you wrap Claude Code in something less intimidating? Maybe a dedicated workspace with pre-loaded skills. Maybe a simple launcher that opens Claude Code with the right MCP servers connected and a welcome prompt. Maybe just good documentation and a 30-minute pairing session.
• What's the minimum viable onboarding? Hal went from zero to productive in days. But he's technically comfortable and self-directed. Salespeople need a more guided introduction. The first session should produce something they can actually use in a real meeting - that's the hook.
• Who's the first user? Same question as the underwriting CLI: find the individual salesperson who's frustrated by the limitations of current tools and would genuinely enjoy learning something new. Not the whole team. One person.

The Risk Hal Isn't Seeing

You're now at four ideas that all run on the same thesis: "remove the interface, keep the person." That's either a genuine strategic insight or confirmation bias running hot. The validation for underwriting (shadow, build, test) will tell you whether the thesis works for one team. But be careful about extrapolating too early.

The sales use case is genuinely easier and lower risk than underwriting. If you're going to pilot one, this is the better candidate. But don't let the ease of this one convince you the thesis is universally true. It might work for sales (data in, report out, low stakes) and fail for underwriting (multi-system, decision-logged, regulated).

Suggested Next Step

Don't wait for the underwriting validation. This is cheap enough to test this week:

1. Pick the best BDM on the team - the one who'd most appreciate custom data in their meetings
2. Ask them: "If I could give you a custom report showing exactly how [specific network] uses Gen H, with charts and trends, for your meeting on [date], would that be useful?"
3. Build it with them. You at the keyboard, them directing the story. One session. One output.
4. See if their eyes light up. If they do, you've found your champion. If they shrug, the thesis might not land for sales the way it lands for you.

Connections

• Underwriting CLI - same thesis (AI as productivity amplifier, not automation replacement) applied to a different team. Sales is the easier, lower-risk pilot. If it works here, it strengthens the case for underwriting. If it fails here, question whether underwriting would be any different.
• Automated Report Pipelines - complementary, not competing. Report pipelines automate recurring reports; sales intelligence creates bespoke, ad-hoc reports. The pipeline infrastructure (LightDash CLI, Claude Code, frontend-slides) is shared. The network/corporate account reports already planned in the pipeline are the templated version of what salespeople would create on the fly here.
• Voice-First Affordability Calculator - both aim to make Gen H look smart and differentiated to brokers, from different directions. Voice calc does it through the product experience; sales intelligence does it through the relationship experience.

EA Reasoning (bootstrap mode)

- Categorised as genh-ops (internal tooling/productivity) not genh-product (not broker-facing product). The output reaches brokers, but the tool is for the sales team. Same logic as underwriting CLI. - Created as a new idea rather than merging into automated report pipelines. The report pipeline is about automated recurring reports that Hal builds. This is about salespeople creating bespoke reports themselves. Different users, different use case, different adoption challenge. - Status: seed. Even easier to test than the underwriting CLI because the infrastructure exists, but still untested with actual salespeople. - Flagged the confirmation bias risk explicitly. Hal now has four ideas running on the same thesis in a single day. That's energising but also a pattern to watch. The thesis might be right, but the excitement could lead him to skip validation. - Suggested a concrete next step that can happen this week - much faster than the underwriting CLI's four-week plan. Sales is the faster, cheaper test of the underlying thesis. - Connected to three existing ideas. The emerging cluster (underwriting CLI, sales CLI, report pipelines, voice calc) is becoming a coherent strategic vision. Worth noting but not yet worth its own idea file - it's a theme, not an actionable thing.