Research workflows

Use this page when you know the GTM question, but you need a better workflow shape than a generic company brief.

Pick the workflow

Workflow	Use when	Output
Competitive ads research	You need to understand how competitors position themselves across paid channels.	Competitor, platform, creative theme, offer, proof, suggested counter-message.
Public + private data chain	You need a source-backed reason to contact an account before writing outbound.	Account reason, buyer route, first-party filter, evidence URL, suggested action.
Event attendees to CRM	You have a Luma, Eventbrite, webinar, or conference export that needs enrichment and routing.	Enriched attendee list, fit tier, work email status, CRM import fields.
Warehouse-to-campaign research	You have product or warehouse data and need a safe GTM action.	Segment definition, reason payload, guardrail result, draft campaign action.
Warm outbound from visitor signals	You have de-anonymized visitor or intent data and need human-approved outreach.	Qualified lead, page signal, messaging bucket, email status, review state.
Account mapping as code	You need repeatable targeting logic instead of spreadsheet-only research.	Targeting rules, exclusions, score rationale, next contacts to enrich.

Highest-value candidates from existing content

These are the best recipe candidates to build out as separate pages next.

Candidate	Why it is worth a full recipe	Source
Competitive ads workflow	It has a clear buyer, clear inputs, and a strong output: what competitors are saying in market right now.	Ad Intelligence Research
Public + private data workflow	It explains Deepline’s strongest point of view: public records create the account reason, private enrichment resolves the buyer, and first-party data decides the action.	Permissionless value props
Event attendees to CRM	It is concrete, common, and easy to verify: messy attendee exports become enriched CRM records.	Event attendees to CRM
Snowflake to CRM to campaign	It shows why agents need guardrails, approvals, and verification, not just tool access.	Snowflake CRM campaign workflow
Warm outbound from website visitors	It turns intent data into an approved sales action and makes the review step explicit.	Warm outbound from Warmly
Product usage to GTM	It is the best frame for warehouse-native PLG motions: define the signal, backtest it, guardrail it, then write back.	Product usage to GTM playbook
Account mapping as code	It matches how technical GTM teams work: keep targeting rules, scoring logic, exclusions, and outputs in reviewable files.	Pipeline as code for GTM account mapping

Recipe 1: Competitive ads research

Use this when the question is: “What are our competitors saying in paid channels, and how should we respond?” Inputs:

Competitor domains or brand names
Channels to inspect, such as Google, LinkedIn, Facebook, or TikTok
The market or persona you care about

Output columns:

competitor
platform
ad_theme
offer
claim
proof_url
counter_message
recommended_action

Agent prompt:

Use competitors.csv and build a competitive ads research workflow.

For each competitor:
1. Pull active ad examples across the paid channels Deepline supports.
2. Group the ads by message, offer, audience, and product theme.
3. Preserve the source URL or evidence field for every claim.
4. Write a counter-message our sales or paid team could test.

Run a small sample first. Write the result to competitor-ads-research.csv.
Return:
- the action chain used
- which competitors had thin or missing ad evidence
- the safest way to scale the workflow to the rest of the list

Start from Competitive and ad intelligence. Use the organic-positioning variant when you need website, comparison-page, or public-post context alongside paid ads.

Recipe 2: Public + private data chain

Use this when the question is: “What source-backed reason do we have to contact this account?” This is the better version of generic account research. Do not start with the person. Start with the source of truth for the market, then resolve the buyer. Inputs:

Account list, market, or territory
Public source to inspect: permit, registry, filing, job post, inspection, ad, event, or website signal
First-party context: CRM stage, owner, product usage, customer status, suppression list, or territory

Output columns:

account
public_signal
source_url
buyer_to_resolve
first_party_filter
why_now
suggested_action
review_note

Agent prompt:

Use accounts.csv and build a public + private data chain.

For each account:
1. Find the public record or web evidence that explains the account reason.
2. Resolve the buyer only after the account reason exists.
3. Apply our first-party context before suggesting any action.
4. Preserve source URLs and evidence fields in the output.
5. Do not write outreach copy until the evidence and buyer route are clear.

Write the result to pvp-account-research.csv.
Return:
- rows that are ready for review
- rows that need more evidence
- rows that should be suppressed or skipped

