Deepline Deepdives

00:01:00 · Fireflies summary

The session opened with product maturity and readiness: fix the product before scaling enterprise deployments, especially when deploying engineers will rely on the workflow output.

00:05:52 · Fireflies summary

The warm outbound workflow de-anonymizes US website visitors, filters for ICP fit, enriches LinkedIn and email data, posts a Slack approval step, then pushes approved leads into Lemlist.

00:16:50 · Fireflies summary

Tenant URL technographics use known SaaS tenant URL formats, Bloomberg or cybersecurity seed data, and low-cost HTTP response checks to verify which companies actively use products like Salesforce or Zendesk.

00:20:30 · Fireflies summary

Warm intro scoring ranks mutual connections by relationship strength and context. The best path is often a medium-strength relationship that is relevant and credible, not the most obvious connection.

00:35:15 · Fireflies summary

LinkedIn event organizer scraping is constrained by login requirements, so the working pattern combines public extraction, Edges-style scraping, Apify actors, and fallback CSVs for pages that cannot be fetched reliably.

00:47:05 · Fireflies summary

CRM cleanup and niche workflow building improve when the agent starts from explicit good examples, iterates against the real outcome, and treats Deepline as headless GTM infrastructure rather than another UI-only agent.

00:00:04 · Jai Toor

So this is one that I put together and this is running queries on a database. You can think of it as what are the key concepts they need to know. Instead of querying the data model every time, you define synonyms -- when someone says company, account, deal, opportunity, you have those mapped. You can define concepts consistently, add custom metrics, and the GPT always gets that definition first.

00:01:50 · Jai Toor

The hard part is building this, right? Now I have to go define every single concept, which isn't sustainable. So what we found is you give GPT the Salesforce table and the reports you're trying to generate, and say recreate this. What that captures is the metrics behind the definitions. You have to manually spot check, but for the most part that gets you 95% of the way there.

00:03:35 · Willy Hernandez

Do you do this in one running markdown file or do you separate semantic from a field reference?

00:03:51 · Jai Toor

Very, very separate. The semantic layer should work independent of the system prompt. You should be able to do something deterministic and programmatic on top of it. It's not free text. You're telling the system prompt to use it in the first step, but from then on the semantic layer is independent.

00:07:06 · Jai Toor

A lot of people are coming from the Clay world where everything is very structured. This is a model we used for scoring: build a big list, get potential accounts, have a good idea of your total addressable market, then try to get signals and enrichment about them. What's changing is you start with a small list of known good fits, score the features, and then expand from there.

00:09:49 · Willy Hernandez

Could you define small, in terms of volume?

00:09:53 · Jai Toor

Probably 30 to 40 is the minimum I've seen be actually useful and differentiated. Good results start happening around a hundred. It scales with what you're doing -- a restaurant company with 2 million targets needs maybe 10,000 before you differentiate, but for most products, starting with a hundred and guiding enrichment from what you find works well.

00:13:16 · Jai Toor

The data showed that west coast restaurants were converting higher. That's because the reps were starting early on the East Coast. By the time they got going, it was the beginning of the day for west coast people. So you have this confirmation bias -- 'oh yeah, west coast people answer the phone more.' That's not the causal driver. The data shows us something nobody would have articulated, which means all the east coast people weren't getting called in the morning.

00:33:03 · Jai Toor

Push to Lemlist and then it adds them to a campaign that I also designed with cloud code. Going from zero to warm outbound campaign took a couple minutes. That includes email validation, everything you need. This runs natively in our system with access to all integrations -- custom HTTP connectors, data providers, sequences, CRMs, or your data warehouse.

00:39:45 · Willy Hernandez

I want to target sales leaders going to major events like SuiteWorld or Dreamforce. If they participate, they're trying to find customers there but probably don't have before-event enrichment. If I can listen through signals of people going to these events, pull a list, enrich them, and give context as to why I'm reaching out, that's a good way to make the agent continuously scour for those people.

00:41:05 · Jai Toor

That's a perfect use case. We have an open-source managed agents implementation. The Anthropic managed agents work almost at Cloud Code levels of flexibility. It comes with a Slack interface built in so you can query any of these tasks. The reply bot finds additional contacts for multi-threaded outreach -- an SDR says 'I'm working on Nucor, find me other people within the account based on our ICP.'

00:45:04 · Willy Hernandez

Next time we do office hours, I'd be really interested in diving into the reply bot thing.

00:47:12 · Jai Toor

There are two ways to do signals. When a third party sends you information, create a webhook -- when this URL is hit with data, do some action. The trigger is external. The other way is schedule: every day, check for changes. You can hack a schedule to be a trigger. The difference is cost. We have a partner where you describe what you want and pay per update received, not per check. Like a penny per social post per person.

00:49:00 · Matt Batterson

Do you do these often?

00:49:01 · Jai Toor

Yeah, weekly. Weekly feels like a lot so we might go biweekly. We have a Slack channel too -- Deepline CLI feedback on the website, cloud code plus GTM is right there.

00:00:00 · Jai Toor

The first thing to get right is what Deepline actually is. Claude Code is the interface. Deepline sits in the middle as one API. Claude asks for the outcome, Deepline figures out which of 30 to 40 data sources to use, and everything gets stored in a database so the workflow is auditable and reusable later.

