--- lang: en template: deployment-detail --- # Lead sourcing to a **verified CRM campaign** > Impact The Lead Sourcing deployment guides a search signal through to a verified CRM campaign: Jadey defines target scope, search logic and selection boundaries, checks brands, companies, contact situation and CRM readiness, and creates from that a traceably verified campaign inventory. The run remains connected across signal, review, correction, CRM write and final verification. ### ~0.12 EUR {#cost-per-crm-ready-lead} Cost per CRM-ready lead ### ~260 min {#time-to-campaign} Time to campaign ### 99.99 % {#crm-first-time-right} CRM First-Time-Right ## Unguided lead sourcing {#challenge} > Challenge New leads are needed, but the path from first hit to usable CRM record is rarely guided cleanly. Manual Excel lists, fragmented research paths, inconsistent evaluation criteria and records that later require CRM cleanup often emerge. The operational effort is not in the individual click. It lies in the sum of many small review decisions: Is the hit relevant? Does the brand belong to this company? Is there already a CRM record? Is the record duplicated? Are website, contact situation and company relationship reliable? May a lead be created from it? And is this lead complete enough to move directly into a campaign? This work is difficult for enterprises to organize cleanly on a sustained basis. It sits between sales, marketing operations, research, CRM maintenance and data quality. Nobody truly owns the full run end to end. The result is media breaks, inconsistent standards, duplicates, incorrect assignments and campaign inventories that sales does not fully trust. The outcome: lead sourcing is done, but it is not really guided. Enterprises gain data, but lose quality. They create leads that must be cleaned up later. They start campaigns on unreliable foundations. And they bind qualified employees to manual review and correction work instead of conversations, closing opportunities or strategic market work. ## Outcome-led campaign run {#solution} > Solution Jadey turns lead sourcing into a guided enterprise process. A recognized lead need becomes a clear campaign run with target segment, target size, selection criteria, exclusions and quality requirements. The enterprise therefore defines not only that new leads are needed, but which leads are actually relevant, usable and commercially connectable for the campaign. From that point, Jadey guides the process throughout. Relevant companies are identified, checked, evaluated and prepared for the campaign. Every potential lead receives a business rating and is prequalified; only highly rated leads enter the campaign inventory. Existing CRM data is considered, duplicate entries are avoided and unclear cases are visibly routed out. Research, qualification, data review and campaign build are therefore no longer distributed between sales, marketing, research and CRM maintenance, but guided in one coherent process. A major difference lies in quality assurance during the run. Incomplete, contradictory, non-uniquely assignable or insufficiently rated records are not silently taken into the campaign. They are corrected, checked again or deliberately blocked until company relationship, data quality, contact situation, rating and CRM readiness are reliably clarified. This avoids a downstream cleanup problem and creates controlled construction of usable campaign data. The result is a verified CRM campaign inventory. Leads, brands, companies, assignments and required data are prepared so that sales can continue on a clean foundation. The run counts as complete only when the campaign is complete, unambiguous and usable in CRM. A lead counts as CRM-ready only when campaign, lead and brand records, campaign binding, brand-lead relation and required fields have been written in CRM and confirmed by readback. CRM First-Time-Right therefore does not describe later sales impact, but successful CRM completion against target state, field findings, relation evidence and parent CRM audit. | KPI | Before Jadey | After Jadey | Meaning | |---|---:|---:|---| | Time per lead sourcing | - | roughly 5 min | A single sourcing case is guided in the standard run through to business prequalification. | | Cost per CRM-ready lead | - | approx. 0.12 EUR | In the configured run, an additional CRM-ready lead is created without newly built manual research and cleanup effort. | | CRM precheck | - | 100 % | Before every lead creation, Jadey checks the existing CRM inventory for existing records, duplicates and exclusions. | | CRM First-Time-Right | - | 99.99 % | Campaign, brands, leads and required fields count as complete only when CRM readback confirms the created inventory. | A full campaign contains 50 potential leads. From a new need, the configured standard run creates a CRM campaign in roughly 260 minutes instead of an intermediate list maintained manually. The reported metrics refer to this configured standard run. Counted are additional CRM-ready leads that emerge without newly built manual research and cleanup effort. Special cases, incomplete data situations and required approvals are checked and controlled separately instead of diluting the quality of the entire campaign. The new capability therefore does not lie in faster search. It lies in Jadey guiding the full operational context: from recognized lead need through selection, review, correction and CRM readiness to the verified campaign inventory. Lead sourcing becomes a repeatable, controllable and evidenced enterprise run instead of a manual research task. ## From signal to CRM evidence {#technical-depth} > Technical depth The technical architecture of the deployment separates daily start, intake, business case guidance, individual playbook steps, rating, CRM subtask, readback and final audit. Jadey therefore does not run lead sourcing as uncontrolled end-to-end automation, but as a bounded, auditable and documented operating process. The deployment deliberately ends at CRM campaign completion. A run is complete only when campaign, leads, brands, relations, CRM readback and parent CRM audit are documented. A later outreach or sales-meeting run is not part of this deployment. ### Agents and roles in the deployment Four agent areas participate in the lead-sourcing run. `cron` starts the daily run technically and hands the run to `opportunity`. `opportunity` takes over business case guidance: `triage` clarifies the need and creates the campaign case, `ops-parent` keeps the run together and commissions `ops-child` for individual review and playbook steps. For business prequalification, `rating` is also involved. `rating` evaluates potential leads, returns a score and ensures that only highly rated leads continue toward the campaign inventory. `crm` takes over CRM subtasks when existing CRM data must be checked, campaign, leads and brands must be written or CRM inventory must be read back. External register and research sources complement the run as data sources. Research source, DPMA, EUIPO, website and Northdata return review signals to the opportunity case, but are not independent target-state agents. The run therefore remains clearly guided: `cron` orchestrates the start, `opportunity/ops-parent` carries outcome responsibility per campaign case, `rating` adds business evaluation and `crm/sales` delivers CRM precheck, write, readback and audit input. #### `cron/runner` Function: Technical daily run Activity: Starts the lead-sourcing run and documents the technical return. `cron/runner` is responsible for the technical daily run. The agent detects that the sourcing run is due, starts the intake waiting at `opportunity/triage` and documents start, return, error, timeout and runner report. The start of the deployment therefore remains separate from the business decision: `cron/runner` provides execution and evidence, while `opportunity` guides the need and campaign case. **Boundary:** `cron/runner` makes no demand decision, evaluates no leads and must not write into CRM. The agent controls the daily run, but not the lead-sourcing process itself. #### `opportunity/triage` Function: Signal clarification and run creation Activity: Turns the lead-sourcing signal into a controlled campaign run. `opportunity/triage` checks whether a new sourcing need exists. The agent classifies target segment, target size, marketplace, category, exclusions and seeds and creates the intake for the campaign run from this. When needed, `opportunity/triage` creates a GitHub issue with the required mandatory fields or updates an existing issue. If there is no need, the run ends without a campaign case. **Boundary:** `opportunity/triage` makes no CRM completion decision and must not write directly into CRM. Missing mandatory values are not silently added, but must be clarified at intake. #### `opportunity/ops-parent` Function: Case guidance for the campaign run Activity: Keeps review, correction, gate and completion together. `opportunity/ops-parent` is the leading business agent for each campaign run. The parent selects the open issue, keeps run state together and commissions individual `opportunity/ops-child` playbooks. The returns from child steps are evaluated by `opportunity/ops-parent`. The parent decides whether the run continues, repeats, jumps back, is repaired or is visibly blocked. Before completion, it performs the parent CRM audit against the target state and documents campaign ID, campaign name, CRM readback and audit finding. The run does not close successfully if mandatory values are missing, child returns are incomplete, source gaps exist, CRM duplicates remain ambiguous, required fields cannot be written or the parent CRM audit shows hard Tier-S/A gaps. **Boundary:** `opportunity/ops-parent` does not write directly into CRM and does not replace any partial review. The parent guides the case, but remains dependent on robust child, rating and CRM returns. The operational boundary is therefore clear at case guidance: `opportunity/ops-parent` decides on progress, repetition, repair, jump-back or blocking, but performs no CRM writes, no direct mass query and no business re-evaluation outside the documented returns. CRM write, CRM read and audit input remain with `crm/sales`; research, rating and source findings must be returned into the run as bounded returns. #### `opportunity/ops-child` Function: Bounded partial review Activity: Checks one specific subarea and returns the finding. `opportunity/ops-child` takes exactly one playbook step at a time. This includes CRM precheck, sourcing shortlist, CRM dedupe, register review, website and contact review, portfolio and company data, rating preparation as well as CRM campaign and upsert. The child returns a playbook result, findings and updated run state to `opportunity/ops-parent`. Individual checks therefore remain bounded while the parent retains overall guidance. **Boundary:** `opportunity/ops-child` does not take over the parent assignment. It makes no overall decision and must not complete the campaign run without the parent gate. #### `rating` Function: Business lead evaluation Activity: Evaluates every potential lead and returns a score. `rating` evaluates potential leads against approved evaluation criteria, publicly traceable market signals and the respective campaign context. The agent classifies the case and returns a score to the campaign run. The rating does not decide CRM completion by itself, but it is a central gate for prequalification. Only highly rated leads are carried forward for the CRM campaign inventory. **Boundary:** `rating` creates no campaign, writes nothing into CRM and does not replace CRM recheck. Customer-specific details are not disclosed. #### `crm/sales` Function: CRM inventory, CRM write and CRM recheck Activity: Checks existing records, writes campaign, brands and leads, and reads the result back. `crm/sales` is the CRM service of the deployment. The agent checks existing CRM data, detects duplicates, ensures the campaign, creates or updates leads and brands, binds them to the campaign and creates the brand-lead relation. After writing, `crm/sales` reads the CRM inventory back and delivers structured IDs, totals, field findings, errors and audit input to `opportunity/ops-parent`. This lets the parent check CRM completion against the target state. **Boundary:** `crm/sales` does not re-evaluate the opportunity from a business perspective and does not replace sourcing or rating decisions. CRM write happens only as a subtask inside the guided run; ambiguous duplicates, missing required fields or readback gaps return to the parent as findings. ### Service hierarchy ```mermaid flowchart TB cron_runner[cron/runner] triage[opportunity/triage] parent[opportunity/ops-parent] child[opportunity/ops-child] rating[rating] crm_sales[crm/sales] github[(GitHub)] crm[(Dynamics Dataverse CRM)] research[(Research source)] dpma[(DPMA)] euipo[(EUIPO)] website[(Website)] northdata[(Northdata)] cron_runner --> triage triage --> parent triage --> github parent --> child child --> rating child --> crm_sales crm_sales --> crm parent --> github child --> research child --> dpma child --> euipo child --> website child --> northdata ``` ### Systems in the deployment Only the systems and data sources required for intake, review, CRM write and final evidence are used in the deployment. GitHub documents intake, run reference and closing note. Research source, DPMA, EUIPO, website and Northdata provide review signals for brand, company, contact situation and campaign readiness. CRM is the leading completion location for campaigns, brands, leads and relations. #### `GitHub` Use: Intake queue and evidence location Description: Contains the sourcing intake with mandatory fields, run reference, returns, blockers and closing note. #### `Research source` Use: Source material for potential leads Description: Includes platforms and publicly available internet sources from which potential leads are drawn for further review. #### `DPMA` Use: Trademark register review in Germany Description: Supports clarification of brand, owner and reliable brand identity in the German register context. #### `EUIPO` Use: Trademark register review in the EU Description: Supports clarification of brand, owner and reliable brand identity in the European register context. #### `Website` Use: Contact situation and company assignment Description: Provides signals on website, contact possibility, company and further brands within the same responsibility area. #### `Northdata` Use: Company environment Description: Supports classification of legal entity, company environment, size and revenue signals. #### `CRM` Use: Inventory search, dedupe, campaign creation, lead/brand upsert, relations and readback Description: Dynamics Dataverse is the leading system for campaign, lead, brand, brand-lead relation, required fields and verified closing state. ### Artefacts in the deployment The artefacts form the evidence chain from search signal to verified CRM campaign. The website shows the most relevant artefacts. In the actual run, every agent role additionally creates its own handover to the next role, so that state changes, findings and blockers remain traceable. For enterprise environments, this artefact chain is central. It makes visible which need was reviewed, which criteria applied, which leads continued or were blocked, whether the CRM result is reliable and which exceptions remain open. #### `Run Summary` Owner: opportunity/ops-parent Produced by: cron/runner + opportunity/ops-parent Meaning: Operating evidence for start, monitoring and terminal run status. Relevance: Proves that the run was started, monitored and completed or blocked in a controlled way. Important for operational governance. #### `Intake & Scope Summary` Owner: opportunity/triage Produced by: opportunity/triage Meaning: Business starting point of the campaign run with need, scope and rules. Relevance: Evidences why sourcing need existed and which criteria applied: target segment, category, seeds and exclusions. Important against implicit defaults. #### `Qualification Decision Summary` Owner: opportunity/ops-parent Produced by: opportunity/ops-parent, supplied by opportunity/ops-child Meaning: Business decision evidence for continuation, exclusion, repair or blocker. Relevance: Shows which checks were passed and why leads or brands continue or drop out. Important for business traceability. #### `CRM Result & Readback Summary` Owner: crm/sales Produced by: crm/sales, evaluated by opportunity/ops-parent Meaning: Evidence of the created or updated CRM inventory and its readback. Relevance: Proves the business outcome: campaign, leads, brands, bindings, relations and readback. Important because CRM write alone is not enough. #### `Governance Exception Summary` Owner: opportunity/ops-parent Produced by: opportunity/ops-parent, supplied by crm/sales and opportunity/ops-child Meaning: Exception and risk evidence for incomplete or unreliable subcases. Relevance: Shows open Tier-S, Tier-A, Tier-B or Tier-C gaps, ambiguities, blocked cases and missing contracts. Important for audit, risk and escalation. ### From search signal to verified CRM campaign The lead-sourcing run connects daily start, intake, issue queue, parent case guidance, child playbooks, CRM precheck, dedupe, research and register review, business rating, CRM campaign, readback and parent audit into one guided operating process. The standard path ends in a verified CRM campaign. Side paths apply when no need exists, mandatory values are missing, child returns are incomplete, a lead is rated too weak, CRM duplicates are ambiguous or readback shows gaps. ```mermaid flowchart TB subgraph cron_lane["cron/runner
Daily run"] c1[Start daily sourcing run] c2[Start opportunity/triage
waiting] c3[Wait for triage return] c4[Write run logs and
runner report] c1 --> c2 --> c3 --> c4 end subgraph triage_lane["opportunity/triage
Intake"] t1[Check sourcing need] t2{Need
present?} t_no[Return no need] t_yes[Materialize
business defaults] t_issue[GitHub issue
with mandatory fields] t1 --> t2 t2 -->|no| t_no t2 -->|yes| t_yes --> t_issue end subgraph parent_lane["opportunity/ops-parent
Campaign run"] p1[Start parent run
from issue] p2[Provide
canonical_run_state] p3[Commission ops-child
playbooks] p4[Collect and evaluate
returns] p5{Parent gate} p6[Parent CRM audit] p7[Handoff
campaign_id + name] p_block[Document
hard block] p1 --> p2 --> p3 --> p4 --> p5 p5 -->|advance| p6 --> p7 p5 -. retry/repair .-> p3 p5 -->|hard block| p_block end subgraph child_lane["opportunity/ops-child
Playbook steps"] ch1[CRM precheck
and dedupe] ch2[Check sourcing, register
and website] ch3[Check portfolio and
company data] ch4[Prepare
opportunity analysis] ch5[Prepare CRM campaign
and upsert] ch1 --> ch2 --> ch3 --> ch4 --> ch5 end subgraph rating_lane["rating
Company evaluation"] r1[Business lead evaluation] r2[Scoring and
rating finding] r1 --> r2 end subgraph crm_lane["crm/sales
CRM service"] crm1[Check Dynamics CRM
inventory] crm2[Write campaign, lead
and brand] crm3[Readback and
audit input] crm1 --> crm2 --> crm3 end triage_parent_gap[ ] c2 --> t1 t_no --> c3 t_issue --> c3 t_issue --> p1 p3 --> ch1 ch1 -. CRM check .-> crm1 crm1 --> ch2 ch4 --> r1 r2 --> ch5 ch5 --> crm2 crm2 --> crm3 crm3 --> p4 p7 --> c3 %% Layout help: keeps distance between intake and parent lane. t_issue ~~~ triage_parent_gap triage_parent_gap ~~~ p1 style triage_parent_gap fill:transparent,stroke:transparent,color:transparent %% Layout help: keeps rating and CRM service readable as separate lanes. ch4 ~~~ r1 ch5 ~~~ crm2 ``` ## This deployment can become a blueprint for your enterprise {#lead-sourcing-deployen} > Implementation The Lead Sourcing deployment shows how Jadey guides an information-intensive sales process in operational use: from search signal through brand, company and CRM review to a verifiably checked campaign inventory. What was implemented here for lead sourcing can be transferred to comparable campaign, research and CRM processes in your enterprise - with your existing system landscape, your approval paths and the rules that govern your operations. In a first conversation, we assess whether this deployment is suitable as a starting point for your enterprise and where Jadey can create near-term operational impact. [Get Started](action:demo-booking)