Use Lead scoring and signal discovery for fit scoring and source-backed signal detection. The source strategy comes from Permissionless value props.

Recipe 3: Event attendees to CRM

Use this when the question is: “Which event attendees should sales follow up with, and what should go into CRM?” Inputs:

Attendee export with name, email, company, or event metadata
Qualification rule
CRM destination and duplicate rule

Output columns:

name
company
domain
work_email_status
fit_tier
reason_to_follow_up
crm_action
dedupe_result

Agent prompt:

Use attendees.csv from our event export.

For each attendee:
1. Normalize names, email domains, and company fields.
2. Enrich missing company and work email fields.
3. Score fit against this rule: [paste our ICP or event follow-up rule].
4. Mark duplicates before any CRM write.
5. Produce a CRM-ready import file and a review file.

Write qualified rows to event-followup-qualified.csv.
Write skipped rows to event-followup-skipped.csv.
Return the fields that still need human review before CRM import.

See the source walkthrough: Event attendees to CRM.

Recipe 4: Warehouse-to-campaign research

Use this when the question is: “Which product or warehouse signal should change the next GTM action?” Inputs:

Product or warehouse table
CRM object to update
Campaign or rep action to draft
Guardrails for suppression, ownership, and approval

Output columns:

account_or_user
signal_definition
why_now
guardrail_result
draft_action
writeback_target
verification_step

Agent prompt:

Use the available product and CRM context to design a warehouse-to-campaign workflow.

Before writing any campaign action:
1. Define what the product signal means in business language.
2. Identify the account or user object it maps to.
3. Apply owner, suppression, customer-status, and duplicate guardrails.
4. Draft the CRM or campaign update only after the guardrails pass.
5. Include a verification step that proves the data landed correctly.

Return the workflow plan, sample output fields, and the first safe dry run.

Use Database access when the workflow needs private tables. The examples to expand are Snowflake CRM campaign workflow and Product usage to GTM playbook.

Recipe 5: Warm outbound from visitor signals

Use this when the question is: “Which website visitors are worth a human-approved outreach step?” Inputs:

Visitor or intent event
Page history or topic signal
ICP rule
Email enrichment and review destination

Output columns:

person
company
page_signal
messaging_bucket
fit_result
email_status
draft_icebreaker
review_state

Agent prompt:

Use visitor_signals.csv and build a warm outbound review workflow.

For each visitor:
1. Deduplicate before enrichment.
2. Map page history to a messaging bucket.
3. Apply deterministic ICP rules before any expensive enrichment.
4. Find a verified work email only for rows that pass the fit gate.
5. Draft an icebreaker that references the page signal.
6. Route the draft for human review. Do not auto-send.

Write review-ready rows to warm-outbound-review.csv.
Return skipped rows with the exact blocked reason.

Follow the complete Warm outbound from Warmly guide for the build prompt, webhook setup, field mapping, logs, and screenshots.

What every research workflow must preserve

The input row that triggered the research.
The source URL, record ID, or evidence field behind each claim.
The reason a row passed, failed, or needs review.
The next system action, such as CRM import, Slack review, campaign draft, or no action.
The dry-run result before any writeback or send.

Treat research as evidence collection plus routing. If a workflow only produces prose, it is probably not ready for production use.

Getting Started

GTM is code

Features

Deepline SDK beta

Integrations

API Reference

Research workflows

Pick the workflow

Highest-value candidates from existing content

Recipe 1: Competitive ads research

Recipe 2: Public + private data chain

Recipe 3: Event attendees to CRM

Recipe 4: Warehouse-to-campaign research

Recipe 5: Warm outbound from visitor signals

What every research workflow must preserve

​Pick the workflow

​Highest-value candidates from existing content

​Recipe 1: Competitive ads research

​Recipe 2: Public + private data chain

​Recipe 3: Event attendees to CRM

​Recipe 4: Warehouse-to-campaign research

​Recipe 5: Warm outbound from visitor signals

​What every research workflow must preserve

Pick the workflow

Highest-value candidates from existing content

Recipe 1: Competitive ads research

Recipe 2: Public + private data chain

Recipe 3: Event attendees to CRM

Recipe 4: Warehouse-to-campaign research

Recipe 5: Warm outbound from visitor signals

What every research workflow must preserve