00:02:43 · Jai Toor

That database layer matters more than people think. Three months later, someone can ask where a field came from, or take over the workflow, or build something new on top of the same account and contact records. In a vibe-coding world, owning the underlying SQL layer is what makes custom GTM tools possible.

00:07:35 · Jai Toor

For the org chart example, the model uses two kinds of information. First, what Claude already knows about how enterprise companies are usually structured. Second, the account-specific information the model would never know on its own, like titles, CRM notes, provider data, transcripts, and first-party context.

00:10:12 · Lindsey Peterson

Would you be interfacing with this in Claude, or in Deepline itself?

00:10:19 · Jai Toor

The interface is Claude. Deepline is in the backend. If you wanted LinkedIn data, fundraising data, phone verification, or ad-spend data, you would normally go find different vendors and figure out how to use each one. Deepline aggregates those sources so you do not need twenty separate accounts just to solve one workflow.

00:13:03 · Jai Toor

The tactical workflow is simple: start from the outcome you want, describe what the output should look like, and let Claude find the information it needs. In this case the outcome was an org chart and a buying-committee view, not a data pull for its own sake.

00:14:09 · Jai Toor

One technique that keeps improving results is using recent-source research before you lock the workflow. If I do not know what a strong AE org chart or GTM playbook should look like, I can research recent discussions on Reddit, X, YouTube, and Hacker News, then use that as a starting point and iterate from there.

00:16:55 · Jai Toor

That recent layer matters because the model's built-in knowledge will always lag what changed in the last month. The recent research is not there because your company is on Reddit. It is there because the best implementation details often live in the open, and those are the details that close the gap between a generic workflow and a useful one.

00:18:21 · Jai Toor

The next problem is signal discovery. Most teams say they know what makes a good customer, but in practice they confirm their own bias. The better approach is to compare won accounts against lost or bad-fit accounts and ask what is actually different between the two.

00:21:08 · Jai Toor

The reason to focus on niche signals is that your ideal customer is never identical to a competitor's ideal customer. Even if two companies sell into the same category, one might skew more enterprise, another more mid-market. Their scoring models should not be the same.

00:24:35 · Jai Toor

Historically, teams built that mental model by talking to customers, reading websites, looking at hiring pages, and guessing. The problem is that manual signal discovery does not scale, and it often just reinforces what the team already believes. A won-versus-lost comparison is much harder to fool.

00:30:56 · Jai Toor

Once the signal set is useful, the next step is to operationalize it. You can build a scoring workflow, push it into the CRM, or run it on a schedule. The value is not just finding the signal once. It is turning it into an ongoing system that stays tied to outcomes.

00:37:40 · Willy Hernandez

How does pricing and packaging work? Is it monthly, usage-based, or something else?

00:37:53 · Jai Toor

The managed credits are pay as you go. The longer-term business is the backend database and infrastructure, not trying to nickel-and-dime every workflow action. If someone just wants enrichment and lightweight workflows, credits are enough. If they want the durable system of record underneath, that is where the real value lives.

00:39:05 · Jai Toor

If a customer already has a better enterprise contract with a provider like Apollo, they can override with their own API key. The point is interoperability. Use Deepline where it helps. Bring your own provider where you already have an advantage.

00:40:10 · Sujith Ayyappan

I want to find LinkedIn posts and comments by pain point, not just keyword, then keep monitoring relevant comments over time.

00:40:20 · Jai Toor

The raw data part is straightforward. The hard part is that LinkedIn itself does not give you sentiment search or vector search. So the workflow is usually: pull the raw comments or posts first, accept that retrieval cost, then have Claude group or filter the data by sentiment and relevance.

00:44:39 · Jai Toor

That logic applies more broadly too. Deepline is not trying to be the reasoning layer for every problem. It gets you the underlying data reliably. Claude Code does the interpretation, scoring, grouping, or orchestration on top of that data.

00:47:17 · Jai Toor

We also have a Clay-to-Claude Code migration skill. You copy the configuration of a Clay table into the skill, and it turns that into a workflow. The critical feedback for us is not whether it migrates a toy example. It is whether it preserves the real logic people depend on, or whether some workflow still forces them back to another tool.

00:50:54 · Jai Toor

If a Clay setup depends on a provider Deepline does not support directly, the migration flow tries to find the closest substitute. If there is no substitute, it should flag that instead of pretending the workflow is complete. That fallback logic is what makes migration credible.

00:51:46 · Shiva Kumar

So if I wanted to monitor a hundred accounts and track people by sentiment, is that a Deepline workflow or something Claude is orchestrating around Deepline?

00:52:02 · Jai Toor

That is the right way to think about it. If there were one API that gave you every data source you needed, that is Deepline. Claude Code orchestrates around it. Deepline stores the data, exposes the endpoints, and can run the workflow on a recurring basis, but the workflow itself is designed from the outcome backward in Claude.

00:54:42 · Jai Toor

That distinction matters because it keeps the stack clean. Deepline should be the infrastructure and data layer. Claude should be the interface and the reasoning layer. Once you see it that way, a lot of GTM workflows become simpler to design.