# LeadGrid, full blog archive (all locales)

LeadGrid is the programmable pipeline platform that unifies sales and recruitment in one system. One API, two pipelines. Free forever on the free plan.

Canonical site: https://leadgrid.io
---

## EN posts

# Lead scoring without ML: why a five-rule scorecard wins for most teams

URL: https://leadgrid.io/blog/lead-scoring-without-ml
Locale: en
Published: 2026-05-13
Author: Ralf Klein
Tags: sales, guides

Most teams that adopt machine learning lead scoring would get 80% of the value from a five-rule scorecard. When to upgrade, and when not to.

Every quarter another sales team tells me they need AI lead scoring. We dig in, and what they actually need is a clean five-rule scorecard with negative weights and a decay function. The ML model is the headline, but the lift is in the basics that almost nobody bothered to set up first.

This is not a contrarian take. It is the same advice you will find buried at the bottom of every honest ML guide. The problem is that the rules-based version sounds boring, so teams skip it and pay for a model that learns the wrong thing from dirty data.

## The math problem most teams have first

A predictive model needs enough closed-won and closed-lost examples to learn from. Most B2B teams do not have that volume yet. According to the [Prospeo guide on AI versus traditional lead scoring](https://prospeo.io/s/ai-lead-scoring-vs-traditional-lead-scoring), the practical floor is roughly 1,000 leads per year, 100 closed deals, and 12 to 24 months of clean CRM data before an ML model produces a defensible score. Below that, a well-built rule-based model will out-predict a poorly trained AI model every single time.

That is the part the vendor decks leave out. A model trained on 60 conversions and a year of inconsistent stage definitions does not learn your buyer, it learns your data hygiene problem.

## Why the rules version usually wins

Forrester has been blunt about this for years. The [Forrester piece on what lead scoring actually is](https://www.forrester.com/blogs/what-is-lead-scoring-anyway/) calls out that most production scoring models are built on guesses and random estimates of propensity to buy, not on any real analysis. Swapping that for an ML model trained on the same shaky inputs does not fix the inputs, it just makes the score harder to argue with.

A simple scorecard is auditable, fast to change, and forces the sales and marketing teams to agree on what "qualified" means before they ship it. That alignment is where most of the real lift comes from. The [Clueless Company breakdown of failing lead scoring models](https://www.theclueless.company/lead-scoring-techniques/) puts it well: the most common reason scoring projects fail is not bad logic, it is that sales does not trust the score, so reps keep working whoever they were working before.

You cannot build trust in a black box. You can build trust in five rules you can read off a whiteboard.

## The five-rule scorecard

Here is the version we recommend for any LeadGrid customer below the ML threshold. It fits in one screen and explains itself.

```yaml
fit_score:
  icp_company_size:    { match: +20, miss: -15 }
  icp_industry:        { match: +15, miss: -10 }
  decision_maker_role: { match: +20, miss: -10 }

intent_score:
  pricing_page_visit:  +20
  demo_request:        +30
  three_emails_opened: +5
  inactivity_per_week: -5

threshold_for_sales_handoff: 50
```

Five rules, two negative weights, one decay rule. That is it. The structure is borrowed from the [Reform guide on common lead scoring mistakes](https://www.reform.app/blog/common-lead-scoring-mistakes-and-fixes), which is direct about the two failure modes a basic scorecard has to fix: tracking too many signals creates noise, and only assigning positive scores floods the CRM with cold leads that nobody removes.

The decay rule matters more than people realise. The [Breadcrumbs B2B lead scoring framework for 2026](https://breadcrumbs.io/blog/b2b-lead-scoring/) recommends subtracting points for each week of inactivity, exactly so zombie MQLs do not sit at the top of the queue while a hotter lead from this morning sits below them. Without decay, your scorecard is a high score table, not a queue.

## When to graduate to ML

There is a real threshold where ML scoring earns its complexity. You have crossed it when three things are true at once.

You have at least 100 clean closed-won and 100 clean closed-lost records, with consistent stage definitions across that history. The [Landbase lead scoring statistics roundup](https://www.landbase.com/blog/lead-scoring-statistics) cites Forrester data showing 38% higher conversion and 28% shorter sales cycles for teams running AI scoring, but those numbers come from teams that had the data hygiene to train on. Without that hygiene, the model is learning your bad CRM, not your buyer.

Your sales cycle is complex enough that humans cannot hold the variables in their head. Multi-stakeholder enterprise deals with 18 plus touchpoints across six months are a different problem than a self-serve SaaS funnel with a free trial gate. ML earns its keep on the complex shape, not on the simple one.

You have already shipped the rules-based version and you can name exactly which rule the ML model is going to beat. If you cannot name it, the ML model is not solving a problem you have, it is solving one a vendor has.

## The honest hybrid

The pattern that works is rules-based scoring as the base layer, ML as an overlay on top once you have the data to justify it. The rules give you a score reps trust on day one. The ML overlay, once you ship it, adjusts the score using patterns the rules cannot see, but the human-readable score stays in the UI.

This is also what the [SiriusDecisions data on lead scoring adoption](https://salesdorado.com/en/sales-qualification/lead-scoring-useless/) was pointing at when it found that 68% of companies were running lead scoring but only 40% of salespeople saw any value in it. The teams in the 40% had a model the reps could explain. The teams in the other 60% had a model the reps did not believe.

Build the five-rule version first. Earn the ML upgrade once your data and your sales team are ready for it. Most teams never need to take that second step, and that is fine.

[Start free →](https://leadgrid.io/signup)

---

# Webhook reliability for pipeline events: idempotency or it didn't happen

URL: https://leadgrid.io/blog/webhook-idempotency-pipeline-events
Locale: en
Published: 2026-05-06
Author: Ralf Klein
Tags: api, engineering

Webhooks deliver at least once, not exactly once. If your pipeline handler is not idempotent, retries silently corrupt state. The patterns LeadGrid uses, with code.

Every webhook provider on the planet ships at-least-once delivery. Stripe, GitHub, Shopify, LeadGrid. That is not a defect, it is the only honest semantic over an unreliable network. Which means your handler will receive the same event twice, and sometimes ten times, and if it is not idempotent the state of your pipeline silently rots.

This is the failure mode I see most in LeadGrid integrations: a single network blip retries a `stage.changed` event, the customer's handler re-runs the side effect, and now the same candidate has two interview invites or the same lead got two welcome emails. Nothing logged it as a bug. The retry was the bug.

## At-least-once is not a bug, it is a contract

When a webhook sender does not get a 2xx within its timeout, it has two choices: assume the receiver got it, or assume it did not. Assuming success drops events on the floor whenever the network flakes. Every mature platform picks the other one. The [Hookdeck guide on implementing webhook idempotency](https://hookdeck.com/webhooks/guides/implement-webhook-idempotency) is blunt about it: most providers operate on at-least-once delivery, and the burden of dedup sits with the consumer.

Stripe documents the same expectation. In the [Stripe webhooks reference](https://docs.stripe.com/webhooks), the recommendation is to treat the `event.id` as the primary key for deduplication on your end, because Stripe will retry on any non-2xx and on most timeouts.

LeadGrid follows the same model for `pipeline.*` events. If we time out waiting for your endpoint, we retry with the same `event.id` and the same payload. If your handler runs the side effect twice, that is on the handler.

## Two layers of idempotency, not one

Most teams only build the first layer, and then are surprised when state still drifts.

The **ingress layer** dedupes the inbound event itself. You take the `event.id`, write it to a table with a `UNIQUE` constraint, and short-circuit if it is already there. This stops duplicate work on retries. The [Hookdeck post on webhook scale](https://hookdeck.com/blog/webhooks-at-scale) recommends exactly this, and it is also the pattern Shopify documents in their [webhooks best practices](https://shopify.dev/docs/apps/build/webhooks/best-practices) using the `X-Shopify-Webhook-Id` header.

The **side-effect layer** dedupes the outbound write that the event triggers. If the webhook handler calls a third-party API to send an email, create a Stripe charge, or post to Slack, that downstream call also needs an idempotency key. Otherwise a partial failure between "we wrote the event_id row" and "we sent the email" leaves you in a state where the next retry sees the event_id as already processed and skips, but the email never went out. Or worse, it went out twice.

[Stripe's idempotent requests docs](https://docs.stripe.com/api/idempotent_requests) describe this well: keys live up to 24 hours, are scoped per endpoint, and should be V4 UUIDs generated client-side, never server-side, because a regenerated key on retry would defeat the whole mechanism.

## What the LeadGrid pattern actually looks like

For pipeline events we ship, here is the receiver shape we recommend, and the one our internal services use:

```ts
async function handleLeadGridWebhook(req: Request) {
  const event = verifySignature(req); // throws on bad signature

  // Layer 1: ingress dedup
  const inserted = await db.query(
    `INSERT INTO webhook_events (event_id, received_at)
     VALUES ($1, NOW())
     ON CONFLICT (event_id) DO NOTHING
     RETURNING event_id`,
    [event.id]
  );

  if (inserted.rowCount === 0) {
    // already processed, ack and move on
    return new Response("ok", { status: 200 });
  }

  // Layer 2: enqueue, do not process inline
  await queue.enqueue("pipeline-events", {
    event_id: event.id,
    type: event.type,
    payload: event.data,
  });

  return new Response("ok", { status: 200 });
}
```

Three things are deliberate. The signature verify happens before the dedup write, so a forged event with a real ID cannot poison the table. The dedup uses `INSERT ... ON CONFLICT` so the check and the write are atomic, no race. And the actual work is enqueued, not done inline, because synchronous webhook processing is how you turn a 200ms blip into a multi-hour outage.

The Hookdeck team makes this case directly in their [webhook scale post](https://hookdeck.com/blog/webhooks-at-scale): treat your endpoint as `verify → enqueue → ack`, and let a worker process from the queue with its own retry and backoff logic.

## Backoff, jitter, dead-letter queue

The other half of the contract is what your worker does on failure. Three rules that survive contact with production.

Use **exponential backoff with jitter**, not fixed retries. A retry storm of identical-interval retries from a thousand workers will hammer a recovering service back into the ground. The same Hookdeck guide notes that 1s, 2s, 4s, 8s with random jitter is the floor of acceptable.

Cap the retry count and route the rest to a **dead-letter queue**. The [Hookdeck DLQ guide](https://hookdeck.com/webhooks/guides/dead-letter-queues-webhook-reliability) is the right reference here: a poison event that fails forever should not block the rest of the queue. Move it to a DLQ after N attempts, alert, and let an operator decide.

Make the worker itself **idempotent on the side effect**, not just on the dedup row. If it fails after sending the email but before marking the event_id as processed, the next retry should generate the same idempotency key and have the upstream API return the cached response. This is what the [Stripe idempotency model](https://docs.stripe.com/api/idempotent_requests) gets right: same key, same result, regardless of how many times it is replayed.

## State, not order, is the source of truth

One last trap. Webhooks are not strictly ordered. A `stage.changed` event arriving before a `pipeline.created` event is normal, not exceptional. Do not write logic that assumes order, write logic that checks state. Pull the current resource by ID, decide whether the event still applies, and act accordingly. The [Hookdeck reliability guide](https://hookdeck.com/blog/reliable-webhook-infrastructure) calls this out: ordering is a mirage, state is the only thing that survives retries, races, and out-of-order delivery.

If you build all four layers, ingress dedup, side-effect idempotency, backoff with DLQ, and state-driven logic, your pipeline integration stops drifting. Without them, every retry is a slow-motion bug.

[Start free →](https://leadgrid.io/signup)

---

# The recruiter application volume problem: 93% more apps, same headcount

URL: https://leadgrid.io/blog/recruiter-application-volume-problem
Locale: en
Published: 2026-04-29
Author: Ralf Klein
Tags: recruitment, guides

Recruiters handle 93% more apps with 14% smaller teams. Hiring more recruiters is not the fix. Process redesign that scales without headcount.

Recruiting teams are running 2021 process on 2026 volume. According to [Gem's 2026 Recruiting Benchmarks Report](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report), recruiters now handle 93% more applications and 40% more open roles than five years ago, while teams have shrunk 14%. Hires per recruiter dropped 43%. The math does not pencil out, and adding headcount is not the fix.

## Why hiring more recruiters is not the answer

Doubling volume with a 14% smaller team would suggest doubling the team. Three reasons that fails.

First, finance is not approving 2x recruiter hires while engineering org charts flatten. Cost per hire is already up across most segments in the [Gem 2026 benchmarks](https://www.gem.com/resource/recruiting-benchmarks). Adding seats makes it worse without changing the conversion rate.

Second, the bottleneck has moved. Most teams treat volume as a screening problem. It is not. The same Gem data shows only 0.5% of applicants get hired, which means 99.5% of recruiter time spent reviewing resumes is wasted in aggregate. More recruiters means more wasted hours, not faster hires.

Third, the highest-converting source is not new applicants at all. Gem reports 46% of sourced hires now come from rediscovered candidates already in the CRM or ATS, up from 26% in 2021. Teams that double down on inbound review are optimizing the worst funnel they have.

## Where the time actually leaks

Run a one-week time audit on any inbound-heavy team. The pattern repeats:

- **Resume review at parity.** Every applicant gets the same first-pass attention regardless of source. A LinkedIn Easy Apply gets the same 30 seconds as a referral. That is the wrong allocation.
- **No scoring tier.** Teams without a hard auto-disqualify rule and a fast-track rule end up reading every middle-of-the-pack resume in full.
- **Synchronous screening calls.** A 20-minute phone screen for every "maybe" candidate consumes the recruiter's day even when 70% will not advance.
- **Cold sourcing while inbound piles up.** Mining existing CRM candidates is left to spare time that never appears.

None of these are headcount problems. They are process and tooling problems.

## Process moves that scale without bodies

**Rediscover before you source.** [SmartRecruiters 2025 recruitment data](https://www.smartrecruiters.com/blog/recruitment-statistics-for-2025/) backs Gem's finding that historical pipelines convert two to three times higher than cold sourcing. Before posting a role, query the CRM for past applicants who matched a similar requisition. That is one search, not 200 resume reviews.

**Tier the inbound funnel.** Build three lanes: auto-disqualify on hard requirements, fast-track on score plus referral or alumni status, manual review for the rest. The tier rules go in the dossier, not in a recruiter's head. The middle lane is where headcount feels expensive. Cutting it in half by raising the bar usually loses zero hires and frees a full recruiter-week per role.

**Async screen the maybes.** Replace the 20-minute "are you real" call with a written async ask: three questions, 48-hour window. Candidates who do not respond self-select out. Candidates who respond give a written record that hiring managers can read in 90 seconds.

**Move automation into the dossier, not around it.** When the next-step nudge, the rejection email, the scheduling link, and the hiring manager handoff all live in the candidate record, recruiters stop context-switching between five tools. The [Cronofy Candidate Expectations Report 2024](https://www.cronofy.com/reports/candidate-expectations-report-2024) found candidates expect a response within 48 hours, and drop rates spike past that window. Tooling that keeps the next action one click away is what makes 48 hours possible at volume.

## What to measure instead of time-to-hire

Aggregate time-to-hire is too coarse to debug a volume problem. Three metrics that separate the signal:

- **Time-in-stage by source.** Inbound applicants stalling in screening for 8 days while referrals clear in 2 tells you the tier rules are off, not that the funnel is slow.
- **Hire rate by lane.** If your manual-review lane converts at 0.4% and your fast-track lane converts at 12%, the manual lane is not earning its recruiter time.
- **Rediscovery hit rate.** What share of hires came from candidates already in the system? If it is below the [Gem benchmark of 46%](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report), your sourcing motion is not using its own data.

Each of these is a tag on the candidate dossier and a stage in the pipeline. None of them require a new tool, and none of them require a bigger team.

## The frame

The volume problem is not a staffing problem. It is a process problem masquerading as a staffing problem. Teams that accept the new baseline (93% more apps, 14% fewer recruiters) and redesign around it ship hires at the same speed. Teams that lobby for more headcount lose the budget conversation and keep the bottleneck.

Build the dossier so a recruiter can move a candidate in one click. Tier the funnel so 80% of applicants are decided in 30 seconds. Mine the CRM before sourcing. The volume number is not going down, but the time per candidate can.

[Start free →](https://leadgrid.io/signup)

---

# Why pipeline drop-off analysis works the same for sales and recruitment

URL: https://leadgrid.io/blog/why-pipeline-drop-off-analysis-works-the-same
Locale: en
Published: 2026-04-28
Author: Ralf Klein
Tags: pipeline, guides

Sales and recruitment look like different pipelines. The drop-off math is identical. Same diagnostic patterns, same fixes, just different stage names.

Most teams treat sales drop-off and recruitment drop-off as separate problems. They run different reports, ask different questions, and hire different specialists to fix each one. That split is mostly cultural. The math is the same.

A pipeline is a sequence of stages. People enter at the top, move stage by stage, and either close or fall out. Drop-off is the percentage that fall out at each transition. Once you accept that frame, sales and recruitment stop being different problems and start being the same problem with different labels on the boxes.

## The funnel math does not care what you call the stages

In sales, the canonical stages are Lead, MQL, SQL, Opportunity, Closed Won. In recruitment, they are Application, Screen, Interview, Offer, Hire. Five stages each. Four transitions each. At every transition, some percentage continues, some falls out.

According to the [Glue Up 2026 sales funnel benchmarks](https://www.glueup.com/blog/sales-funnel-conversion-rate-benchmarks), the typical B2B sales funnel converts Lead to MQL at 25 to 35%, MQL to SQL at 13 to 26%, SQL to Opportunity at 50 to 62%, and Opportunity to Closed Deal at 15 to 30%. Multiply those out and you get end-to-end conversion of roughly 0.3% to 1.6%.

In recruitment, [CareerPlug's 2025 Recruiting Metrics Report](https://www.careerplug.com/blog/recruiting-metrics-report/) tracked over 10 million applications and found roughly 3% of applicants reach an interview and under 1% become a hire. Same shape. Same magnitudes. The biggest single drop in both funnels happens at the qualification step: MQL to SQL in sales, Application to Screen in recruitment.

## The diagnostic patterns are the same too

When sales drop-off spikes between MQL and SQL, three things are usually true: lead volume rose faster than rep capacity, qualification criteria are misaligned between marketing and sales, or response time has slipped. When recruitment drop-off spikes between Application and Screen, three things are usually true: application volume rose faster than recruiter capacity, screening criteria are misaligned between hiring manager and recruiter, or response time has slipped.

Read those two paragraphs again. Same three diagnoses. The [Ashby 2025 Talent Trends Report](https://www.ashbyhq.com/resources) shows recruiting teams now handle nearly twice the application volume of 2021 with the same headcount, which produces exactly the bottleneck a sales team gets when leads triple but reps stay flat.

The fixes also rhyme. In sales, you tighten qualification criteria, add SLAs on response time, or invest in scoring before routing. In recruitment, you tighten screening criteria, add SLAs on time-to-respond, or invest in pre-screening before recruiter review. The verb is "filter or accelerate". That verb works in both pipelines.

## Where the analysis breaks down (and why)

The reason most teams miss the symmetry is that the data lives in different systems. CRM stores sales pipeline. ATS stores recruitment pipeline. Reports are built per system, by people who only see one funnel. So when sales drop-off and recruitment drop-off are caused by the same underlying thing (the company hired more demand than it built capacity for), nobody sees it because nobody is looking at both at once.

[SHRM research on candidate experience](https://www.shrm.org/topics-tools/news/talent-acquisition) finds 60% of candidates abandon applications because of process friction. The exact same percentage of B2B leads abandon sales conversations for the same reason: too many steps, too slow, too unclear. One number, one root cause, two reports nobody connects.

## What unified pipeline analysis unlocks

If you can run the same drop-off query against both funnels, three things become obvious that were invisible before. First, capacity bottlenecks at shared resources, like a hiring manager who is also a deal sponsor, show up as drop-off in both pipelines simultaneously. Second, process improvements compound: an SLA pattern that lifts sales conversion is the same SLA pattern that lifts offer acceptance. Third, you stop hiring two analytics teams to answer one question.

That is the practical case for treating sales and recruitment as one pipeline product, not two. The data model is the same. The diagnostics are the same. The fixes are the same. The only thing different is the label on the box.

[Start free →](https://leadgrid.io/signup)

---

# Four LeadGrid API integrations your team will actually use

URL: https://leadgrid.io/blog/leadgrid-api-integrations-you-will-actually-use
Locale: en
Published: 2026-04-25
Author: Ralf Klein
Tags: api, product, guides

LeadGrid exposes every pipeline action as a REST endpoint. Here are four integrations teams build in an afternoon, with real code examples.

LeadGrid is built API-first. Every action you can take in the UI - create a dossier, move a lead through a stage, add a note, assign an owner - is a documented REST call. That's a design choice, not a side feature.

According to the [Postman 2025 State of the API Report](https://www.postman.com/state-of-api/2025/), 82% of organizations have adopted some level of an API-first approach. The teams that build on top of their pipeline tool rather than around it are the ones that stop doing the same manual task twice a week.

Here are four integrations teams actually ship, with the code to prove it.

## 1. Web form submission creates a dossier automatically

This is the most common one. You have a contact form, a landing page, or a partner referral link. Someone fills it in. Right now, someone on your team manually copies that data into LeadGrid. That's the first thing to kill.

The LeadGrid API lets you `POST /dossiers` to create a new record in any pipeline. A simple webhook receiver in Node handles the rest:

```ts
// Triggered by your form provider (Typeform, Tally, native form - doesn't matter)
app.post('/webhook/new-lead', async (req, res) => {
  const { name, email, company } = req.body;

  await fetch('https://api.leadgrid.io/v1/dossiers', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.LEADGRID_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      pipelineId: 'your-pipeline-id',
      title: `${name} - ${company}`,
      fields: { email, company },
    }),
  });

  res.sendStatus(200);
});
```

New lead in. No copy-paste. No one forgets.

## 2. Stage change fires a Slack notification

Sales managers check LeadGrid. The rest of the team checks Slack. If a deal moves to "Negotiation" or a candidate reaches "Final interview", your Slack channel should know before anyone has to ask.

LeadGrid webhooks let you subscribe to `dossier.stage_changed` events. When that fires, forward to your Slack incoming webhook:

```ts
app.post('/webhook/leadgrid-events', async (req, res) => {
  const { event, data } = req.body;

  if (event === 'dossier.stage_changed') {
    const { title, stage, pipelineId } = data;

    await fetch(process.env.SLACK_WEBHOOK_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        text: `Pipeline update: *${title}* moved to *${stage}*`,
      }),
    });
  }

  res.sendStatus(200);
});
```

Thirty lines. Your team stops asking "where is that deal right now?"

## 3. Closed deal pushes a record to your HR or ERP system

When a recruitment placement closes or a sales contract is signed, your back-office needs to know. Manually exporting from LeadGrid and importing into your HR platform or ERP is the kind of busywork that turns into errors by Thursday afternoon.

Subscribe to `dossier.closed` events and push the structured data directly:

```ts
if (event === 'dossier.closed') {
  const { id, title, fields } = data;

  // Push to your HR system - swap for your vendor's API
  await fetch('https://api.your-hr-tool.com/employees', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.HR_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      name: fields.candidateName,
      email: fields.email,
      startDate: fields.startDate,
      role: fields.jobTitle,
    }),
  });
}
```

LeadGrid becomes the trigger. Your HR system receives clean, structured data. No CSV in sight.

## 4. Nightly pipeline report sent to your inbox

Management wants a snapshot every morning. Who moved yesterday? What is stalled? What needs attention?

A simple cron job that calls `GET /dossiers?filter=updated_since=yesterday` and formats the result covers this entirely:

```ts
// Run every morning at 07:00 via cron or a scheduled function
const yesterday = new Date(Date.now() - 86400000).toISOString();

const response = await fetch(
  `https://api.leadgrid.io/v1/dossiers?updated_since=${yesterday}`,
  { headers: { 'Authorization': `Bearer ${process.env.LEADGRID_API_KEY}` } }
);

const { dossiers } = await response.json();
const summary = dossiers.map(d => `- ${d.title}: ${d.stage}`).join('\n');

// Send via Resend, Postmark, or any transactional email provider
await sendEmail({
  to: 'team@yourcompany.com',
  subject: `Pipeline update - ${new Date().toLocaleDateString()}`,
  text: summary || 'No changes since yesterday.',
});
```

The [Postman 2025 State of the API Report](https://www.postman.com/state-of-api/2025/) also found that 52% of developers faced breaking changes from external vendors in 2024. LeadGrid maintains versioned endpoints (`/v1/`) so your integrations don't quietly break on a Tuesday.

## The pattern behind all four

Each of these follows the same structure: listen for a trigger (webhook or schedule), call the LeadGrid API to read or write data, push the result somewhere else. The API surface is consistent, authenticated with a single bearer token, and returns predictable JSON.

That's what API-first actually means in practice. You don't build workflows *inside* LeadGrid. You build workflows *on top of* it.

Full API reference, authentication docs, and webhook event catalog are at [leadgrid.io/docs](https://leadgrid.io/docs).

[Start free →](https://leadgrid.io/signup)

---

# Why your operations team panics when sales is winning

URL: https://leadgrid.io/blog/why-ops-panics-when-sales-wins
Locale: en
Published: 2026-04-23
Author: Ralf Klein
Tags: sales, recruitment, pipeline

When leads pile up and recruiting lags, ops hits the panic button. It is usually an information crisis, not a capacity crisis. Here is how to tell the difference.

There is a specific moment every 30-to-60-person company hits. Sales is closing. The pipeline is full. The CRM is lighting up. And somewhere in a Slack channel or a Monday morning meeting, an ops lead says: "We can't take on more clients right now."

The sales team is confused. The numbers look good. The ops team is stressed. Both are right, and both are missing half the picture.

## The gap between closing and delivering

Most companies at this stage run two completely separate pipelines. Sales tracks leads through a CRM: prospect, demo, proposal, closed-won. Recruitment tracks candidates through an ATS: applied, screened, interviewed, hired. Same underlying motion, different tools, zero shared context.

The problem is not that these teams move at different speeds. They always will. The problem is that nobody can see both pipelines at once.

When ops sees a full sales pipeline and does not know that three engineers are at final-round interview stage, they panic. When sales sees a slow quarter and does not know that two recent hires are still onboarding, they push harder. Every decision gets made with incomplete information.

## Time-to-hire is longer than you think

[SHRM's Talent Acquisition Benchmarking Report](https://www.shrm.org/topics-tools/research/talent-acquisition-benchmarking-report) puts average time-to-fill across industries at 36 to 44 days. For technical and specialist roles at growth-stage companies, [Greenhouse's Hiring Benchmarks](https://www.greenhouse.com/guidance/hiring-benchmarks) show median time-to-hire pushing closer to 47 days.

That means the hire you need to deliver on a deal closing this week should have been sourced five to seven weeks ago. If you can only see the sales pipeline, that gap is completely invisible.

## The visibility problem, not the capacity problem

Here is what usually happens in practice: ops is right that the team is stretched. But they're wrong about why, and wrong about the fix.

The instinct is to slow down sales. "Let's not take on new clients until we hire." That sounds rational. But if you could see that four candidates are in final rounds and will likely start within three weeks, the math changes entirely. The team is stretched right now. It will not be stretched in a month.

The decision is not "slow down sales." The decision is "at which stage of which pipeline does the actual bottleneck sit?" You cannot answer that question if you are looking at one pipeline.

## What changes when you see both at once

When sales and recruitment pipelines share the same view, a few things shift immediately.

**Timing decisions improve.** You can see that you have ten leads at proposal stage and five candidates at offer stage, and make an informed call about whether to accelerate, hold, or hire faster.

**Forecasting gets honest.** Capacity planning at 30-100 people is mostly gut feel because the data lives in two tools that do not talk. A shared view makes the dependency visible: every closed deal needs a delivery team, and that team comes from a pipeline you should be watching in parallel.

**Panic drops.** Most of the stress that ops teams experience in this phase is not a capacity crisis. It is an information crisis. When you can see that recruitment is tracking ahead of plan, a full CRM stops being a threat and starts being a goal.

## The fix is not another integration

The obvious move is to pipe your ATS into your CRM or vice versa. That is what most teams try first. It produces a mess: mismatched data models, fields that map awkwardly, dashboards that show numbers but not context.

The cleaner fix is to model both pipelines in the same tool from the start. Sales leads and job candidates are both people moving through stages. Give them a name, a stage, a deadline, an owner, and you have described both. The difference is only in the outcome: closed-won versus hired.

[Deloitte's Global Human Capital Trends research](https://www.deloitte.com/global/en/insights/focus/human-capital-trends.html) finds that organizations with integrated talent and business planning cycles make workforce decisions significantly faster than those that plan separately. At the 10-to-100-person scale, that speed is not a competitive advantage. It is the difference between scaling smoothly and hiring in panic mode.

## Ops is not wrong to worry

The gut feeling that "we can't take this on" is often correct at its core. Teams at the 30-to-80-person stage are genuinely running close to capacity. The problem is not that ops is wrong. It is that they are making a call without the data they need.

When the recruiting pipeline is visible next to the sales pipeline, the question changes from "should we slow down?" to "what needs to be true for us to say yes to this?" That is a much more useful conversation to be having.

[Start free →](https://leadgrid.io/signup)

---

# How long can you keep a candidate in your talent pool? The GDPR rules explained

URL: https://leadgrid.io/blog/talent-pool-retention-period-gdpr
Locale: en
Published: 2026-04-22
Author: Ralf Klein
Tags: recruitment, guides

Rejected candidates, near-misses, future fits: how long can you legally hold their data in a talent pool under GDPR? Here is the exact answer.

A candidate applied, made it to the final round, and did not get the job. You want to keep them on file for the next opening. That instinct is right. The execution needs to be deliberate, because under GDPR, "keeping someone on file" is a processing activity with a legal basis and a retention limit.

Here is what the rules actually say.

## The default: four weeks after rejection

When a candidate applies for a specific role and you reject them, you may keep their data for **four weeks** after the rejection. This covers the period in which the candidate might file an objection or request access to their file.

After those four weeks, if you have no other legal basis, the data must be deleted.

No consent, no active pipeline, no open role: delete.

## Extending into a talent pool: you need explicit consent

Keeping a candidate longer, in a talent pool, requires **explicit, informed consent**. Not implied consent. Not a pre-ticked box. Not a blanket line buried in your privacy policy.

The candidate must actively agree to:

- being kept in a talent pool
- for a specific retention period you name upfront
- for a purpose you describe clearly (future roles, not general marketing)

Standard practice in the Netherlands and across the EU is a **maximum of one year** with a single consent. After a year, you either re-ask for consent or delete the record. Some organisations set the window at two years, which is defensible if the role type has a slow hiring cycle, but one year is the safer default.

## What the consent request should include

A compliant talent pool opt-in has three components:

1. **What you are storing.** CV, contact details, interview notes, assessment scores. Be specific.
2. **Why.** Future vacancies at your organisation that match their profile.
3. **How long.** One year from the date of consent. Not "for the foreseeable future."

Add a clear opt-out mechanism. The candidate can withdraw consent at any time, and withdrawal must be as easy as giving consent.

If you are using a recruitment tool or ATS, check whether it logs consent timestamps and sends automatic deletion reminders when the retention period expires. Manual tracking in a spreadsheet is a compliance liability at any scale.

## Near-misses and talent pools in practice

The talent pool rule applies equally to:

- Candidates who were rejected outright
- Candidates who were a good fit but lost to a stronger hire
- Candidates who withdrew their application mid-process

The legal basis does not change based on how close they came. If they are no longer in an active process, you need consent or you delete.

One nuance: if the candidate sent an **open application** with no specific role attached, the implied expectation is that you are storing it for future consideration. That context alone does not constitute valid GDPR consent, but it does make the opt-in conversation easier.

## The Dutch Autoriteit Persoonsgegevens position

The Dutch data protection authority (AP) has published guidance confirming that talent pool storage requires explicit consent and recommends a maximum retention period of **one year**. They have actively fined organisations for retaining candidate data without a valid legal basis.

If you operate across EU borders, the rules are consistent. GDPR applies uniformly. Local DPAs may differ slightly on enforcement emphasis, but the consent and retention requirements are the same.

## What to build into your process

Three practical steps that eliminate most compliance risk:

**At rejection:** send a single, clear email asking whether the candidate wants to join your talent pool. Include what that means, how long their data will be kept, and a one-click opt-in.

**On consent:** log the date and what was consented to. Your ATS or CRM should do this automatically. If it does not, that is a tooling problem worth solving.

**At expiry:** automated reminder when the consent window lapses. Either re-request consent or trigger a deletion workflow.

This is not complex to implement. It is easy to skip. Skipping it is what creates the compliance exposure.

## The short version

Rejected candidate, no consent: delete after four weeks. Talent pool with consent: up to one year, then re-ask or delete. Log everything. Opt-out must be simple.

That is the whole rule. The rest is implementation.

---

# ATS or CRM? Recruitment Agencies Are Asking the Wrong Question

URL: https://leadgrid.io/blog/ats-vs-crm-recruitment-agencies
Locale: en
Published: 2026-04-21
Author: Ralf Klein
Tags: recruitment, guides, pipeline

Most recruitment agencies agonize over ATS vs CRM, then buy both. Here is why the question itself is the problem, and what a lighter stack looks like.

Your best candidate this week is in the ATS. Your hottest client is in the CRM. On Thursday, the client calls asking for exactly that profile. You paste notes across two tabs, fire off a follow-up, and hope nothing slips. On Friday, the candidate accepts an offer elsewhere because the reply took two days to land.

That is the ATS vs CRM problem in 15 seconds. Two tools. Two tabs. One gap.

## Two Tools Built for Two Different Teams

The ATS was designed for internal HR teams managing high-volume hiring. It moves applications through stages, stores resumes, and tracks time-to-hire. The CRM was designed for sales teams managing client relationships. It logs calls, reminds you to follow up, and tracks deal stages.

Neither was designed for the person running both motions at once: the recruiter at a 12-person staffing bureau who needs to match the right candidate to the right client opening before either side goes cold. When you bolt an ATS onto a CRM, or run them side by side, you get the overhead of two systems without the clarity of either.

## The Stack Is Getting Heavier as Teams Get Smaller

[Gem's 2026 Recruiting Benchmarks Report](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report), which tracked over 165 million applicants, found that recruiting teams now handle 93% more applications than they did in 2021 while headcount has shrunk by 14%. Teams are being asked to run harder on a track that has gotten longer.

Adding a second system to that workload is the wrong answer. Every manual sync between the ATS and the CRM is time a recruiter is not spending on the candidate or the client. Every context switch between dashboards is a window where something slips through.

## What Slipping Through Looks Like in Practice

The [iHire 2025 State of Online Recruiting Report](https://www.ihire.com/about-us/press-room/articles/2025/ihire-releases-2025-state-of-online-recruiting-survey-results) found that 59% of job seekers named being ghosted by employers as their top job search frustration. Ghosting is rarely deliberate. It is what happens when a recruiter loses track of a candidate because their data lives in a different system from the client conversation.

On the client side, the same gap shows up differently. A lead goes cold not because there was no good candidate, but because the recruiter was head-down in the ATS when the client went quiet, with no shared view of where things stood.

[SmartRecruiters' 2025 recruitment statistics](https://www.smartrecruiters.com/blog/recruitment-statistics-for-2025/) put a number on this: 22% of talent teams report difficulty tracking applicants through their own hiring process. That is not a recruiter problem. That is a tool problem.

## The Practical Takeaway

Before you sign another annual contract, trace your last five placements and find where each candidate sat without a touchpoint for more than 48 hours. In most agencies, that delay happens at two specific moments: right after the initial screen, when the candidate moves from the ATS into "email the client," and right after a client shows interest, when the recruiter switches back to the ATS to pull candidate details.

Those are the handoff points. That is where your pipeline leaks. Fixing the tool is faster than training around the gap.

## One Grid Handles Both Motions

LeadGrid is not an ATS. It is not a CRM. That is the point.

It puts candidates and clients in the same pipeline grid, with the same stage logic, the same ownership model, and the same visibility. When a client opens a role, you see which candidates are already at the right stage. When a candidate progresses, the relevant client context is one click away. There is no second tab to switch to and no manual sync to run.

Teams at 5 to 50 people who have bounced off Salesforce, HubSpot, Greenhouse, or Lever often find that what they needed was not a better version of either tool. They needed one grid that handles both motions without the overhead of two stacks.

**[Start free →](https://leadgrid.io/signup)**

---

# Half Your Pipeline Drops Out Before You Even Notice

URL: https://leadgrid.io/blog/half-pipeline-drops-before-notice
Locale: en
Published: 2026-04-20
Author: Ralf Klein
Tags: recruitment, pipeline

47% of candidates cite poor communication as their reason for dropping out. The leak is not at the top of your funnel. It is in the handoff.

A strong candidate completes two rounds of interviews. The hiring manager likes them. The recruiter is ready to move forward. Then a week passes. Then two. No one sent a follow-up. The candidate, assuming they were ghosted, accepts an offer elsewhere.

This is not an edge case. [According to the 2025 Ghosting Index by The Interview Guys](https://blog.theinterviewguys.com/the-2025-ghosting-index/), **61% of job seekers have been ghosted after a job interview**, a nine percentage point increase since early 2024. The number keeps climbing, and it is not because candidates are becoming less committed. It is because the teams hiring them are not following up.

The drop is not happening at the top of your funnel.

## The loss happens after the interest

Most hiring teams focus on sourcing. They optimize job descriptions, run LinkedIn campaigns, and refine application forms. Meanwhile, the biggest drop-off sits further down the pipeline, inside stages where the candidate has already raised their hand.

Research from [The HT Group](https://www.thehtgroup.com/how-to-fix-top-candidate-drop-off-in-the-hiring-process/) puts it precisely: the interview stage alone accounts for nearly a third of all candidate loss, with the scheduling stage adding another 20%. That means more than half of every candidate you worked to attract drops out after they were already engaged. They wanted the role. They showed up. Then the process lost them.

Better sourcing will not fix this. A faster handoff will.

## Poor communication is the stated reason, not a guess

When candidates drop out, they say why. [The Cronofy Candidate Expectations Report 2024](https://www.cronofy.com/reports/candidate-expectations-report-2024) found that **47% of candidates cite poor communication as their reason for withdrawing** from a hiring process. Not salary. Not commute. Not a competing offer. Communication.

The mechanism is straightforward. A recruiter finishes the screening call and moves the candidate forward. The hiring manager receives the handoff but has six other open roles, a sprint review, and a board deck due this week. The candidate waits. After seven days of silence, 34% assume they have already been rejected and stop responding.

This is the part that stings: the candidate did not lose interest. The process lost the candidate. And by the time someone notices the record has been sitting in the same stage for ten days, the candidate is two weeks into a new role.

## The handoff is where ownership breaks down

In most scale-ups, the recruiter owns the pipeline until an interview is scheduled. Then ownership shifts, informally, to the hiring manager. There is no explicit handoff. No timestamp. No visible next step. Both people assume the other is handling it.

Offer acceptance tells the full story. [CareerPlug's 2025 Candidate Experience Statistics](https://www.careerplug.com/candidate-experience-statistics/) report that offer acceptance rates fell to 51% in Q2 2025, down from 74% just two years prior. Teams are reaching the offer stage and still losing the candidate. That is not a sourcing problem or a compensation problem. That is a visibility problem.

When no one can see who owns the next step, the next step does not happen.

## Audit the stage where ownership changes

Look at your pipeline and find the stage where the last activity timestamp is oldest. That is almost always the recruiter-to-hiring-manager handoff. Now run the same check for every active role, not just the one you are currently worried about.

The pattern is consistent across teams: pipeline leaks most where ownership is assumed rather than assigned. A candidate sitting in "interview scheduled" for eleven days has an owner problem, not a candidate problem. The fix starts with making that visible.

Flag every record where the last activity was more than five business days ago and ownership is unclear. You will find your drop-off. It will not be random. It will cluster at the same stage, for the same reason, every time.

## The candidates are not ghosting you. The handoff is.

Running recruitment in a spreadsheet while the hiring manager tracks notes in email is not a workflow gap. It is a structural guarantee that something will drop. Nobody has visibility across both, so nobody catches the silence before it costs a hire.

LeadGrid puts candidates in a single cockpit with explicit stage ownership and a visible last-activity marker for every record. When a candidate sits too long without a next step, that is visible to everyone who needs to see it, not buried in someone's inbox or hidden in a tab they forgot to check.

**[Start free →](https://leadgrid.io/signup)**

---

# Five things you automate when every pipeline action is a REST call

URL: https://leadgrid.io/blog/automate-pipeline-with-rest-api
Locale: en
Published: 2026-04-18
Author: Ralf Klein
Tags: api, engineering

LeadGrid exposes every UI action through a documented REST API. Here are five automations you can ship in an afternoon, without a single CSV export.

Every LeadGrid UI action, create a dossier, move a stage, add a note, assign a member, is a documented REST call. That's not a feature; it's the shape of the product. It means the boundary between "what LeadGrid does" and "what your own code does" is just an HTTP request.

Here are five automations that take less than an afternoon once you stop thinking of your CRM as a thing you click on.

## 1. Auto-create dossiers from inbound email

Every workspace gets an inbound address. Forward a lead or a CV to it, LeadGrid parses the sender and attachment, creates a structured dossier, and fires a webhook at your automation layer.

No scraping a shared inbox. No CSV upload. Your AE forwards a client intro, and by the time they refresh the grid the dossier is assigned, tagged, and in the correct pipeline.

## 2. Stage-based Slack pings with context

`dossier.stage_changed` webhook → your function → Slack message. The body includes dossier name, old stage, new stage, assignee, and deadline. You write the filter: `if new_stage == "Interview" and dossier.type == "candidate"` → `#recruitment-live`. Sales deals follow a different channel and a different threshold.

You're not reconfiguring notifications in a vendor UI. You're expressing a rule in code, versioned with the rest of your infra.

## 3. Deadline escalations that actually escalate

LeadGrid has built-in deadlines. What's different is you can subscribe to `dossier.deadline_missed` and react the way *your* team operates: page the owner's manager, post in the escalation channel, open a Linear ticket, or fire a calendar reminder 24 hours before.

The API lets you compose escalations out of services you already run. No new dashboard to check.

## 4. Keep your data warehouse current without ETL

Every dossier event, created, moved, closed, commented, is available as a webhook. Pipe them into a queue, write them to your warehouse, and your BI layer is caught up in seconds instead of the 24-hour lag of a nightly sync.

```ts
// pseudo-handler
app.post("/webhooks/leadgrid", async (req) => {
  const sig = req.headers["x-leadgrid-signature"];
  verify(sig, req.rawBody);            // HMAC, documented
  await queue.publish("leadgrid", req.body);
  return { ok: true };
});
```

No ETL pipeline, no scheduled job, no "oh the sync is broken again." The source of truth pushes, your warehouse listens.

## 5. Agents that move pipelines on their own

This is where it gets fun. Because every action is a REST call with a clean OpenAPI spec, an LLM can drive LeadGrid. A Claude or GPT agent can:

- Read a candidate's CV from storage
- Write an AI summary and post it as a note
- Move the dossier to the next stage if the summary matches the role
- Email the candidate a structured next-step using the workspace's sender domain

None of this requires scraping. The agent calls `POST /v1/dossiers/<id>/notes` the same way a human clicks "Add note."

We're not selling a closed AI feature on top of a closed CRM. We're selling a programmable pipeline, and you decide which of those loops run with humans, which with automation, and which with agents.

## The underlying point

Every CRM can produce a CSV. Very few are designed so the entire surface is as callable as a library. LeadGrid is. Read the spec at [`/docs/api`](/docs/api), grab an API key from your workspace settings, and ship your first automation in an afternoon.

[Start free →](/signup)

---

# Two pipelines, one bottleneck

URL: https://leadgrid.io/blog/two-pipelines-one-bottleneck
Locale: en
Published: 2026-04-16
Author: Ralf Klein
Tags: pipeline, sales, recruitment

Most scale-ups run sales and recruitment on two stacks that never talk. A single hiring manager is the bottleneck in both pipelines at once.

On a Friday afternoon at almost every scale-up we work with, two things fail in the same building and nobody notices they are the same thing. A strong enterprise lead slips because the AE is waiting on the hiring manager to confirm capacity before committing to a timeline. Two floors down, a senior engineer the recruiter has been nurturing for three weeks goes quiet, because that same hiring manager has not returned the calibration call. The lead leaks. The candidate cools. Monday morning both teams report the loss in their own standup, on their own board, with their own explanation.

Those are not two separate problems. They are one problem, seen twice, by teams who cannot see each other.

## The shape is identical, the stacks are not

Every scale-up above a certain size runs two motions that look the same on paper. Sales has leads moving from qualified to discovery to proposal to close. Recruitment has candidates moving from sourced to screen to interview to offer. Same pipeline shape, same stages in spirit, same ownership model, same notion of last-touch and next-touch. Wire one up on HubSpot or Pipedrive, wire the other on Greenhouse or Workable, and you have two motions that never see each other. The people who block one often block the other. The context that matters in one often matters in the other. Neither tool knows that.

## The data is already uncomfortable

The structural cost of fragmentation is quantified. A recent [Gartner Sales Operations benchmark](https://www.gartner.com/en/sales/trends/2025-sales-operations-leadership-vision) found that revenue operations teams now commonly support five or more groups and spend 68% of their time on nonclient work. Two thirds of ops bandwidth goes to coordination, tool glue, reconciliation, and the slow decoding of what a different system actually meant when it set a status. That is before anyone asks whether the two adjacent motions in your company, sales and hiring, share so much as a stage definition.

On the candidate side the leak is faster and more visible. Industry reporting on [the 2025 hiring process](https://blog.theinterviewguys.com/state-of-the-hiring-process-in-2025/) points at a blunt dynamic, the best candidates are off the market in roughly 10 days, and application abandonment sits around 60% when the process drags. When sales gets the commercial answer it needs and recruitment is still waiting, the candidate has already said yes to someone else. Your AE does not know. Your recruiter knows, but has nowhere to flag it that the AE would see.

The inverse proves the point. [HubSpot Research](https://www.hubspot.com/state-of-marketing) found that when sales and customer success share an operational frame, retention jumps 36% and win rates climb 38%. The lesson is not about CS specifically, it is about adjacency. Two teams working the same buyer relationship perform radically better when they can see each other. There is no published benchmark yet for sales plus recruitment alignment because almost nobody has measured it, but the mechanism is the same. Adjacency rewarded once will reward twice.

## The anatomy of a handoff failure

Every handoff leak we have traced in a scale-up resolves to one of three mechanics.

The first is **stale ownership**. A lead or a candidate has a name next to it. That name is someone who has since moved to another team, gone on holiday, or quietly disengaged from the account. The record is not wrong on purpose. It is wrong because nothing in the stack ever forced a refresh. On a single-motion stack this is painful. On two motions that block each other, it is multiplicative.

The second is the **invisible stage**. A lead moves from "qualified" to "discovery" in the CRM. The recruiter does not see it. Why would they? The lead is a sales artifact. But the same account also has a hiring manager who is one of four decision makers on the deal. When sales moves the record, recruitment does not know the temperature just shifted. A calibration call that could have happened this week instead happens in three weeks, after the stage has already stalled.

The third, and the most expensive, is the **cross-motion bottleneck**. One person, usually a hiring manager or a VP Engineering, is the rate-limit in two different pipelines at once. The sales team is waiting on them to green-light headcount before they can commit to scope. The recruitment team is waiting on them to sign off on the offer before a candidate accepts. Each team escalates individually. Each team adds to the pile that the same person has to clear. If either team had seen the other's queue, they would have batched the conversation. Neither saw it.

## What a shared cockpit actually changes

Ownership becomes one field, not two. The same person, listed as owner of record, carries forward into both motions for the accounts where it is the same person. Stages become legible across teams. A lead moving to "proposal" flags the recruitment record for the same company, because the roles being hired against that account just became time-critical. Bottlenecks surface as bottlenecks, not as two unrelated reschedule requests. The hiring manager sees what is pending from both sides on a single view and makes one decision instead of waiting to be pushed twice.

This is what it means to put two pipelines in one grid, and it is the reason LeadGrid exists. Not because sales teams are tired of CRMs and recruitment teams are tired of ATSes, though both are true. Because the handoff that breaks a scale-up is not inside either tool, it is between them.

## The audit to run on Monday

You do not need a new platform to start. You need to find where your handoffs actually leak. A few things to try in the first week, with whatever you have.

Walk into Monday morning and list every lead that stalled last week together with every candidate that stalled last week. Put them in the same spreadsheet, sorted by the named person waiting on something. Count how often the same person shows up in both columns. That number is your cross-motion bottleneck rate. At most scale-ups we have helped, it sits between 15 and 30 percent. That is 15 to 30 percent of your stalls that are not a sales problem or a recruitment problem, they are a queue problem.

Then check your ownership fields. For every active record in both systems, ask whether the person listed responded to email within the last five working days. The percentage that fails is your stale-ownership rate. Anything above 20% means the record is lying to you at the moment you need it most.

Finally, pick one open account where the company is both a deal and a hiring target. Line up the sales activity log and the recruitment activity log side by side. Notice every moment where one team could have saved the other a day. That list is your handoff deficit.

## The fix is one grid, not a bigger CRM

The reason revenue leaks at the join between sales and recruitment is not that your CRM is bad or your ATS is wrong. It is that your motion is one thing and your stack is two. The fix is not a bigger CRM. It is not a deeper ATS. It is a grid that shows both pipelines with the same vocabulary, the same owner field, and the same notion of what "stuck" means. Give ops leaders one view of the motion, and the motion stops dropping people on the floor.

**[Start free →](https://leadgrid.io/signup)**

---

# Why we built LeadGrid as one API for two pipelines

URL: https://leadgrid.io/blog/why-we-built-leadgrid
Locale: en
Published: 2026-04-14
Author: Ralf Klein
Tags: product, api

Most growth teams run a CRM and an ATS for the same motion. Here's what collapses when you model sales and recruitment on one data model, and why we made it programmable by default.

Every growth team I've worked with runs the same motion twice. Sales has a CRM. Recruitment has an ATS. Same pipeline shape, intake, qualify, move, close, but on two stacks that don't talk.

We built LeadGrid because that split is a choice, not a constraint.

## The data model is the same

A lead and a candidate are both *people moving through stages*. Give them a name, a stage, a deadline, an owner, a set of notes, and you've described both. The verbs are identical: create, assign, move, comment, close.

The industry built two product categories around this because it was profitable to do so, not because the underlying work is different. Teams ended up paying two vendors, integrating two APIs, training on two UIs, and reconciling two sources of truth, to track the same thing twice.

## What collapses when you unify

Running one platform for both pipelines does three concrete things:

- **Hand-offs stop dropping.** Sales promises delivery. Recruitment finds the people who deliver. When both look at the same grid, escalations happen before the candidate walks away or the deal slips.
- **Tooling cost halves.** One workspace, one billing line, one permissions model. Sales and recruitment stop fighting over which tool is the source of truth, it's the same one.
- **Reporting becomes honest.** Time-to-hire and time-to-close live in the same database. You can finally answer "did we miss this deal because we didn't have the person?" without a spreadsheet.

## API-first, not API-afterthought

The other deliberate choice: every action the UI does is a REST call. Create a dossier, move a stage, add a note, assign a member, all scriptable, all documented at [`/docs/api`](/docs/api).

That sounds table-stakes, and it should be, but most CRMs hold their best features back for a higher tier, wrap the API in rate limits designed to push you into professional services, or refuse to document webhooks. We wanted the opposite: the API is the product, the UI is a convenient way to use it.

The practical consequence: your automations don't care whether something is a lead or a candidate. You write one integration once, and it works across both pipelines. Claude, n8n, Zapier, your own backend, same endpoint shape, same auth, same webhook schema.

## Free forever on the free plan

One last thing. LeadGrid is free forever on the free plan, not a 14-day trial, not a limited-time promo. You can run a real team on it, ship real pipelines, and never pay us a cent. Paid plans unlock more seats, active dossiers, flows, and API throughput when you outgrow the free limits.

We'd rather have you on the platform building than watching a trial countdown.

[Start free →](/signup)

---

## NL posts

# Lead scoring zonder ML: waarom een scorekaart met vijf regels wint voor de meeste teams

URL: https://leadgrid.io/nl/blog/lead-scoring-zonder-ml-vijf-regels-scorekaart
Locale: nl
Published: 2026-05-13
Author: Ralf Klein
Tags: sales, guides

De meeste teams die machine learning lead scoring invoeren halen 80% van de waarde uit een scorekaart met vijf regels. Wanneer wel upgraden, en wanneer niet.

Elk kwartaal komt er weer een salesteam langs dat zegt AI lead scoring nodig te hebben. We graven door, en wat ze eigenlijk nodig hebben is een schone scorekaart van vijf regels met negatieve gewichten en een decay-functie. Het ML-model is de kop, maar de winst zit in de basis die bijna niemand eerst opzet.

Dit is geen contrair standpunt. Het is precies wat onderaan elke eerlijke ML-gids staat. Het probleem is dat de rules-versie saai klinkt, dus teams slaan die over en betalen voor een model dat het verkeerde leert uit vieze data.

## Het wiskundige probleem dat de meeste teams eerst hebben

Een predictief model heeft genoeg closed-won en closed-lost voorbeelden nodig om van te leren. De meeste B2B-teams hebben dat volume nog niet. Volgens de [Prospeo guide on AI versus traditional lead scoring](https://prospeo.io/s/ai-lead-scoring-vs-traditional-lead-scoring) ligt de praktische ondergrens rond de 1.000 leads per jaar, 100 gesloten deals en 12 tot 24 maanden schone CRM-data voordat een ML-model een verdedigbare score oplevert. Daaronder verslaat een goed gebouwd rules-based model elke keer een slecht getraind AI-model.

Dat is het stuk dat vendor decks weglaten. Een model dat getraind is op 60 conversies en een jaar inconsistente fase-definities leert je koper niet, het leert je probleem met datahygiëne.

## Waarom de rules-versie meestal wint

Forrester is hier al jaren keihard over. Het [Forrester piece on what lead scoring actually is](https://www.forrester.com/blogs/what-is-lead-scoring-anyway/) stelt dat de meeste productieve scoring-modellen gebouwd zijn op aannames en willekeurige schattingen van koopintentie, niet op echte analyse. Dat vervangen door een ML-model dat op dezelfde wankele inputs is getraind, fixt de inputs niet, het maakt de score alleen moeilijker om te betwisten.

Een eenvoudige scorekaart is auditbaar, snel aan te passen, en dwingt de sales- en marketingteams om het erover eens te worden wat "qualified" betekent voordat ze hem live zetten. Die alignment is waar de meeste echte winst vandaan komt. De [Clueless Company breakdown of failing lead scoring models](https://www.theclueless.company/lead-scoring-techniques/) zegt het goed: de meest voorkomende reden dat scoring-projecten falen is niet slechte logica, het is dat sales de score niet vertrouwt, dus reps blijven werken met wie ze toch al bewerkten.

Je kunt geen vertrouwen bouwen in een black box. Wel in vijf regels die je van een whiteboard kunt aflezen.

## De scorekaart met vijf regels

Hier is de versie die we aanraden voor elke LeadGrid-klant onder de ML-drempel. Hij past op één scherm en legt zichzelf uit.

```yaml
fit_score:
  icp_company_size:    { match: +20, miss: -15 }
  icp_industry:        { match: +15, miss: -10 }
  decision_maker_role: { match: +20, miss: -10 }

intent_score:
  pricing_page_visit:  +20
  demo_request:        +30
  three_emails_opened: +5
  inactivity_per_week: -5

threshold_for_sales_handoff: 50
```

Vijf regels, twee negatieve gewichten, één decay-regel. Dat is het. De structuur is geleend van de [Reform guide on common lead scoring mistakes](https://www.reform.app/blog/common-lead-scoring-mistakes-and-fixes), die direct is over de twee faalmodi die een basis-scorekaart moet oplossen: te veel signalen tegelijk volgen creëert ruis, en alleen positieve scores toekennen vult je CRM met koude leads die niemand opruimt.

De decay-regel telt zwaarder dan mensen denken. Het [Breadcrumbs B2B lead scoring framework for 2026](https://breadcrumbs.io/blog/b2b-lead-scoring/) raadt aan punten af te trekken voor elke week inactiviteit, juist zodat zombie-MQL's niet bovenaan de wachtrij staan terwijl een hetere lead van vanochtend eronder hangt. Zonder decay is je scorekaart een hi-score lijst, geen wachtrij.

## Wanneer wel doorgroeien naar ML

Er is een echte drempel waarop ML-scoring zijn complexiteit verdient. Je bent eroverheen als drie dingen tegelijk waar zijn.

Je hebt minstens 100 schone closed-won en 100 schone closed-lost records, met consistente fase-definities over die hele historie. De [Landbase lead scoring statistics roundup](https://www.landbase.com/blog/lead-scoring-statistics) citeert Forrester-data die 38% hogere conversie en 28% kortere sales cycles laat zien voor teams met AI scoring, maar die cijfers komen van teams die de datahygiëne hadden om op te trainen. Zonder die hygiëne leert het model je rommelige CRM, niet je koper.

Je sales cycle is complex genoeg dat mensen de variabelen niet meer in hun hoofd kunnen vasthouden. Multi-stakeholder enterprise deals met 18+ touchpoints over zes maanden zijn een ander probleem dan een self-serve SaaS funnel met een free trial gate. ML verdient zijn brood op de complexe vorm, niet op de eenvoudige.

Je hebt al een rules-based versie live en je kunt precies benoemen welke regel het ML-model gaat verslaan. Kun je die niet benoemen, dan lost het ML-model geen probleem op dat jij hebt, het lost er één op dat een vendor heeft.

## De eerlijke hybride

Het patroon dat werkt is rules-based scoring als basislaag, met ML als overlay erbovenop zodra je de data hebt om dat te verantwoorden. De rules geven je een score die reps op dag één vertrouwen. De ML-overlay, als je hem live zet, past de score aan op basis van patronen die de regels niet zien, maar de menselijk leesbare score blijft in de UI staan.

Daar wijst de [SiriusDecisions data on lead scoring adoption](https://salesdorado.com/en/sales-qualification/lead-scoring-useless/) ook op: 68% van de bedrijven draaide lead scoring, maar slechts 40% van de salesmensen zag er waarde in. De teams in die 40% hadden een model dat reps konden uitleggen. De teams in de andere 60% hadden een model dat reps niet geloofden.

Bouw eerst de versie met vijf regels. Verdien de ML-upgrade zodra je data en je salesteam er klaar voor zijn. De meeste teams hoeven die tweede stap nooit te zetten, en dat is prima.

[Gratis starten →](https://leadgrid.io/signup)

---

# Het applicatievolume-probleem voor recruiters: 93% meer sollicitaties, zelfde headcount

URL: https://leadgrid.io/nl/blog/applicatievolume-recruiters-probleem
Locale: nl
Published: 2026-04-29
Author: Ralf Klein
Tags: recruitment, guides

Recruiters verwerken 93% meer sollicitaties met 14% kleinere teams. Meer recruiters aannemen is niet de fix. Procesherontwerp dat schaalt zonder headcount.

Recruitmentteams draaien een 2021-proces op 2026-volume. Volgens [Gem's 2026 Recruiting Benchmarks Report](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report) verwerken recruiters nu 93% meer sollicitaties en beheren ze 40% meer openstaande rollen dan vijf jaar geleden, terwijl teams met 14% zijn gekrompen. Aannames per recruiter daalden 43%. De rekensom klopt niet, en headcount toevoegen is niet de fix.

## Waarom meer recruiters aannemen niet het antwoord is

Het volume verdubbelen met een 14% kleiner team zou suggereren dat je het team verdubbelt. Drie redenen waarom dat faalt.

Ten eerste keurt finance geen 2x recruiter-hires goed terwijl engineering-organogrammen platter worden. De cost per hire is al gestegen in de meeste segmenten volgens de [Gem 2026 benchmarks](https://www.gem.com/resource/recruiting-benchmarks). Seats toevoegen maakt het erger zonder de conversie te veranderen.

Ten tweede is het knelpunt verschoven. De meeste teams zien volume als een screeningsprobleem. Dat is het niet. Dezelfde Gem-data laat zien dat slechts 0,5% van de sollicitanten wordt aangenomen, wat betekent dat 99,5% van de recruitertijd voor cv-review in totaal wordt verspild. Meer recruiters betekent meer verspilde uren, geen snellere hires.

Ten derde is de best converterende bron helemaal geen nieuwe sollicitanten. Gem rapporteert dat 46% van de sourced hires nu uit herontdekte kandidaten in de CRM of ATS komt, een stijging van 26% in 2021. Teams die dubbel inzetten op inbound-review optimaliseren de slechtste funnel die ze hebben.

## Waar de tijd echt weglekt

Doe een time audit van een week op elk inbound-zwaar team. Het patroon herhaalt zich:

- **Cv-review op pariteit.** Elke sollicitant krijgt dezelfde eerste aandacht ongeacht bron. Een LinkedIn Easy Apply krijgt dezelfde 30 seconden als een referral. Dat is de verkeerde verdeling.
- **Geen scoringslaag.** Teams zonder harde auto-disqualify-regel en fast-track-regel lezen elk middelmatig cv volledig.
- **Synchrone screeningsgesprekken.** Een telefoongesprek van 20 minuten voor elke "misschien"-kandidaat slokt de dag van de recruiter op, ook als 70% niet door zal gaan.
- **Cold sourcing terwijl inbound zich opstapelt.** Bestaande CRM-kandidaten doorzoeken wordt overgelaten aan vrije tijd die er nooit komt.

Geen van deze zijn headcount-problemen. Het zijn proces- en tooling-problemen.

## Procesbewegingen die schalen zonder mensen

**Herontdek voordat je sourced.** [SmartRecruiters 2025 recruitment data](https://www.smartrecruiters.com/blog/recruitment-statistics-for-2025/) ondersteunt Gem's bevinding dat historische pipelines twee tot drie keer hoger converteren dan cold sourcing. Voordat je een rol publiceert, doorzoek de CRM op eerdere sollicitanten die matchten met een vergelijkbare aanvraag. Dat is één zoekopdracht, geen 200 cv-reviews.

**Geef de inbound-funnel lagen.** Bouw drie banen: auto-disqualify op harde eisen, fast-track op score plus referral of alumni-status, handmatige review voor de rest. De laagregels horen in het dossier, niet in het hoofd van een recruiter. De middelste baan is waar headcount duur voelt. Hem halveren door de lat hoger te leggen verliest meestal nul hires en bespaart een volledige recruiter-week per rol.

**Async screen de maybes.** Vervang het gesprek van 20 minuten "ben je echt" door een schriftelijke async-vraag: drie vragen, venster van 48 uur. Kandidaten die niet reageren selecteren zichzelf eruit. Kandidaten die wel reageren leveren een geschreven verslag dat hiring managers in 90 seconden lezen.

**Verplaats automatisering naar het dossier, niet eromheen.** Als de next-step-nudge, de afwijzingsmail, de planlink en de hiring-manager-handoff allemaal in het kandidaatdossier staan, stoppen recruiters met context-switchen tussen vijf tools. Het [Cronofy Candidate Expectations Report 2024](https://www.cronofy.com/reports/candidate-expectations-report-2024) vond dat kandidaten een reactie binnen 48 uur verwachten, en dat drop-rates pieken na dat venster. Tooling die de volgende actie op één klik houdt, is wat 48 uur mogelijk maakt op volume.

## Wat je moet meten in plaats van time-to-hire

Geaggregeerde time-to-hire is te grof om een volumeprobleem te debuggen. Drie metrics die het signaal scheiden:

- **Tijd-in-fase per bron.** Inbound-sollicitanten die 8 dagen blijven hangen in screening terwijl referrals binnen 2 dagen door zijn, vertelt je dat de laagregels niet kloppen, niet dat de funnel langzaam is.
- **Hire-rate per baan.** Als jouw handmatige-review-baan converteert op 0,4% en je fast-track-baan op 12%, verdient de handmatige baan zijn recruitertijd niet.
- **Rediscovery hit rate.** Welk aandeel van de hires kwam uit kandidaten die al in het systeem zaten? Als het onder de [Gem-benchmark van 46%](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report) ligt, gebruikt jouw sourcing-beweging zijn eigen data niet.

Elk hiervan is een tag op het kandidaatdossier en een fase in de pipeline. Geen van alle vereist een nieuwe tool, en geen van alle vereist een groter team.

## De frame

Het volumeprobleem is geen staffing-probleem. Het is een procesprobleem dat zich vermomt als staffing-probleem. Teams die de nieuwe basislijn accepteren (93% meer sollicitaties, 14% minder recruiters) en daaromheen herontwerpen, leveren hires op dezelfde snelheid. Teams die lobbyen voor meer headcount verliezen het budgetgesprek en houden het knelpunt.

Bouw het dossier zo dat een recruiter een kandidaat in één klik kan verplaatsen. Geef de funnel lagen zodat 80% van de sollicitanten in 30 seconden is afgehandeld. Doorzoek de CRM voordat je source. Het volumegetal gaat niet omlaag, maar de tijd per kandidaat wel.

[Gratis starten →](https://leadgrid.io/signup)

---

# Waarom pipeline drop-off analyse hetzelfde werkt voor sales en recruitment

URL: https://leadgrid.io/nl/blog/pipeline-drop-off-analyse-werkt-hetzelfde
Locale: nl
Published: 2026-04-28
Author: Ralf Klein
Tags: pipeline, guides

Sales en recruitment lijken verschillende pipelines. De drop-off wiskunde is identiek. Dezelfde diagnoses, dezelfde fixes, alleen andere fasen-labels.

De meeste teams behandelen sales drop-off en recruitment drop-off als losse problemen. Ze draaien verschillende rapporten, stellen andere vragen en huren andere specialisten in om elk probleem op te lossen. Die scheiding is vooral cultureel. De wiskunde is identiek.

Een pipeline is een reeks fasen. Mensen komen er bovenaan in, bewegen fase voor fase door, en sluiten of vallen uit. Drop-off is het percentage dat uitvalt bij elke overgang. Zodra je dat frame accepteert, zijn sales en recruitment niet langer verschillende problemen, maar hetzelfde probleem met andere labels op de dozen.

## De funnel-wiskunde geeft niet om hoe je de fasen noemt

In sales zijn de standaardfasen Lead, MQL, SQL, Opportunity, Closed Won. In recruitment zijn dat Sollicitatie, Screen, Interview, Offer, Hire. Vijf fasen per pipeline. Vier overgangen per pipeline. Bij elke overgang gaat een percentage door, een ander deel valt uit.

Volgens de [Glue Up 2026 sales funnel benchmarks](https://www.glueup.com/blog/sales-funnel-conversion-rate-benchmarks) converteert de typische B2B sales-funnel Lead naar MQL op 25 tot 35%, MQL naar SQL op 13 tot 26%, SQL naar Opportunity op 50 tot 62%, en Opportunity naar Closed Deal op 15 tot 30%. Vermenigvuldig die en je komt uit op een end-to-end conversie van ruwweg 0,3% tot 1,6%.

In recruitment volgde het [CareerPlug's 2025 Recruiting Metrics Report](https://www.careerplug.com/blog/recruiting-metrics-report/) ruim 10 miljoen sollicitaties en kwam tot ongeveer 3% van de sollicitanten dat een interview haalt, en onder de 1% dat daadwerkelijk wordt aangenomen. Zelfde vorm. Zelfde grootte. De grootste enkele drop in beide funnels zit op de kwalificatiestap: MQL naar SQL in sales, Sollicitatie naar Screen in recruitment.

## De diagnostische patronen zijn ook identiek

Als sales drop-off piekt tussen MQL en SQL, zijn er meestal drie dingen aan de hand: lead-volume groeide harder dan rep-capaciteit, kwalificatiecriteria zijn niet uitgelijnd tussen marketing en sales, of de reactietijd is weggezakt. Als recruitment drop-off piekt tussen Sollicitatie en Screen, zijn er meestal drie dingen aan de hand: sollicitatievolume groeide harder dan recruiter-capaciteit, screeningcriteria zijn niet uitgelijnd tussen hiring manager en recruiter, of de reactietijd is weggezakt.

Lees die twee alinea's nog eens. Dezelfde drie diagnoses. Het [Ashby 2025 Talent Trends Report](https://www.ashbyhq.com/resources) laat zien dat recruitmentteams nu bijna tweemaal het sollicitatievolume van 2021 verwerken met dezelfde bezetting, en dat is precies de bottleneck die een salesteam krijgt als leads verdrievoudigen maar reps gelijk blijven.

De fixes rijmen ook. In sales scherp je kwalificatiecriteria aan, leg je SLA's op reactietijd op, of investeer je in scoring vóór routing. In recruitment scherp je screeningcriteria aan, leg je SLA's op reactietijd op, of investeer je in pre-screening vóór de recruiter het oppikt. Het werkwoord is "filter of versnel". Dat werkwoord werkt in beide pipelines.

## Waar de analyse strandt (en waarom)

De reden dat de meeste teams die symmetrie missen, is dat de data in verschillende systemen leeft. CRM bewaart de sales-pipeline. ATS bewaart de recruitment-pipeline. Rapporten worden per systeem gebouwd, door mensen die maar één funnel zien. Dus als sales drop-off en recruitment drop-off worden veroorzaakt door hetzelfde onderliggende ding (het bedrijf heeft meer vraag binnengehaald dan het aan capaciteit heeft gebouwd), ziet niemand het, want niemand kijkt naar beide tegelijk.

[SHRM-onderzoek naar kandidaatervaring](https://www.shrm.org/topics-tools/news/talent-acquisition) vindt dat 60% van de kandidaten sollicitaties afbreekt vanwege procesfrictie. Exact hetzelfde percentage B2B-leads breekt salesgesprekken af om dezelfde reden: te veel stappen, te traag, te onduidelijk. Eén getal, één hoofdoorzaak, twee rapporten die niemand verbindt.

## Wat unified pipeline-analyse oplevert

Als je dezelfde drop-off query kunt draaien tegen beide funnels, worden drie dingen zichtbaar die eerder onzichtbaar waren. Ten eerste: capaciteitsbottlenecks bij gedeelde resources, zoals een hiring manager die ook deal-sponsor is, komen tegelijk in beide pipelines naar boven als drop-off. Ten tweede: procesverbeteringen stapelen op, een SLA-patroon dat sales-conversie liftt, is hetzelfde SLA-patroon dat offer-acceptatie liftt. Ten derde: je stopt met twee analytics-teams inhuren om één vraag te beantwoorden.

Dat is de praktische case voor het behandelen van sales en recruitment als één pipeline-product, niet twee. Het datamodel is hetzelfde. De diagnoses zijn hetzelfde. De fixes zijn hetzelfde. Het enige verschil is het label op de doos.

[Gratis starten →](https://leadgrid.io/signup)

---

# Vier LeadGrid API-integraties die je team echt gaat gebruiken

URL: https://leadgrid.io/nl/blog/leadgrid-api-integraties-die-je-team-echt-gebruikt
Locale: nl
Published: 2026-04-25
Author: Ralf Klein
Tags: api, product, guides

LeadGrid exposeert elke pipeline-actie als een REST-endpoint. Vier integraties die teams in een middag bouwen, inclusief echte codevoorbeelden.

LeadGrid is API-first gebouwd. Elke actie die je in de UI kunt uitvoeren - een dossier aanmaken, een lead door een fase bewegen, een notitie toevoegen, een eigenaar toewijzen - is een gedocumenteerde REST-aanroep. Dat is een ontwerpkeuze, geen bijzaak.

Volgens het [Postman 2025 State of the API Report](https://www.postman.com/state-of-api/2025/) heeft 82% van de organisaties een API-first aanpak omarmd. Teams die bovenop hun pipeline-tool bouwen in plaats van er omheen, zijn de teams die stoppen met dezelfde handmatige taak twee keer per week te herhalen.

Hier zijn vier integraties die teams echt bouwen, inclusief de code.

## 1. Webformulier-inzending maakt automatisch een dossier aan

Dit is de meest voorkomende. Je hebt een contactformulier, een landingspagina of een partnerverwijzingslink. Iemand vult het in. Nu kopieert iemand van je team die gegevens handmatig naar LeadGrid. Dat is het eerste wat je moet afschaffen.

De LeadGrid API laat je `POST /dossiers` aanroepen om een nieuw record in een pipeline aan te maken. Een simpele webhook-ontvanger in Node doet de rest:

```ts
// Getriggerd door je formulierprovider (Typeform, Tally, eigen formulier - maakt niet uit)
app.post('/webhook/new-lead', async (req, res) => {
  const { name, email, company } = req.body;

  await fetch('https://api.leadgrid.io/v1/dossiers', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.LEADGRID_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      pipelineId: 'your-pipeline-id',
      title: `${name} - ${company}`,
      fields: { email, company },
    }),
  });

  res.sendStatus(200);
});
```

Nieuwe lead binnen. Geen kopieer-plak. Niemand die het vergeet.

## 2. Fasewijziging verstuurt een Slack-melding

Salesmanagers kijken in LeadGrid. De rest van het team kijkt in Slack. Als een deal naar "Onderhandeling" gaat of een kandidaat de "Eindgesprek"-fase bereikt, moet je Slack-kanaal dat weten voordat iemand ernaar hoeft te vragen.

LeadGrid-webhooks laten je abonneren op `dossier.stage_changed`-events. Als dat vuurt, stuur je het door naar je Slack incoming webhook:

```ts
app.post('/webhook/leadgrid-events', async (req, res) => {
  const { event, data } = req.body;

  if (event === 'dossier.stage_changed') {
    const { title, stage, pipelineId } = data;

    await fetch(process.env.SLACK_WEBHOOK_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        text: `Pipeline-update: *${title}* verplaatst naar *${stage}*`,
      }),
    });
  }

  res.sendStatus(200);
});
```

Dertig regels. Je team stopt met vragen: "waar staat die deal nu eigenlijk?"

## 3. Gesloten deal stuurt een record naar je HR- of ERP-systeem

Als een recruitment-plaatsing afgerond is of een salescontract getekend, moet je backoffice dat weten. Handmatig exporteren uit LeadGrid en importeren in je HR-platform of ERP is precies het soort werk dat donderdagmiddag tot fouten leidt.

Abonneer je op `dossier.closed`-events en stuur de gestructureerde data direct door:

```ts
if (event === 'dossier.closed') {
  const { id, title, fields } = data;

  // Push naar je HR-systeem - vervang door de API van jouw leverancier
  await fetch('https://api.your-hr-tool.com/employees', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.HR_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      name: fields.candidateName,
      email: fields.email,
      startDate: fields.startDate,
      role: fields.jobTitle,
    }),
  });
}
```

LeadGrid is de trigger. Je HR-systeem ontvangt schone, gestructureerde data. Geen CSV te bekennen.

## 4. Nachtelijk pipeline-rapport in je inbox

Management wil elke ochtend een snapshot. Wat is er gisteren bewogen? Wat staat stil? Wat heeft aandacht nodig?

Een simpele cron-job die `GET /dossiers?filter=updated_since=yesterday` aanroept en het resultaat opmaakt, dekt dit volledig:

```ts
// Elke ochtend om 07:00 draaien via cron of een geplande functie
const yesterday = new Date(Date.now() - 86400000).toISOString();

const response = await fetch(
  `https://api.leadgrid.io/v1/dossiers?updated_since=${yesterday}`,
  { headers: { 'Authorization': `Bearer ${process.env.LEADGRID_API_KEY}` } }
);

const { dossiers } = await response.json();
const summary = dossiers.map(d => `- ${d.title}: ${d.stage}`).join('\n');

// Verstuur via Resend, Postmark of een andere transactionele e-mailprovider
await sendEmail({
  to: 'team@yourcompany.com',
  subject: `Pipeline-update - ${new Date().toLocaleDateString()}`,
  text: summary || 'Geen wijzigingen sinds gisteren.',
});
```

Het [Postman 2025 State of the API Report](https://www.postman.com/state-of-api/2025/) concludeerde ook dat 52% van de ontwikkelaars in 2024 te maken had met breaking changes van externe leveranciers. LeadGrid onderhoudt versioned endpoints (`/v1/`) zodat je integraties niet stilletjes op een dinsdagochtend stukgaan.

## Het patroon achter alle vier

Elke integratie volgt dezelfde structuur: luister naar een trigger (webhook of schema), roep de LeadGrid API aan om data te lezen of schrijven, en stuur het resultaat ergens anders naartoe. Het API-oppervlak is consistent, geverifieerd met één bearer token en retourneert voorspelbare JSON.

Dat is wat API-first in de praktijk betekent. Je bouwt workflows niet *binnen* LeadGrid. Je bouwt ze *bovenop*.

Volledige API-referentie, authenticatiedocumentatie en webhook-eventcatalogus vind je op [leadgrid.io/docs](https://leadgrid.io/docs).

[Gratis starten →](https://leadgrid.io/signup)

---

# Waarom je operationeel team in paniek raakt als sales wint

URL: https://leadgrid.io/nl/blog/waarom-ops-in-paniek-raakt-als-sales-wint
Locale: nl
Published: 2026-04-23
Author: Ralf Klein
Tags: sales, recruitment, pipeline

Als leads zich opstapelen en recruitment achterblijft, raakt ops in paniek. Meestal is het een informatiecrisis, geen capaciteitscrisis. Zo zie je het verschil.

Er is een specifiek moment dat elk bedrijf van 30 tot 60 mensen meemaakt. Sales sluit deals. De pipeline zit vol. De CRM licht op. En ergens in een Slack-kanaal of maandagochtendoverleg zegt een ops-lead: "We kunnen nu geen nieuwe klanten aannemen."

Het salesteam snapt het niet. De cijfers zien er goed uit. Het ops-team staat onder druk. Beiden hebben gelijk, en beiden missen de helft van het plaatje.

## Het gat tussen afsluiten en leveren

De meeste bedrijven in deze fase draaien twee volledig gescheiden pipelines. Sales volgt leads via een CRM: prospect, demo, voorstel, gesloten. Recruitment volgt kandidaten via een ATS: aangemeld, gescreend, geïnterviewd, aangenomen. Dezelfde onderliggende beweging, verschillende tools, nul gedeelde context.

Het probleem is niet dat deze teams in een ander tempo werken. Dat doen ze altijd. Het probleem is dat niemand beide pipelines tegelijk kan zien.

Wanneer ops een volle salespipeline ziet maar niet weet dat drie engineers in de eindrondes zitten, raakt ops in paniek. Wanneer sales een traag kwartaal ziet maar niet weet dat twee nieuwe medewerkers nog inwerken, duwt sales harder. Elke beslissing wordt genomen met onvolledige informatie.

## Time-to-hire is langer dan je denkt

[SHRM's Talent Acquisition Benchmarking Report](https://www.shrm.org/topics-tools/research/talent-acquisition-benchmarking-report) plaatst de gemiddelde time-to-fill over sectoren heen op 36 tot 44 dagen. Voor technische en specialistische rollen bij groeibedrijven laat [Greenhouse's Hiring Benchmarks](https://www.greenhouse.com/guidance/hiring-benchmarks) zien dat de mediane time-to-hire richting de 47 dagen gaat.

Dat betekent dat de medewerker die je nodig hebt om de deal van deze week te leveren, vijf tot zeven weken geleden al gesourced had moeten zijn. Als je alleen de salespipeline kunt zien, is dat gat volledig onzichtbaar.

## Het zichtbaarheidsprobleem, niet het capaciteitsprobleem

Dit is wat er in de praktijk meestal gebeurt: ops heeft gelijk dat het team het druk heeft. Maar ze zitten er naast over de oorzaak, en over de oplossing.

De reflex is om sales te remmen. "Laten we geen nieuwe klanten aannemen totdat we hebben aangeworven." Dat klinkt rationeel. Maar als je zou kunnen zien dat vier kandidaten in de eindrondes zitten en waarschijnlijk binnen drie weken starten, verandert de rekensom volledig. Het team heeft het nu druk. Over een maand niet meer.

De vraag is niet "remmen we sales af?" De vraag is "in welke fase van welke pipeline zit de echte bottleneck?" Die vraag kun je niet beantwoorden als je maar naar één pipeline kijkt.

## Wat er verandert als je beide tegelijk ziet

Wanneer sales- en recruitmentpipeline dezelfde view delen, verschuiven er een paar dingen direct.

**Timingbeslissingen verbeteren.** Je ziet dat je tien leads in de offertafase hebt en vijf kandidaten in de aanbodingsfase, en je kunt een weloverwogen beslissing nemen: versnellen, afwachten of sneller aannemen.

**Forecasting wordt eerlijk.** Capaciteitsplanning bij 30 tot 100 mensen is grotendeels buikgevoel, omdat de data in twee tools leeft die niet met elkaar praten. Een gedeelde view maakt de afhankelijkheid zichtbaar: elke gesloten deal heeft een leveringsteam nodig, en dat team komt uit een pipeline die je parallel in de gaten moet houden.

**Paniek verdwijnt.** De meeste stress die ops-teams in deze fase ervaren, is geen capaciteitscrisis. Het is een informatiecrisis. Wanneer je kunt zien dat recruitment op schema ligt, is een volle CRM geen bedreiging meer, maar een doel.

## De oplossing is niet nog een integratie

De voor de hand liggende stap is je ATS aan je CRM koppelen of andersom. Dat is wat de meeste teams als eerste proberen. Het levert een warboel op: niet-overeenkomende datamodellen, velden die lastig te mappen zijn, dashboards die cijfers tonen maar geen context.

De nettere oplossing is om beide pipelines vanaf het begin in hetzelfde tool te modelleren. Salesleads en kandidaten zijn allebei mensen die door fasen bewegen. Geef ze een naam, een fase, een deadline, een eigenaar, en je hebt beiden beschreven. Het verschil zit alleen in de uitkomst: gesloten deal versus aangenomen.

[Deloitte's Global Human Capital Trends onderzoek](https://www.deloitte.com/global/en/insights/focus/human-capital-trends.html) laat zien dat organisaties met geïntegreerde talent- en businessplanningscycli aanzienlijk sneller personeelsbeslissingen nemen dan organisaties die apart plannen. Op de schaal van 10 tot 100 mensen is die snelheid geen concurrentievoordeel. Het is het verschil tussen soepel schalen en in paniekmode aanwerven.

## Ops heeft niet voor niets zorgen

Het buikgevoel van "we kunnen dit er niet bij hebben" klopt vaak wel degelijk. Teams van 30 tot 80 mensen draaien echt op het randje van hun capaciteit. Het probleem is niet dat ops het mis heeft. Het probleem is dat ze een beslissing nemen zonder de data die ze nodig hebben.

Wanneer de recruitmentpipeline naast de salespipeline zichtbaar is, verandert de vraag van "moeten we afremmen?" naar "wat moet er waar zijn om hiertegen ja te kunnen zeggen?" Dat is een veel nuttiger gesprek om te voeren.

[Gratis starten →](https://leadgrid.io/signup)

---

# Hoe lang mag je een kandidaat in je talent pool bewaren? De AVG-regels uitgelegd

URL: https://leadgrid.io/nl/blog/bewaartermijn-talent-pool-avg
Locale: nl
Published: 2026-04-22
Author: Ralf Klein
Tags: recruitment, guides

Afgewezen kandidaten, bijna-matches, toekomstige fits: hoe lang mag je hun data legaal bewaren in een talent pool onder de AVG? Hier is het exacte antwoord.

Een kandidaat heeft gesolliciteerd, haalde de laatste ronde, maar kreeg de baan niet. Je wilt ze bewaren voor de volgende vacature. Dat instinct klopt. De uitvoering moet bewust zijn, want onder de AVG is "iemand op de lijst houden" een verwerkingsactiviteit met een wettelijke grondslag en een bewaartermijn.

Dit zeggen de regels.

## De standaard: vier weken na afwijzing

Wanneer een kandidaat solliciteert op een specifieke functie en je ze afwijst, mag je hun data bewaren voor **vier weken** na de afwijzing. Dit dekt de periode waarin de kandidaat mogelijk bezwaar maakt of inzage vraagt in hun dossier.

Na die vier weken moet je de data verwijderen als je geen andere wettelijke grondslag hebt.

Geen toestemming, geen actieve pipeline, geen openstaande vacature: verwijderen.

## Uitbreiden naar een talent pool: je hebt expliciete toestemming nodig

Een kandidaat langer bewaren, in een talent pool, vereist **expliciete, geïnformeerde toestemming**. Geen impliciete toestemming. Geen vooraf aangevinkt vakje. Geen algemene zin weggestopt in je privacybeleid.

De kandidaat moet actief instemmen met:

- opname in een talent pool
- voor een specifieke bewaartermijn die je vooraf noemt
- voor een doel dat je duidelijk omschrijft (toekomstige functies, niet algemene marketing)

Gangbare praktijk in Nederland en door de hele EU is een **maximum van één jaar** met één toestemming. Na een jaar vraag je opnieuw toestemming of verwijder je het dossier. Sommige organisaties hanteren twee jaar, wat verdedigbaar is bij functies met een langzame aanwervingscyclus, maar één jaar is de veiligste standaard.

## Wat het toestemmingsverzoek moet bevatten

Een AVG-conforme talent pool opt-in heeft drie onderdelen:

1. **Wat je bewaart.** CV, contactgegevens, gespreksnotities, beoordelingsscores. Wees specifiek.
2. **Waarom.** Toekomstige vacatures bij jouw organisatie die passen bij hun profiel.
3. **Hoe lang.** Één jaar vanaf de datum van toestemming. Niet "voor de nabije toekomst."

Voeg een duidelijk opt-out-mechanisme toe. De kandidaat kan de toestemming op elk moment intrekken, en intrekken moet even gemakkelijk zijn als toestemming geven.

Controleer bij een recruitment tool of ATS of het toestemmingstijdstempels logt en automatische verwijderherinneringen verstuurt wanneer de bewaartermijn afloopt. Handmatig bijhouden in een spreadsheet is een compliance-risico op elke schaal.

## Bijna-matches en talent pools in de praktijk

De talent pool-regel geldt gelijkelijk voor:

- Kandidaten die direct zijn afgewezen
- Kandidaten die goed pasten maar verloren van een sterkere kandidaat
- Kandidaten die hun sollicitatie halverwege het proces hebben ingetrokken

De wettelijke grondslag verandert niet op basis van hoe dicht ze in de buurt kwamen. Als ze niet meer in een actief proces zitten, heb je toestemming nodig of verwijder je.

Eén nuance: als de kandidaat een **open sollicitatie** heeft gestuurd zonder specifieke functie, is de impliciete verwachting dat je die bewaart voor toekomstige overweging. Dat alleen vormt geen geldige AVG-toestemming, maar maakt het opt-in gesprek wel gemakkelijker.

## Het standpunt van de Autoriteit Persoonsgegevens

De Nederlandse toezichthouder (AP) heeft richtsnoeren gepubliceerd die bevestigen dat talent pool-opslag expliciete toestemming vereist en een maximale bewaartermijn van **één jaar** aanbeveelt. Ze hebben actief organisaties beboet voor het bewaren van kandidaatdata zonder geldige wettelijke grondslag.

Als je over EU-grenzen heen werkt, zijn de regels consistent. De AVG is uniform van toepassing. Nationale toezichthouders kunnen licht verschillen in handhavingsfocus, maar de toestemmings- en bewaarvereisten zijn hetzelfde.

## Wat je in je proces moet inbouwen

Drie praktische stappen die de meeste compliance-risico's elimineren:

**Bij afwijzing:** stuur een enkelvoudige, duidelijke e-mail met de vraag of de kandidaat zich wil aanmelden voor je talent pool. Vermeld wat dat inhoudt, hoe lang hun data bewaard wordt, en een one-click opt-in.

**Bij toestemming:** leg de datum en wat er is ingestemd vast. Je ATS of CRM zou dit automatisch moeten doen. Als dat niet zo is, is dat een toolingprobleem dat de moeite waard is om op te lossen.

**Bij vervaldatum:** automatische herinnering wanneer het toestemmingsvenster verloopt. Vraag opnieuw toestemming of start een verwijderingsworkflow.

Dit is niet complex om te implementeren. Het is makkelijk om over te slaan. Overslaan is wat de compliance-blootstelling creëert.

## De korte versie

Afgewezen kandidaat, geen toestemming: verwijder na vier weken. Talent pool met toestemming: maximaal één jaar, daarna opnieuw vragen of verwijderen. Log alles. Opt-out moet eenvoudig zijn.

Dat is de hele regel. De rest is implementatie.

---

# ATS of CRM? Recruitmentbureaus stellen de verkeerde vraag

URL: https://leadgrid.io/nl/blog/ats-vs-crm-voor-recruitmentbureaus
Locale: nl
Published: 2026-04-21
Author: Ralf Klein
Tags: recruitment, guides, pipeline

De meeste recruitmentbureaus piekeren eindeloos over ATS vs CRM en kopen uiteindelijk allebei. Waarom de vraag zelf het probleem is, en hoe een slankere toolstack eruitziet.

Je beste kandidaat van deze week staat in het ATS. Je warmste klant staat in het CRM. Op donderdag belt die klant precies met dat profiel in gedachten. Je knipt en plakt notities tussen twee tabbladen, stuurt een follow-up en hoopt dat er niets tussenval. Op vrijdag accepteert de kandidaat een aanbod elders, omdat jouw reactie twee dagen op zich liet wachten.

Dat is het ATS vs CRM-probleem in vijftien seconden. Twee tools. Twee tabbladen. Eén gat.

## Twee tools gebouwd voor twee verschillende teams

Het ATS is ontworpen voor interne HR-teams die grote aantallen vacatures verwerken. Het begeleidt sollicitaties door de stages, slaat cv's op en houdt de time-to-hire bij. Het CRM is ontworpen voor salesteams die klantrelaties beheren. Het logt gesprekken, herinnert je aan follow-ups en bewaakt de dealstages.

Geen van beide is gebouwd voor degene die beide bewegingen tegelijk uitvoert: de recruiter bij een bureau van twaalf mensen die de juiste kandidaat moet koppelen aan de juiste klantopening vóórdat beide partijen afhaken. Als je een ATS aan een CRM koppelt, of ze naast elkaar draait, betaal je de overhead van twee systemen zonder de helderheid van één.

## De toolstack wordt zwaarder terwijl teams kleiner worden

[Gem's 2026 Recruiting Benchmarks Report](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report), dat meer dan 165 miljoen sollicitanten volgde, stelde vast dat recruitingteams nu 93% meer sollicitaties verwerken dan in 2021, terwijl de bezetting met 14% is gekrompen. Teams moeten harder lopen op een parcours dat langer is geworden.

Een tweede systeem toevoegen aan die werkdruk is het verkeerde antwoord. Elke handmatige sync tussen het ATS en het CRM is tijd die een recruiter niet besteedt aan de kandidaat of de klant. Elke contextwisseling tussen dashboards is een moment waarop iets door de mazen glipt.

## Hoe 'door de mazen glippen' er in de praktijk uitziet

Het [iHire 2025 State of Online Recruiting Report](https://www.ihire.com/about-us/press-room/articles/2025/ihire-releases-2025-state-of-online-recruiting-survey-results) stelde vast dat 59% van de werkzoekenden werd genegeerd door werkgevers, hun grootste frustratie in het sollicitatieproces. Ghosting is zelden opzettelijk. Het is wat er gebeurt als een recruiter het spoor van een kandidaat bijster raakt omdat de data in een ander systeem staat dan het klantgesprek.

Aan de klantenkant manifesteert hetzelfde gat zich anders. Een lead koelt af, niet omdat er geen geschikte kandidaat was, maar omdat de recruiter met het hoofd in het ATS zat toen de klant stil werd, zonder een gedeeld overzicht van de stand van zaken.

[SmartRecruiters' 2025 recruitment statistics](https://www.smartrecruiters.com/blog/recruitment-statistics-for-2025/) zetten er een getal op: 22% van de talentteams geeft aan moeite te hebben met het bijhouden van kandidaten in hun eigen wervingsproces. Dat is geen recruitersprobleem. Dat is een toolprobleem.

## De praktische conclusie

Voordat je een volgende jaarcontract tekent, loop dan je laatste vijf plaatsingen na en zoek uit waar elke kandidaat langer dan 48 uur zonder contactmoment heeft gezeten. Bij de meeste bureaus doet die vertraging zich voor op twee specifieke momenten: vlak na het eerste gesprek, wanneer de kandidaat vanuit het ATS "richting mail naar de klant" gaat, en vlak nadat een klant interesse toont, wanneer de recruiter terugschakelt naar het ATS om kandidaatdetails op te halen.

Dat zijn de handoff-momenten. Daar lekt jouw pipeline. Het probleem in de tool aanpakken gaat sneller dan werken om het gat heen.

## Eén grid voor beide bewegingen

LeadGrid is geen ATS. Het is geen CRM. Dat is precies het punt.

Het plaatst kandidaten en klanten in dezelfde pipeline-grid, met dezelfde stagelogica, hetzelfde eigendomsmodel en dezelfde zichtbaarheid. Wanneer een klant een vacature opent, zie je meteen welke kandidaten al op de juiste stage zitten. Wanneer een kandidaat vordert, is de relevante klantcontext één klik verwijderd. Geen tweede tabblad om naar te wisselen, geen handmatige sync om uit te voeren.

Teams van 5 tot 50 mensen die zijn vastgelopen op Salesforce, HubSpot, Greenhouse of Lever, ontdekken vaak dat ze geen betere versie van één van die tools nodig hadden. Ze hadden één grid nodig die beide bewegingen afhandelt zonder de overhead van twee stacks.

**[Gratis starten →](https://leadgrid.io/signup)**

---

# De helft van je pipeline valt weg voordat je het doorhebt

URL: https://leadgrid.io/nl/blog/helft-pipeline-valt-weg-voor-signaal
Locale: nl
Published: 2026-04-20
Author: Ralf Klein
Tags: recruitment, pipeline

47% van de kandidaten noemt slechte communicatie als reden om af te haken. Het lek zit niet bovenaan je funnel. Het zit in de overdracht.

Een sterke kandidaat doorloopt twee gespreksrondes. De hiring manager is enthousiast. De recruiter is klaar om door te gaan. Dan verstrijkt er een week. Dan twee. Niemand heeft een follow-up gestuurd. De kandidaat, die ervan uitgaat dat hij genegeerd wordt, accepteert elders een aanbod.

Dit is geen uitzondering. [Volgens de 2025 Ghosting Index van The Interview Guys](https://blog.theinterviewguys.com/the-2025-ghosting-index/) **is 61% van de werkzoekenden geghost na een sollicitatiegesprek**, een stijging van negen procentpunten ten opzichte van begin 2024. Het getal blijft stijgen, en dat is niet omdat kandidaten minder betrokken zijn geworden. Het is omdat de teams die hen werven geen follow-up geven.

Het lek zit niet bovenaan je funnel.

## Het verlies gebeurt ná de interesse

De meeste wervingsteams focussen op sourcing. Ze optimaliseren vacatureteksten, draaien LinkedIn-campagnes en verfijnen sollicitatieformulieren. Ondertussen zit de grootste uitval verderop in de pipeline, in stages waar de kandidaat al zijn hand heeft opgestoken.

Onderzoek van [The HT Group](https://www.thehtgroup.com/how-to-fix-top-candidate-drop-off-in-the-hiring-process/) is precies: de interviewfase alleen al is verantwoordelijk voor bijna een derde van al het kandidaatverlies, waarbij de planningsfase nog eens 20% toevoegt. Dat betekent dat meer dan de helft van elke kandidaat die je met moeite hebt aangetrokken afhaakt nadat ze al betrokken waren. Ze wilden de rol. Ze kwamen opdagen. Vervolgens verloor het proces hen.

Betere sourcing lost dit niet op. Een snellere overdracht wel.

## Slechte communicatie is de genoemde reden, geen aanname

Als kandidaten afhaken, zeggen ze waarom. [Het Cronofy Candidate Expectations Report 2024](https://www.cronofy.com/reports/candidate-expectations-report-2024) stelde vast dat **47% van de kandidaten slechte communicatie noemt als reden om zich terug te trekken** uit een wervingsproces. Niet het salaris. Niet de reistijd. Niet een concurrerend aanbod. Communicatie.

Het mechanisme is simpel. Een recruiter rondt het screeningsgesprek af en stuurt de kandidaat door. De hiring manager ontvangt de overdracht maar heeft zes andere openstaande rollen, een sprint review en een boardpresentatie deze week. De kandidaat wacht. Na zeven dagen stilte gaan 34% ervan uit dat ze al zijn afgewezen en stoppen ze met reageren.

Dit is het pijnlijke deel: de kandidaat was niet minder geïnteresseerd. Het proces verloor de kandidaat. En tegen de tijd dat iemand opmerkt dat het dossier al tien dagen in dezelfde stage staat, zit de kandidaat twee weken in een nieuwe baan.

## De overdracht is waar eigenaarschap wegvalt

In de meeste scale-ups heeft de recruiter de pipeline in handen totdat een gesprek is ingepland. Dan verschuift het eigenaarschap, informeel, naar de hiring manager. Er is geen expliciete overdracht. Geen tijdstempel. Geen zichtbare volgende stap. Beide mensen gaan ervan uit dat de ander het regelt.

Aanbodacceptatie vertelt het volledige verhaal. [De 2025 Candidate Experience Statistics van CareerPlug](https://www.careerplug.com/candidate-experience-statistics/) rapporteren dat de acceptatiegraad van aanbiedingen daalde naar 51% in Q2 2025, van 74% slechts twee jaar eerder. Teams bereiken de aanbiedingsfase en verliezen de kandidaat nog steeds. Dat is geen sourcing-probleem of compensatieprobleem. Dat is een zichtbaarheidsprobleem.

Als niemand kan zien wie verantwoordelijk is voor de volgende stap, gebeurt de volgende stap niet.

## Analyseer de stage waar eigenaarschap wisselt

Bekijk je pipeline en zoek de stage waar de tijdstempel van de laatste activiteit het oudst is. Dat is bijna altijd de overdracht van recruiter naar hiring manager. Doe nu dezelfde controle voor elke actieve rol, niet alleen de rol waar je je op dit moment zorgen over maakt.

Het patroon is consistent in alle teams: de pipeline lekt het meest waar eigenaarschap wordt aangenomen in plaats van toegewezen. Een kandidaat die elf dagen in "gesprek gepland" staat heeft een eigenaarschapsprobleem, geen kandidaatprobleem. De oplossing begint met dit zichtbaar maken.

Markeer elk dossier waarbij de laatste activiteit meer dan vijf werkdagen geleden was en het eigenaarschap onduidelijk is. Je vindt je uitval. Het zal niet willekeurig zijn. Het clustert bij dezelfde stage, om dezelfde reden, elke keer.

## De kandidaten negeren jou niet. De overdracht wel.

Recruitment bijhouden in een spreadsheet terwijl de hiring manager notities in e-mail bijhoudt is geen workflow-lacune. Het is een structurele garantie dat er iets uitvalt. Niemand heeft zicht over beide, dus niemand merkt de stilte op voordat er een hire verloren gaat.

LeadGrid plaatst kandidaten in één cockpit met expliciet stage-eigenaarschap en een zichtbare laatste-activiteitsmarkering voor elk dossier. Als een kandidaat te lang zonder een volgende stap zit, is dat zichtbaar voor iedereen die het moet zien, niet begraven in iemands inbox of verborgen in een tabblad dat ze vergeten zijn te bekijken.

**[Gratis beginnen →](https://leadgrid.io/signup)**

---

# Vijf dingen die je automatiseert als elke pipeline-actie een REST-call is

URL: https://leadgrid.io/nl/blog/pipeline-automatiseren-met-rest-api
Locale: nl
Published: 2026-04-18
Author: Ralf Klein
Tags: api, engineering

LeadGrid biedt elke UI-actie aan via een gedocumenteerde REST API. Dit zijn vijf automatiseringen die je op een middag live kunt zetten, zonder ook maar één CSV-export.

Elke LeadGrid UI-actie, een dossier aanmaken, een fase verplaatsen, een notitie toevoegen, een lid toewijzen, is een gedocumenteerde REST-call. Dat is geen feature; dat is de kern van het product. Het betekent dat de grens tussen "wat LeadGrid doet" en "wat jouw eigen code doet" gewoon een HTTP-request is.

Dit zijn vijf automatiseringen die minder dan een middag kosten, zodra je je CRM niet meer ziet als iets waar je op klikt.

## 1. Automatisch dossiers aanmaken vanuit inkomende e-mail

Elke workspace krijgt een inbound-adres. Stuur een lead of een CV erheen, LeadGrid parseert de afzender en de bijlage, maakt een gestructureerd dossier aan en stuurt een webhook naar je automatiseringslaag.

Geen gedeelde inbox handmatig leegvissen. Geen CSV-upload. Je AE stuurt een klantintroductie door, en tegen de tijd dat ze de grid vernieuwen is het dossier toegewezen, getagd en in de juiste pipeline.

## 2. Fase-gebaseerde Slack-meldingen met context

`dossier.stage_changed` webhook → jouw functie → Slack-bericht. De body bevat dossiernaam, oude fase, nieuwe fase, toegewezene en deadline. Jij schrijft de filter: `if new_stage == "Interview" and dossier.type == "candidate"` → `#recruitment-live`. Sales-deals volgen een ander kanaal en een andere drempel.

Je herconfigureert geen meldingen in een vendor-UI. Je formuleert een regel in code, geversioneerd samen met de rest van je infra.

## 3. Deadline-escalaties die echt escaleren

LeadGrid heeft ingebouwde deadlines. Het verschil is dat je je kunt abonneren op `dossier.deadline_missed` en kunt reageren op de manier waarop *jouw* team werkt: de manager van de eigenaar pingen, posten in het escalatiekanaal, een Linear-ticket openen, of een kalenderherinnering 24 uur van tevoren sturen.

De API laat je escalaties samenstellen uit diensten die je al gebruikt. Geen nieuw dashboard om te bekijken.

## 4. Je data warehouse actueel houden zonder ETL

Elk dossier-event, aangemaakt, verplaatst, gesloten, van commentaar voorzien, is beschikbaar als webhook. Stuur ze naar een queue, schrijf ze naar je warehouse, en je BI-laag is binnen seconden bijgewerkt in plaats van de 24-uurs vertraging van een nachtelijke sync.

```ts
// pseudo-handler
app.post("/webhooks/leadgrid", async (req) => {
  const sig = req.headers["x-leadgrid-signature"];
  verify(sig, req.rawBody);            // HMAC, gedocumenteerd
  await queue.publish("leadgrid", req.body);
  return { ok: true };
});
```

Geen ETL-pipeline, geen geplande taak, geen "oh, de sync is weer stuk." De bron van waarheid pusht, jouw warehouse luistert.

## 5. Agents die pipelines zelfstandig vooruit bewegen

Hier wordt het interessant. Omdat elke actie een REST-call is met een schone OpenAPI-spec, kan een LLM LeadGrid aansturen. Een Claude- of GPT-agent kan:

- Het CV van een kandidaat uit storage lezen
- Een AI-samenvatting schrijven en als notitie plaatsen
- Het dossier naar de volgende fase verplaatsen als de samenvatting bij de rol past
- De kandidaat een gestructureerde vervolgstap e-mailen via het senderdomein van de workspace

Hier is geen scraping voor nodig. De agent roept `POST /v1/dossiers/<id>/notes` aan, precies zoals een mens op "Notitie toevoegen" klikt.

We verkopen geen gesloten AI-feature bovenop een gesloten CRM. We verkopen een programmeerbare pipeline, en jij bepaalt welke loops met mensen draaien, welke met automatisering, en welke met agents.

## De kern van de zaak

Elk CRM kan een CSV produceren. Heel weinig zijn zo ontworpen dat het volledige oppervlak zo aanroepbaar is als een bibliotheek. LeadGrid wel. Lees de spec op [`/docs/api`](/docs/api), pak een API-sleutel uit je workspace-instellingen, en zet je eerste automatisering op een middag live.

[Gratis starten →](/signup)

---

# Twee pipelines, één knelpunt

URL: https://leadgrid.io/nl/blog/twee-pipelines-een-knelpunt
Locale: nl
Published: 2026-04-16
Author: Ralf Klein
Tags: pipeline, sales, recruitment

De meeste scale-ups draaien sales en recruitment op twee stacks die nooit met elkaar praten. Eén hiring manager is tegelijkertijd het knelpunt in beide pipelines.

Op een vrijdagmiddag bij vrijwel iedere scale-up waarmee we werken, lopen twee dingen tegelijk mis in hetzelfde gebouw, en niemand heeft door dat het eigenlijk hetzelfde probleem is. Een sterke enterprise lead glipt weg omdat de AE wacht tot de hiring manager capaciteit bevestigt voordat hij een tijdlijn toezegt. Twee verdiepingen lager valt een senior engineer stil die de recruiter al drie weken koesterde, omdat diezelfde hiring manager de calibratie-call nog niet heeft teruggebeld. De lead lekt. De kandidaat koelt af. Maandagochtend rapporteren beide teams het verlies in hun eigen standup, op hun eigen board, met hun eigen verklaring.

Dat zijn geen twee aparte problemen. Het is één probleem, twee keer gezien, door teams die elkaar niet kunnen zien.

## De vorm is identiek, de stacks niet

Elke scale-up boven een bepaalde omvang draait twee processen die op papier hetzelfde lijken. Sales heeft leads die van qualified naar discovery naar proposal naar close bewegen. Recruitment heeft kandidaten die van sourced naar screen naar interview naar offer gaan. Dezelfde pipeline-vorm, dezelfde fases in essentie, hetzelfde ownership-model, hetzelfde idee van last-touch en next-touch. Richt de ene op HubSpot of Pipedrive, de andere op Greenhouse of Workable, en je hebt twee processen die elkaar nooit zien. De mensen die de ene blokkeren, blokkeren vaak ook de andere. De context die in de ene ertoe doet, doet er in de andere ook toe. Geen van beide tools weet dat.

## De data is al ongemakkelijk

De structurele kosten van fragmentatie zijn gekwantificeerd. Een recent [Gartner Sales Operations benchmark](https://www.gartner.com/en/sales/trends/2025-sales-operations-leadership-vision) stelde vast dat revenue operations-teams nu gewoonlijk vijf of meer groepen bedienen en 68% van hun tijd besteden aan niet-klantgerelateerd werk. Twee derde van de ops-capaciteit gaat op aan coördinatie, tool-lijm, reconciliatie en het langzaam ontcijferen van wat een ander systeem eigenlijk bedoelde toen het een status instelde. En dat is nog voordat iemand vraagt of de twee aangrenzende processen in jouw bedrijf, sales en recruitment, ook maar een gedeelde fase-definitie hebben.

Aan de kant van de kandidaten gaat het lek sneller en is het zichtbaarder. Branche-onderzoek naar [het wervingsproces in 2025](https://blog.theinterviewguys.com/state-of-the-hiring-process-in-2025/) wijst op een harde dynamiek: de beste kandidaten zijn in roughly 10 dagen van de markt, en het uitvalpercentage bij sollicitaties ligt rond de 60% als het proces sleept. Wanneer sales het commerciële antwoord krijgt dat het nodig heeft en recruitment nog wacht, heeft de kandidaat al ja gezegd tegen iemand anders. Je AE weet het niet. Je recruiter weet het wel, maar heeft geen plek om het te signaleren die de AE ook ziet.

Het omgekeerde bewijst het punt. [HubSpot Research](https://www.hubspot.com/state-of-marketing) ontdekte dat wanneer sales en customer success een gedeeld operationeel kader hebben, retentie met 36% stijgt en win rates met 38% klimmen. De les gaat niet specifiek over CS, het gaat over aangrenzendheid. Twee teams die hetzelfde klantrelatie bewerken, presteren radicaal beter als ze elkaar kunnen zien. Er is nog geen gepubliceerde benchmark voor sales plus recruitment alignment, omdat bijna niemand het heeft gemeten, maar het mechanisme is hetzelfde. Aangrenzendheid loont één keer, loont ook twee keer.

## De anatomie van een handoff-fout

Elk handoff-lek dat we bij een scale-up hebben nagetrokken, laat zich herleiden tot één van drie mechanismen.

Het eerste is **verouderd eigenaarschap**. Een lead of een kandidaat heeft een naam ernaast staan. Die naam is iemand die sindsdien naar een ander team is gegaan, op vakantie is, of zich stilletjes heeft teruggetrokken van het account. Het record is niet opzettelijk fout. Het is fout omdat niets in de stack ooit een refresh afdwong. Op een single-motion stack is dat pijnlijk. Op twee processen die elkaar blokkeren, is het vermenigvuldigd.

Het tweede is de **onzichtbare fase**. Een lead beweegt van "qualified" naar "discovery" in het CRM. De recruiter ziet het niet. Waarom ook? De lead is een sales-artefact. Maar hetzelfde account heeft ook een hiring manager die één van vier beslissers op de deal is. Wanneer sales het record verplaatst, weet recruitment niet dat de temperatuur zojuist verschoof. Een calibratie-call die deze week had kunnen plaatsvinden, vindt nu pas over drie weken plaats, nadat de fase al is vastgelopen.

Het derde, en het duurste, is het **cross-motion knelpunt**. Eén persoon, meestal een hiring manager of VP Engineering, is tegelijkertijd de rate-limit in twee verschillende pipelines. Het sales-team wacht op hen om headcount goed te keuren voordat ze scope kunnen toezeggen. Het recruitment-team wacht op hen om het aanbod te tekenen voordat een kandidaat accepteert. Elk team escaleert afzonderlijk. Elk team stapelt op de berg die diezelfde persoon moet afwerken. Als een van beide teams de wachtrij van de ander had gezien, hadden ze het gesprek gebatcht. Niemand zag het.

## Wat een gedeelde cockpit écht verandert

Eigenaarschap wordt één veld, niet twee. Dezelfde persoon, geregistreerd als eigenaar, draagt door naar beide processen voor de accounts waar het dezelfde persoon betreft. Fases worden leesbaar over teams heen. Een lead die naar "proposal" beweegt, markeert het recruitment-record voor hetzelfde bedrijf, omdat de rollen die voor dat account worden geworven zojuist tijdkritisch zijn geworden. Knelpunten verschijnen als knelpunten, niet als twee losstaande herplanningsverzoeken. De hiring manager ziet wat er van beide kanten openstaat in één overzicht en neemt één beslissing in plaats van twee keer te worden aangejaagd.

Dit is wat het betekent om twee pipelines in één grid te zetten, en het is de reden dat LeadGrid bestaat. Niet omdat sales-teams hun CRM beu zijn en recruitment-teams hun ATS beu zijn, hoewel beide waar zijn. Maar omdat de handoff die een scale-up breekt niet binnen een van beide tools zit, maar ertussen.

## De audit die je maandag uitvoert

Je hebt geen nieuw platform nodig om te beginnen. Je moet ontdekken waar jouw handoffs echt lekken. Een paar dingen om in de eerste week te proberen, met wat je al hebt.

Loop maandagochtend naar binnen en zet alle leads die vorige week vastliepen op een rij, samen met alle kandidaten die vorige week vastliepen. Zet ze in hetzelfde spreadsheet, gesorteerd op de benoemde persoon die ergens op wacht. Tel hoe vaak dezelfde persoon in beide kolommen voorkomt. Dat getal is je cross-motion knelpuntpercentage. Bij de meeste scale-ups waarmee we hebben gewerkt, ligt het tussen de 15 en 30 procent. Dat is 15 tot 30 procent van je vastlopers die geen sales-probleem zijn of een recruitment-probleem, het is een wachtrij-probleem.

Controleer daarna je eigenaarschapsvelden. Voor elk actief record in beide systemen, vraag je of de genoemde persoon de afgelopen vijf werkdagen op e-mail heeft gereageerd. Het percentage dat het haalt niet, is je verouderd-eigenaarschapspercentage. Alles boven de 20% betekent dat het record op het moment dat je het het hardst nodig hebt, tegen je liegt.

Kies tot slot één open account waarbij het bedrijf zowel een deal als een wervingsdoelwit is. Zet het sales-activiteitenlogboek en het recruitment-activiteitenlogboek naast elkaar. Merk elk moment op waarop het ene team het andere een dag had kunnen besparen. Die lijst is je handoff-deficit.

## De oplossing is één grid, geen grotere CRM

De reden dat omzet lekt op de naad tussen sales en recruitment is niet dat je CRM slecht is of je ATS verkeerd. Het is dat je proces één ding is en je stack twee. De oplossing is geen grotere CRM. Het is geen diepere ATS. Het is een grid dat beide pipelines toont met hetzelfde vocabulaire, hetzelfde eigenaarsveld en hetzelfde begrip van wat "vastgelopen" betekent. Geef ops-leiders één overzicht van het proces, en het proces stopt met mensen op de grond te laten vallen.

**[Gratis beginnen →](https://leadgrid.io/signup)**

---

# Waarom we LeadGrid bouwden als één API voor twee pipelines

URL: https://leadgrid.io/nl/blog/waarom-we-leadgrid-bouwden
Locale: nl
Published: 2026-04-14
Author: Ralf Klein
Tags: product, api

De meeste groeiteams draaien een CRM én een ATS voor dezelfde beweging. Dit is wat er instort als je sales en recruitment op één datamodel modelleert, en waarom we het standaard programmeerbaar maakten.

Elk groeiteam waar ik mee gewerkt heb, voert dezelfde beweging twee keer uit. Sales heeft een CRM. Recruitment heeft een ATS. Dezelfde pipelinevorm, intake, kwalificeren, doorschuiven, afsluiten, maar op twee stacks die niet met elkaar praten.

We bouwden LeadGrid omdat die splitsing een keuze is, geen vanzelfsprekendheid.

## Het datamodel is hetzelfde

Een lead en een kandidaat zijn allebei *mensen die door fases bewegen*. Geef ze een naam, een fase, een deadline, een eigenaar en een set notities, en je hebt allebei beschreven. De werkwoorden zijn identiek: aanmaken, toewijzen, doorsturen, becommentariëren, afsluiten.

De industrie bouwde twee productcategorieën hieromheen omdat het winstgevend was om dat te doen, niet omdat het onderliggende werk anders is. Teams betaalden uiteindelijk twee leveranciers, integreerden twee APIs, trainden op twee UIs en verzoenden twee waarheidsbronnen, om hetzelfde twee keer bij te houden.

## Wat instort als je alles samenvoegt

Eén platform draaien voor beide pipelines doet drie concrete dingen:

- **Overdrachten vallen niet meer weg.** Sales belooft levering. Recruitment vindt de mensen die leveren. Als beiden naar hetzelfde grid kijken, gebeuren escalaties voordat de kandidaat vertrekt of de deal wegglipt.
- **Toolingkosten halveren.** Één workspace, één factuurlijn, één permissiemodel. Sales en recruitment houden op te vechten over welke tool de waarheidsbron is, het is dezelfde.
- **Rapportage wordt eerlijk.** Time-to-hire en time-to-close leven in dezelfde database. Je kunt eindelijk de vraag beantwoorden "misten we deze deal omdat we de juiste persoon niet hadden?" zonder een spreadsheet.

## API-first, niet API-als-nagedachte

De andere bewuste keuze: elke actie die de UI uitvoert, is een REST-aanroep. Een dossier aanmaken, een fase verplaatsen, een notitie toevoegen, een lid toewijzen, allemaal scriptbaar, allemaal gedocumenteerd op [`/docs/api`](/docs/api).

Dat klinkt als minimumvereiste, en dat zou het ook moeten zijn, maar de meeste CRMs houden hun beste features achter voor een hogere tier, wikkelen de API in rate limits die je richting professional services duwen, of weigeren webhooks te documenteren. Wij wilden het tegenovergestelde: de API is het product, de UI is een handige manier om het te gebruiken.

De praktische consequentie: je automatiseringen trekken zich niets aan van of iets een lead of een kandidaat is. Je schrijft één integratie één keer, en die werkt over beide pipelines. Claude, n8n, Zapier, je eigen backend, dezelfde endpoint-structuur, dezelfde auth, hetzelfde webhook-schema.

## Gratis voor altijd op het gratis plan

Nog één ding. LeadGrid is gratis voor altijd op het gratis plan, geen proefperiode van 14 dagen, geen tijdelijke actie. Je kunt er een echt team op draaien, echte pipelines bouwen en ons nooit een cent betalen. Betaalde plannen ontgrendelen meer seats, actieve dossiers, flows en API-doorvoer als je de gratis limieten ontgroeit.

We hebben liever dat je op het platform aan het bouwen bent dan dat je naar een aftelklok staart.

[Gratis starten →](/signup)

---

## DE posts

# Lead Scoring ohne ML: warum eine Scorecard mit fünf Regeln für die meisten Teams gewinnt

URL: https://leadgrid.io/de/blog/lead-scoring-ohne-ml-fuenf-regeln-scorecard
Locale: de
Published: 2026-05-13
Author: Ralf Klein
Tags: sales, guides

Die meisten Teams, die Machine-Learning-Lead-Scoring einführen, bekämen 80% des Nutzens aus einer Scorecard mit fünf Regeln. Wann upgraden, und wann nicht.

Jedes Quartal kommt wieder ein Sales-Team und sagt, es brauche AI Lead Scoring. Wir graben nach, und was sie eigentlich brauchen ist eine saubere Scorecard mit fünf Regeln, negativen Gewichten und einer Decay-Funktion. Das ML-Modell ist die Schlagzeile, der Hebel sitzt aber in der Basis, die fast niemand zuerst aufgesetzt hat.

Das ist keine gegenläufige Meinung. Genau das findest du am Ende jedes ehrlichen ML-Leitfadens. Das Problem ist, dass die Rules-Version langweilig klingt, also überspringen Teams sie und zahlen für ein Modell, das aus dreckigen Daten das Falsche lernt.

## Das mathematische Problem, das die meisten Teams zuerst haben

Ein prädiktives Modell braucht genug Closed-Won- und Closed-Lost-Beispiele, aus denen es lernen kann. Die meisten B2B-Teams haben dieses Volumen schlicht noch nicht. Laut [Prospeo guide on AI versus traditional lead scoring](https://prospeo.io/s/ai-lead-scoring-vs-traditional-lead-scoring) liegt die praktische Untergrenze bei etwa 1.000 Leads pro Jahr, 100 abgeschlossenen Deals und 12 bis 24 Monaten sauberer CRM-Daten, bevor ein ML-Modell einen verteidigbaren Score liefert. Darunter schlägt ein gut gebautes regelbasiertes Modell jedes Mal ein schlecht trainiertes AI-Modell.

Das ist der Teil, den Vendor-Decks weglassen. Ein Modell, das auf 60 Conversions und einem Jahr inkonsistenter Phasen-Definitionen trainiert wurde, lernt nicht deinen Käufer, es lernt dein Datenhygiene-Problem.

## Warum die Rules-Version meistens gewinnt

Forrester ist da seit Jahren deutlich. Das [Forrester piece on what lead scoring actually is](https://www.forrester.com/blogs/what-is-lead-scoring-anyway/) bringt es auf den Punkt: Die meisten produktiven Scoring-Modelle basieren auf Annahmen und zufälligen Schätzungen der Kaufneigung, nicht auf echter Analyse. Das durch ein ML-Modell zu ersetzen, das auf denselben wackligen Inputs trainiert wurde, repariert die Inputs nicht, es macht den Score nur schwerer angreifbar.

Eine einfache Scorecard ist auditierbar, schnell zu ändern und zwingt Sales und Marketing dazu, sich auf eine Definition von "qualified" zu einigen, bevor sie sie ausliefern. Aus diesem Alignment kommt der meiste echte Hebel. Die [Clueless Company breakdown of failing lead scoring models](https://www.theclueless.company/lead-scoring-techniques/) bringt es gut auf den Punkt: Der häufigste Grund, warum Scoring-Projekte scheitern, ist nicht schlechte Logik, es ist, dass Sales dem Score nicht traut, also arbeiten die Reps weiter mit denen, mit denen sie sowieso schon gearbeitet haben.

Vertrauen in eine Black Box lässt sich nicht aufbauen. Vertrauen in fünf Regeln, die du von einem Whiteboard ablesen kannst, schon.

## Die Scorecard mit fünf Regeln

Hier ist die Version, die wir jedem LeadGrid-Kunden unter der ML-Schwelle empfehlen. Sie passt auf einen Bildschirm und erklärt sich selbst.

```yaml
fit_score:
  icp_company_size:    { match: +20, miss: -15 }
  icp_industry:        { match: +15, miss: -10 }
  decision_maker_role: { match: +20, miss: -10 }

intent_score:
  pricing_page_visit:  +20
  demo_request:        +30
  three_emails_opened: +5
  inactivity_per_week: -5

threshold_for_sales_handoff: 50
```

Fünf Regeln, zwei negative Gewichte, eine Decay-Regel. Das war's. Die Struktur ist aus dem [Reform guide on common lead scoring mistakes](https://www.reform.app/blog/common-lead-scoring-mistakes-and-fixes) übernommen, der die zwei Failure-Modes klar benennt, die eine Basis-Scorecard fixen muss: Zu viele Signale verfolgen erzeugt Rauschen, und nur positive Scores vergeben füllt das CRM mit kalten Leads, die niemand mehr rausnimmt.

Die Decay-Regel wiegt schwerer, als die Leute denken. Das [Breadcrumbs B2B lead scoring framework for 2026](https://breadcrumbs.io/blog/b2b-lead-scoring/) empfiehlt, für jede Woche Inaktivität Punkte abzuziehen, genau damit Zombie-MQLs nicht oben in der Warteschlange hängen, während ein heißerer Lead von heute Morgen darunter liegt. Ohne Decay ist deine Scorecard eine Highscore-Liste, keine Warteschlange.

## Wann auf ML wechseln

Es gibt eine echte Schwelle, an der ML-Scoring seine Komplexität verdient. Du hast sie überschritten, wenn drei Dinge gleichzeitig wahr sind.

Du hast mindestens 100 saubere Closed-Won- und 100 saubere Closed-Lost-Datensätze, mit konsistenten Phasen-Definitionen über diese gesamte Historie. Der [Landbase lead scoring statistics roundup](https://www.landbase.com/blog/lead-scoring-statistics) zitiert Forrester-Daten mit 38% höherer Conversion und 28% kürzeren Sales Cycles für Teams mit AI-Scoring, aber diese Zahlen stammen von Teams, die die Datenhygiene zum Trainieren hatten. Ohne diese Hygiene lernt das Modell dein chaotisches CRM, nicht deinen Käufer.

Dein Sales Cycle ist komplex genug, dass Menschen die Variablen nicht mehr im Kopf halten können. Multi-Stakeholder-Enterprise-Deals mit 18+ Touchpoints über sechs Monate sind ein anderes Problem als ein Self-Serve-SaaS-Funnel mit Free-Trial-Gate. ML rechtfertigt seine Kosten an der komplexen Form, nicht an der einfachen.

Du hast die regelbasierte Version bereits live und kannst exakt benennen, welche Regel das ML-Modell schlagen wird. Wenn du das nicht benennen kannst, löst das ML-Modell kein Problem, das du hast, sondern eines, das ein Vendor hat.

## Der ehrliche Hybrid

Das Muster, das funktioniert, ist regelbasiertes Scoring als Basisschicht und ML als Overlay obendrauf, sobald du die Daten hast, um das zu rechtfertigen. Die Regeln geben dir einen Score, dem Reps ab Tag eins trauen. Das ML-Overlay justiert den Score anhand von Mustern, die die Regeln nicht sehen, aber der menschenlesbare Score bleibt im UI.

Genau darauf zielt auch die [SiriusDecisions data on lead scoring adoption](https://salesdorado.com/en/sales-qualification/lead-scoring-useless/) ab: 68% der Unternehmen betrieben Lead Scoring, aber nur 40% der Vertriebler sahen einen Wert darin. Die Teams in den 40% hatten ein Modell, das die Reps erklären konnten. Die in den anderen 60% hatten eines, dem die Reps nicht glaubten.

Bau zuerst die Version mit fünf Regeln. Verdiene das ML-Upgrade, sobald deine Daten und dein Sales-Team bereit dafür sind. Die meisten Teams müssen diesen zweiten Schritt nie gehen, und das ist in Ordnung.

[Kostenlos starten →](https://leadgrid.io/signup)

---

# Das Bewerbungsvolumen-Problem für Recruiter: 93% mehr Bewerbungen, gleiche Headcount

URL: https://leadgrid.io/de/blog/bewerbungsvolumen-problem-recruiter
Locale: de
Published: 2026-04-29
Author: Ralf Klein
Tags: recruitment, guides

Recruiter bearbeiten 93% mehr Bewerbungen mit 14% kleineren Teams. Mehr Recruiter einstellen ist nicht die Lösung. Prozessumbau, der ohne Headcount skaliert.

Recruiting-Teams fahren 2021er Prozesse auf 2026er Volumen. Laut [Gem's 2026 Recruiting Benchmarks Report](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report) bearbeiten Recruiter heute 93% mehr Bewerbungen und 40% mehr offene Stellen als vor fünf Jahren, während Teams um 14% geschrumpft sind. Hires pro Recruiter sind um 43% gefallen. Die Rechnung geht nicht auf, und Headcount aufzustocken ist nicht die Lösung.

## Warum mehr Recruiter einzustellen nicht die Antwort ist

Das Volumen mit einem 14% kleineren Team zu verdoppeln, würde nahelegen, das Team zu verdoppeln. Drei Gründe, warum das scheitert.

Erstens genehmigt Finance keine 2x Recruiter-Hires, während Engineering-Organigramme flacher werden. Die Cost per Hire ist in den meisten Segmenten laut den [Gem 2026 Benchmarks](https://www.gem.com/resource/recruiting-benchmarks) bereits gestiegen. Seats hinzuzufügen macht es schlimmer, ohne die Conversion-Rate zu ändern.

Zweitens hat sich der Engpass verschoben. Die meisten Teams behandeln Volumen als Screening-Problem. Ist es nicht. Dieselben Gem-Daten zeigen, dass nur 0,5% der Bewerber eingestellt werden, was bedeutet, dass 99,5% der Recruiter-Zeit, die für Lebenslauf-Reviews aufgewendet wird, in der Summe verschwendet ist. Mehr Recruiter heißt mehr verschwendete Stunden, keine schnelleren Hires.

Drittens sind neue Bewerber gar nicht die Quelle mit der höchsten Conversion. Gem berichtet, dass 46% der sourced Hires inzwischen aus wiederentdeckten Kandidat(inn)en stammen, die bereits im CRM oder ATS liegen, gestiegen von 26% in 2021. Teams, die doppelt auf Inbound-Review setzen, optimieren den schwächsten Funnel, den sie haben.

## Wo die Zeit wirklich verloren geht

Mach ein einwöchiges Time Audit auf einem Inbound-lastigen Team. Das Muster wiederholt sich:

- **Lebenslauf-Review auf Parität.** Jeder Bewerber bekommt die gleiche erste Aufmerksamkeit, unabhängig von der Quelle. Ein LinkedIn Easy Apply bekommt dieselben 30 Sekunden wie ein Referral. Das ist die falsche Verteilung.
- **Keine Scoring-Stufen.** Teams ohne harte Auto-Disqualify-Regel und Fast-Track-Regel lesen jeden mittelmäßigen Lebenslauf vollständig.
- **Synchrone Screening-Calls.** Ein 20-Minuten-Telefonat für jede(n) "Vielleicht"-Kandidat(in) frisst den Tag der/des Recruiter(s), auch wenn 70% nicht weiterkommen.
- **Cold Sourcing während Inbound sich stapelt.** Bestehende CRM-Kandidat(inn)en zu durchforsten, bleibt der freien Zeit überlassen, die nie auftaucht.

Keines davon ist ein Headcount-Problem. Es sind Prozess- und Tooling-Probleme.

## Prozessbewegungen, die ohne Köpfe skalieren

**Wiederentdecken vor dem Sourcen.** [SmartRecruiters 2025 Recruitment Data](https://www.smartrecruiters.com/blog/recruitment-statistics-for-2025/) stützt Gems Befund, dass historische Pipelines zwei- bis dreimal höher konvertieren als Cold Sourcing. Bevor du eine Rolle veröffentlichst, durchsuche das CRM nach früheren Bewerber(inne)n, die zu einer ähnlichen Anforderung passen. Das ist eine Suche, nicht 200 Lebenslauf-Reviews.

**Stufe den Inbound-Funnel.** Bau drei Spuren: Auto-Disqualify auf harten Anforderungen, Fast-Track auf Score plus Referral oder Alumni-Status, manuelle Review für den Rest. Die Stufen-Regeln gehören ins Dossier, nicht in den Kopf der/des Recruiter(s). Die mittlere Spur ist es, wo Headcount teuer wirkt. Sie zu halbieren, indem du die Latte höher legst, kostet meist null Hires und macht eine ganze Recruiter-Woche pro Rolle frei.

**Async-Screen die Vielleicht-Kandidat(inn)en.** Ersetze den 20-Minuten-Call "bist du echt" durch eine schriftliche Async-Frage: drei Fragen, 48-Stunden-Fenster. Kandidat(inn)en, die nicht antworten, selektieren sich selbst aus. Wer antwortet, liefert eine schriftliche Spur, die Hiring Manager in 90 Sekunden lesen.

**Bring Automatisierung ins Dossier, nicht drumherum.** Wenn der Next-Step-Nudge, die Absage-Mail, der Scheduling-Link und der Hiring-Manager-Handoff alle im Kandidaten-Datensatz liegen, hören Recruiter auf, zwischen fünf Tools zu wechseln. Der [Cronofy Candidate Expectations Report 2024](https://www.cronofy.com/reports/candidate-expectations-report-2024) hat festgestellt, dass Kandidat(inn)en eine Antwort innerhalb von 48 Stunden erwarten, und dass Drop-Rates jenseits dieses Fensters in die Höhe schnellen. Tooling, das die nächste Aktion einen Klick entfernt hält, ist das, was 48 Stunden bei Volumen möglich macht.

## Was du statt Time-to-Hire messen solltest

Aggregierte Time-to-Hire ist zu grob, um ein Volumenproblem zu debuggen. Drei Metriken, die das Signal trennen:

- **Zeit-in-Phase pro Quelle.** Inbound-Bewerber, die 8 Tage im Screening hängen, während Referrals in 2 durchkommen, sagt dir, dass die Stufenregeln nicht stimmen, nicht dass der Funnel langsam ist.
- **Hire-Rate pro Spur.** Wenn deine manuelle Review-Spur auf 0,4% konvertiert und deine Fast-Track-Spur auf 12%, verdient die manuelle Spur ihre Recruiter-Zeit nicht.
- **Rediscovery Hit Rate.** Welcher Anteil der Hires kam aus Kandidat(inn)en, die bereits im System waren? Wenn er unter dem [Gem-Benchmark von 46%](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report) liegt, nutzt deine Sourcing-Bewegung ihre eigenen Daten nicht.

Jede davon ist ein Tag im Kandidaten-Dossier und eine Phase in der Pipeline. Keine erfordert ein neues Tool, und keine erfordert ein größeres Team.

## Der Rahmen

Das Volumenproblem ist kein Staffing-Problem. Es ist ein Prozess-Problem, das sich als Staffing-Problem tarnt. Teams, die die neue Basislinie akzeptieren (93% mehr Bewerbungen, 14% weniger Recruiter) und drumherum neu designen, liefern Hires in derselben Geschwindigkeit. Teams, die für mehr Headcount lobbyieren, verlieren das Budget-Gespräch und behalten den Engpass.

Bau das Dossier so, dass ein(e) Recruiter(in) eine(n) Kandidat(in) mit einem Klick bewegen kann. Stufe den Funnel, sodass 80% der Bewerber in 30 Sekunden entschieden sind. Durchforste das CRM vor dem Sourcen. Die Volumenzahl geht nicht runter, aber die Zeit pro Kandidat(in) kann es.

[Kostenlos starten →](https://leadgrid.io/signup)

---

# Warum Pipeline-Drop-off-Analyse für Vertrieb und Recruiting gleich funktioniert

URL: https://leadgrid.io/de/blog/pipeline-drop-off-analyse-funktioniert-gleich
Locale: de
Published: 2026-04-28
Author: Ralf Klein
Tags: pipeline, guides

Vertrieb und Recruiting wirken wie verschiedene Pipelines. Die Drop-off-Mathematik ist identisch. Gleiche Diagnosen, gleiche Fixes, nur andere Phasennamen.

Die meisten Teams behandeln Vertriebs-Drop-off und Recruiting-Drop-off als getrennte Probleme. Sie ziehen unterschiedliche Reports, stellen andere Fragen und holen sich andere Spezialisten, um jedes zu lösen. Diese Trennung ist meist kulturell. Die Mathematik ist identisch.

Eine Pipeline ist eine Abfolge von Phasen. Menschen treten oben ein, wandern Phase für Phase weiter und schließen entweder ab oder fallen heraus. Drop-off ist der Prozentsatz, der bei jedem Übergang herausfällt. Sobald Du diesen Rahmen akzeptierst, sind Vertrieb und Recruiting nicht länger verschiedene Probleme, sondern dasselbe Problem mit anderen Etiketten auf den Kästen.

## Die Funnel-Mathematik schert sich nicht darum, wie Du die Phasen nennst

Im Vertrieb sind die Standardphasen Lead, MQL, SQL, Opportunity, Closed Won. Im Recruiting sind es Bewerbung, Screening, Interview, Offer, Hire. Fünf Phasen je Pipeline. Vier Übergänge je Pipeline. Bei jedem Übergang geht ein Anteil weiter, ein anderer fällt aus.

Laut den [Glue Up 2026 sales funnel benchmarks](https://www.glueup.com/blog/sales-funnel-conversion-rate-benchmarks) konvertiert der typische B2B-Vertriebs-Funnel Lead zu MQL bei 25 bis 35%, MQL zu SQL bei 13 bis 26%, SQL zu Opportunity bei 50 bis 62%, und Opportunity zu Closed Deal bei 15 bis 30%. Multipliziert man das, kommt man auf eine End-to-End-Konversion von etwa 0,3% bis 1,6%.

Im Recruiting hat der [CareerPlug's 2025 Recruiting Metrics Report](https://www.careerplug.com/blog/recruiting-metrics-report/) über 10 Millionen Bewerbungen ausgewertet und festgestellt, dass etwa 3% der Bewerber ein Interview erreichen und unter 1% tatsächlich eingestellt werden. Gleiche Form. Gleiche Größenordnungen. Der größte Einzeleinbruch in beiden Funnels passiert im Qualifikationsschritt: MQL zu SQL im Vertrieb, Bewerbung zu Screening im Recruiting.

## Die diagnostischen Muster sind ebenfalls dieselben

Wenn der Vertriebs-Drop-off zwischen MQL und SQL ausschlägt, sind meist drei Dinge wahr: Lead-Volumen wuchs schneller als Rep-Kapazität, Qualifikationskriterien sind zwischen Marketing und Vertrieb nicht abgestimmt, oder die Reaktionszeit ist weggebrochen. Wenn der Recruiting-Drop-off zwischen Bewerbung und Screening ausschlägt, sind meist drei Dinge wahr: Bewerbungsvolumen wuchs schneller als Recruiter-Kapazität, Screening-Kriterien sind zwischen Hiring Manager und Recruiter nicht abgestimmt, oder die Reaktionszeit ist weggebrochen.

Lies die beiden Absätze nochmal. Dieselben drei Diagnosen. Der [Ashby 2025 Talent Trends Report](https://www.ashbyhq.com/resources) zeigt, dass Recruiting-Teams heute fast doppelt so viele Bewerbungen wie 2021 mit derselben Personaldecke bearbeiten, und das produziert genau den Bottleneck, den ein Vertriebsteam bekommt, wenn sich Leads verdreifachen, Reps aber gleich bleiben.

Die Fixes reimen sich auch. Im Vertrieb verschärfst Du Qualifikationskriterien, legst SLAs auf Reaktionszeit fest, oder investierst in Scoring vor dem Routing. Im Recruiting verschärfst Du Screening-Kriterien, legst SLAs auf Reaktionszeit fest, oder investierst in Pre-Screening vor der Recruiter-Sichtung. Das Verb lautet "filtere oder beschleunige". Dieses Verb funktioniert in beiden Pipelines.

## Wo die Analyse zerbricht (und warum)

Der Grund, warum die meisten Teams diese Symmetrie übersehen, ist, dass die Daten in verschiedenen Systemen liegen. CRM speichert die Vertriebs-Pipeline. ATS speichert die Recruiting-Pipeline. Reports werden pro System gebaut, von Leuten, die nur einen Funnel sehen. Wenn also Vertriebs-Drop-off und Recruiting-Drop-off durch dasselbe Grundproblem verursacht werden (das Unternehmen hat mehr Nachfrage hereingeholt als an Kapazität aufgebaut), sieht es niemand, weil niemand auf beide gleichzeitig schaut.

Eine [SHRM-Studie zur Candidate Experience](https://www.shrm.org/topics-tools/news/talent-acquisition) findet heraus, dass 60% der Kandidat(in)en Bewerbungen wegen Prozessreibung abbrechen. Exakt derselbe Prozentsatz B2B-Leads bricht Vertriebsgespräche aus demselben Grund ab: zu viele Schritte, zu langsam, zu unklar. Eine Zahl, eine Wurzelursache, zwei Reports, die niemand verbindet.

## Was eine vereinheitlichte Pipeline-Analyse freischaltet

Wenn Du dieselbe Drop-off-Abfrage gegen beide Funnels laufen lassen kannst, werden drei Dinge sichtbar, die vorher unsichtbar waren. Erstens: Kapazitäts-Bottlenecks bei geteilten Ressourcen, etwa einem Hiring Manager, der zugleich Deal-Sponsor ist, zeigen sich gleichzeitig in beiden Pipelines als Drop-off. Zweitens: Prozessverbesserungen kumulieren, ein SLA-Muster, das die Vertriebskonversion hebt, ist dasselbe SLA-Muster, das die Offer-Annahme hebt. Drittens: Du hörst auf, zwei Analytics-Teams einzustellen, um eine Frage zu beantworten.

Das ist der praktische Fall dafür, Vertrieb und Recruiting als ein Pipeline-Produkt zu behandeln, nicht zwei. Das Datenmodell ist gleich. Die Diagnosen sind gleich. Die Fixes sind gleich. Das einzige, was sich unterscheidet, ist das Etikett auf der Box.

[Kostenlos starten →](https://leadgrid.io/signup)

---

# Vier LeadGrid API-Integrationen, die dein Team wirklich nutzen wird

URL: https://leadgrid.io/de/blog/leadgrid-api-integrationen-die-dein-team-wirklich-nutzt
Locale: de
Published: 2026-04-25
Author: Ralf Klein
Tags: api, product, guides

LeadGrid macht jede Pipeline-Aktion als REST-Endpunkt verfügbar. Vier Integrationen, die Teams an einem Nachmittag bauen, mit echten Codebeispielen.

LeadGrid ist API-first entwickelt. Jede Aktion, die du in der UI durchführen kannst - ein Dossier erstellen, einen Lead durch eine Phase bewegen, eine Notiz hinzufügen, einen Inhaber(in) zuweisen - ist ein dokumentierter REST-Aufruf. Das ist eine Designentscheidung, kein Nebenmerkmal.

Laut dem [Postman 2025 State of the API Report](https://www.postman.com/state-of-api/2025/) haben 82% der Organisationen einen API-first-Ansatz übernommen. Teams, die auf ihrem Pipeline-Tool aufbauen statt darum herum zu arbeiten, hören auf, dieselbe manuelle Aufgabe zweimal pro Woche zu erledigen.

Hier sind vier Integrationen, die Teams tatsächlich bauen, mit dem dazugehörigen Code.

## 1. Webformular-Einsendung erstellt automatisch ein Dossier

Das ist die häufigste Integration. Du hast ein Kontaktformular, eine Landingpage oder einen Partner-Empfehlungslink. Jemand füllt es aus. Zurzeit kopiert jemand in deinem Team diese Daten manuell in LeadGrid. Das ist das Erste, was du abschaffen solltest.

Die LeadGrid API lässt dich `POST /dossiers` aufrufen, um einen neuen Datensatz in einer Pipeline zu erstellen. Ein einfacher Webhook-Empfänger in Node erledigt den Rest:

```ts
// Ausgelöst von deinem Formularanbieter (Typeform, Tally, eigenes Formular - egal)
app.post('/webhook/new-lead', async (req, res) => {
  const { name, email, company } = req.body;

  await fetch('https://api.leadgrid.io/v1/dossiers', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.LEADGRID_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      pipelineId: 'your-pipeline-id',
      title: `${name} - ${company}`,
      fields: { email, company },
    }),
  });

  res.sendStatus(200);
});
```

Neuer Lead drin. Kein Kopieren und Einfügen. Niemand vergisst es.

## 2. Phasenänderung sendet eine Slack-Benachrichtigung

Sales-Manager schauen in LeadGrid. Der Rest des Teams schaut in Slack. Wenn ein Deal in die "Verhandlung"-Phase wechselt oder ein Kandidat(in) das "Abschlussgespräch" erreicht, sollte dein Slack-Kanal das wissen, bevor jemand nachfragen muss.

LeadGrid-Webhooks ermöglichen das Abonnieren von `dossier.stage_changed`-Events. Wenn das ausgelöst wird, leitest du es an deinen Slack Incoming Webhook weiter:

```ts
app.post('/webhook/leadgrid-events', async (req, res) => {
  const { event, data } = req.body;

  if (event === 'dossier.stage_changed') {
    const { title, stage, pipelineId } = data;

    await fetch(process.env.SLACK_WEBHOOK_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        text: `Pipeline-Update: *${title}* ist jetzt in Phase *${stage}*`,
      }),
    });
  }

  res.sendStatus(200);
});
```

Dreißig Zeilen. Dein Team hört auf zu fragen: "Wo steht der Deal gerade?"

## 3. Abgeschlossener Deal schreibt einen Datensatz in dein HR- oder ERP-System

Wenn eine Recruitment-Vermittlung abgeschlossen ist oder ein Vertrag unterzeichnet wurde, muss dein Backoffice es wissen. Manuell aus LeadGrid exportieren und in deine HR-Plattform oder dein ERP importieren ist genau die Art von Arbeit, die donnerstagnachmittags zu Fehlern führt.

Abonniere `dossier.closed`-Events und sende die strukturierten Daten direkt weiter:

```ts
if (event === 'dossier.closed') {
  const { id, title, fields } = data;

  // Push an dein HR-System - ersetze durch die API deines Anbieters
  await fetch('https://api.your-hr-tool.com/employees', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.HR_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      name: fields.candidateName,
      email: fields.email,
      startDate: fields.startDate,
      role: fields.jobTitle,
    }),
  });
}
```

LeadGrid ist der Auslöser. Dein HR-System empfängt saubere, strukturierte Daten. Keine CSV weit und breit.

## 4. Nächtlicher Pipeline-Bericht in deinem Posteingang

Das Management möchte jeden Morgen einen Überblick. Was hat sich gestern bewegt? Was steckt fest? Was braucht Aufmerksamkeit?

Ein einfacher Cron-Job, der `GET /dossiers?filter=updated_since=yesterday` aufruft und das Ergebnis formatiert, deckt das vollständig ab:

```ts
// Jeden Morgen um 07:00 Uhr über Cron oder eine geplante Funktion ausführen
const yesterday = new Date(Date.now() - 86400000).toISOString();

const response = await fetch(
  `https://api.leadgrid.io/v1/dossiers?updated_since=${yesterday}`,
  { headers: { 'Authorization': `Bearer ${process.env.LEADGRID_API_KEY}` } }
);

const { dossiers } = await response.json();
const summary = dossiers.map(d => `- ${d.title}: ${d.stage}`).join('\n');

// Senden über Resend, Postmark oder einen anderen Transaktions-E-Mail-Anbieter
await sendEmail({
  to: 'team@yourcompany.com',
  subject: `Pipeline-Update - ${new Date().toLocaleDateString()}`,
  text: summary || 'Keine Änderungen seit gestern.',
});
```

Der [Postman 2025 State of the API Report](https://www.postman.com/state-of-api/2025/) stellte außerdem fest, dass 52% der Entwickler 2024 mit Breaking Changes externer Anbieter konfrontiert waren. LeadGrid pflegt versionierte Endpunkte (`/v1/`), damit deine Integrationen nicht still und leise an einem Dienstagmorgen kaputtgehen.

## Das Muster hinter allen vier

Jede dieser Integrationen folgt der gleichen Struktur: auf einen Trigger hören (Webhook oder Zeitplan), die LeadGrid API aufrufen, um Daten zu lesen oder zu schreiben, das Ergebnis woanders hinschicken. Die API-Oberfläche ist konsistent, per einzelnem Bearer-Token authentifiziert und gibt vorhersehbares JSON zurück.

Das ist, was API-first in der Praxis bedeutet. Du baust Workflows nicht *innerhalb* von LeadGrid. Du baust sie *darauf*.

Vollständige API-Referenz, Authentifizierungsdokumentation und Webhook-Event-Katalog findest du auf [leadgrid.io/docs](https://leadgrid.io/docs).

[Kostenlos starten →](https://leadgrid.io/signup)

---

# Warum dein Operations-Team in Panik gerät, wenn Sales gewinnt

URL: https://leadgrid.io/de/blog/warum-ops-in-panik-geraet-wenn-sales-gewinnt
Locale: de
Published: 2026-04-23
Author: Ralf Klein
Tags: sales, recruitment, pipeline

Wenn Leads sich stapeln und Recruiting hinterherhinkt, drückt Ops auf den Panikknopf. Meistens ist es eine Informationskrise, keine Kapazitätskrise. So erkennst du den Unterschied.

Es gibt einen bestimmten Moment, den jedes Unternehmen zwischen 30 und 60 Mitarbeitern erlebt. Sales schließt Deals. Die Pipeline ist voll. Das CRM leuchtet auf. Und irgendwo in einem Slack-Kanal oder einem Montagsmeeting sagt ein Ops-Lead: "Wir können gerade keine neuen Kunden annehmen."

Das Sales-Team ist verwirrt. Die Zahlen sehen gut aus. Das Ops-Team steht unter Druck. Beide haben recht, und beide sehen nur die halbe Wahrheit.

## Die Lücke zwischen Abschluss und Lieferung

Die meisten Unternehmen in dieser Phase betreiben zwei vollständig getrennte Pipelines. Sales verfolgt Leads durch ein CRM: Prospect, Demo, Angebot, Abschluss. Recruiting verfolgt Kandidaten durch ein ATS: Bewerbung, Screening, Interview, Einstellung. Dieselbe grundlegende Bewegung, verschiedene Tools, null gemeinsamer Kontext.

Das Problem ist nicht, dass diese Teams unterschiedlich schnell arbeiten. Das werden sie immer. Das Problem ist, dass niemand beide Pipelines gleichzeitig sehen kann.

Wenn Ops eine volle Sales-Pipeline sieht und nicht weiß, dass drei Engineers in den Abschlussrunden sind, gerät Ops in Panik. Wenn Sales ein schwaches Quartal sieht und nicht weiß, dass zwei neue Mitarbeitende noch im Onboarding sind, drückt Sales harder. Jede Entscheidung wird mit unvollständigen Informationen getroffen.

## Time-to-Hire ist länger als du denkst

[SHRM's Talent Acquisition Benchmarking Report](https://www.shrm.org/topics-tools/research/talent-acquisition-benchmarking-report) beziffert die durchschnittliche Time-to-Fill branchenübergreifend auf 36 bis 44 Tage. Für technische und spezialisierte Rollen bei wachsenden Unternehmen zeigen [Greenhouse's Hiring Benchmarks](https://www.greenhouse.com/guidance/hiring-benchmarks), dass die mediane Time-to-Hire eher in Richtung 47 Tage geht.

Das bedeutet: Der Mitarbeitende, den du brauchst, um den Deal dieser Woche zu liefern, hätte vor fünf bis sieben Wochen bereits gesourced werden müssen. Wenn du nur die Sales-Pipeline siehst, ist diese Lücke vollständig unsichtbar.

## Das Sichtbarkeitsproblem, nicht das Kapazitätsproblem

Folgendes passiert in der Praxis meistens: Ops hat recht, dass das Team ausgelastet ist. Aber die Ursache und der Fix sind falsch eingeschätzt.

Der Reflex ist, Sales zu bremsen. "Nehmen wir keine neuen Kunden an, bis wir eingestellt haben." Das klingt vernünftig. Aber wenn du sehen könntest, dass vier Kandidaten in den Abschlussrunden sind und wahrscheinlich innerhalb von drei Wochen anfangen, ändert sich die Rechnung komplett. Das Team ist jetzt ausgelastet. In einem Monat nicht mehr.

Die Frage ist nicht "bremsen wir Sales?" Die Frage ist: "In welcher Phase welcher Pipeline sitzt der eigentliche Engpass?" Diese Frage kannst du nicht beantworten, wenn du nur eine Pipeline siehst.

## Was sich ändert, wenn du beide gleichzeitig siehst

Wenn Sales- und Recruiting-Pipeline dieselbe Ansicht teilen, verschieben sich einige Dinge sofort.

**Timing-Entscheidungen verbessern sich.** Du siehst, dass du zehn Leads in der Angebotsphase und fünf Kandidaten in der Angebotsphase hast, und kannst eine fundierte Entscheidung treffen: beschleunigen, abwarten oder schneller einstellen.

**Forecasting wird ehrlich.** Kapazitätsplanung bei 30 bis 100 Mitarbeitenden ist überwiegend Bauchgefühl, weil die Daten in zwei Tools leben, die nicht miteinander sprechen. Eine gemeinsame Ansicht macht die Abhängigkeit sichtbar: Jeder abgeschlossene Deal braucht ein Liefer-Team, und dieses Team kommt aus einer Pipeline, die du parallel im Blick haben solltest.

**Panik nimmt ab.** Der meiste Stress, den Ops-Teams in dieser Phase erleben, ist keine Kapazitätskrise. Es ist eine Informationskrise. Wenn du sehen kannst, dass Recruiting nach Plan läuft, ist eine volle CRM keine Bedrohung mehr, sondern ein Ziel.

## Der Fix ist nicht noch eine Integration

Der naheliegende Schritt ist, dein ATS in dein CRM einzuspeisen oder umgekehrt. Das versuchen die meisten Teams zuerst. Das Ergebnis ist ein Durcheinander: nicht übereinstimmende Datenmodelle, Felder, die sich schlecht mappen lassen, Dashboards, die Zahlen zeigen, aber keinen Kontext.

Der sauberere Fix ist, beide Pipelines von Anfang an im selben Tool zu modellieren. Sales-Leads und Kandidaten sind beides Menschen, die Phasen durchlaufen. Gib ihnen einen Namen, eine Phase, eine Deadline, einen Inhaber, und du hast beide beschrieben. Der Unterschied liegt nur im Ergebnis: Abschluss versus Einstellung.

[Deloittes Global Human Capital Trends Forschung](https://www.deloitte.com/global/en/insights/focus/human-capital-trends.html) zeigt, dass Organisationen mit integrierten Talent- und Geschäftsplanungszyklen Personalentscheidungen deutlich schneller treffen als solche, die getrennt planen. Im Maßstab von 10 bis 100 Mitarbeitenden ist diese Geschwindigkeit kein Wettbewerbsvorteil. Es ist der Unterschied zwischen reibungslosem Wachstum und Panic-Hiring.

## Ops liegt nicht falsch mit seinen Sorgen

Das Bauchgefühl "das können wir nicht noch stemmen" stimmt oft im Kern. Teams zwischen 30 und 80 Mitarbeitenden laufen wirklich nahe an ihrer Kapazitätsgrenze. Das Problem ist nicht, dass Ops falsch liegt. Das Problem ist, dass sie eine Entscheidung ohne die nötigen Daten treffen.

Wenn die Recruiting-Pipeline neben der Sales-Pipeline sichtbar ist, ändert sich die Frage von "sollen wir bremsen?" zu "was muss erfüllt sein, damit wir hier Ja sagen können?" Das ist ein viel nützlicheres Gespräch.

[Kostenlos starten →](https://leadgrid.io/signup)

---

# Wie lange darf ein Kandidat im Talent Pool bleiben? Die DSGVO-Regeln erklärt

URL: https://leadgrid.io/de/blog/aufbewahrungsfrist-talent-pool-dsgvo
Locale: de
Published: 2026-04-22
Author: Ralf Klein
Tags: recruitment, guides

Abgelehnte Kandidaten, Beinahe-Treffer, zukünftige Fits: Wie lange darf man ihre Daten in einem Talent Pool unter der DSGVO rechtmäßig speichern?

Ein Kandidat hat sich beworben, kam bis in die Endrunde und hat die Stelle nicht bekommen. Du möchtest ihn für die nächste Vakanz im System behalten. Dieser Instinkt ist richtig. Die Umsetzung muss bewusst erfolgen, denn unter der DSGVO ist "jemanden auf der Liste zu behalten" eine Verarbeitungstätigkeit mit einer Rechtsgrundlage und einer Aufbewahrungsfrist.

Hier ist, was die Regeln tatsächlich sagen.

## Der Standard: vier Wochen nach der Ablehnung

Wenn ein Kandidat sich auf eine bestimmte Stelle bewirbt und Du ihn ablehnst, darfst Du seine Daten **vier Wochen** nach der Ablehnung aufbewahren. Dies deckt den Zeitraum ab, in dem der Kandidat möglicherweise Einspruch erheben oder Einsicht in sein Dossier beantragen könnte.

Nach diesen vier Wochen müssen die Daten gelöscht werden, wenn keine andere Rechtsgrundlage besteht.

Keine Einwilligung, keine aktive Pipeline, keine offene Stelle: löschen.

## Erweiterung auf einen Talent Pool: Du brauchst ausdrückliche Einwilligung

Einen Kandidaten länger, in einem Talent Pool, aufzubewahren, erfordert eine **ausdrückliche, informierte Einwilligung**. Keine implizite Einwilligung. Kein vorab angekreuztes Kästchen. Kein allgemeiner Satz, der in der Datenschutzerklärung vergraben ist.

Der Kandidat muss aktiv zustimmen:

- in einem Talent Pool aufgenommen zu werden
- für eine konkrete Aufbewahrungsfrist, die Du vorab nennst
- für einen Zweck, den Du klar beschreibst (zukünftige Stellen, kein allgemeines Marketing)

Gängige Praxis in Deutschland und in der gesamten EU ist ein **Maximum von einem Jahr** bei einer einzigen Einwilligung. Nach einem Jahr fragst Du entweder erneut nach der Einwilligung oder löschst das Dossier. Manche Organisationen setzen das Fenster auf zwei Jahre, was bei Funktionen mit langsamem Einstellungszyklus vertretbar ist, aber ein Jahr ist der sicherere Standard.

## Was die Einwilligungsanfrage enthalten muss

Eine DSGVO-konforme Talent Pool Opt-in-Anfrage hat drei Komponenten:

1. **Was Du speicherst.** Lebenslauf, Kontaktdaten, Gesprächsnotizen, Assessment-Ergebnisse. Sei konkret.
2. **Warum.** Zukünftige Vakanzen in Deiner Organisation, die zum Profil des Kandidaten passen.
3. **Wie lange.** Ein Jahr ab dem Datum der Einwilligung. Nicht "auf absehbare Zeit."

Füge einen klaren Opt-out-Mechanismus hinzu. Der Kandidat kann die Einwilligung jederzeit widerrufen, und der Widerruf muss genauso einfach sein wie die Einwilligung.

Wenn Du ein Recruitment-Tool oder ATS verwendest, prüfe, ob es Einwilligungs-Zeitstempel protokolliert und automatische Löschungserinnerungen sendet, wenn die Aufbewahrungsfrist abläuft. Manuelle Nachverfolgung in einer Tabelle ist ein Compliance-Risiko in jeder Größenordnung.

## Beinahe-Treffer und Talent Pools in der Praxis

Die Talent Pool-Regel gilt gleichermaßen für:

- Kandidaten, die direkt abgelehnt wurden
- Kandidaten, die gut gepasst haben, aber gegen einen stärkeren Bewerber verloren haben
- Kandidaten, die ihre Bewerbung mitten im Prozess zurückgezogen haben

Die Rechtsgrundlage ändert sich nicht danach, wie nah sie dran waren. Wenn sie nicht mehr in einem aktiven Prozess sind, brauchst Du eine Einwilligung oder löschst.

Eine Nuance: Wenn der Kandidat eine **offene Bewerbung** ohne spezifische Stelle eingereicht hat, ist die implizite Erwartung, dass Du sie für zukünftige Überlegungen speicherst. Das allein stellt keine gültige DSGVO-Einwilligung dar, erleichtert aber das Opt-in-Gespräch.

## Die Position der Datenschutzbehörden

Die deutschen und europäischen Datenschutzbehörden haben Leitlinien veröffentlicht, die bestätigen, dass die Talent Pool-Speicherung eine ausdrückliche Einwilligung erfordert, und empfehlen eine maximale Aufbewahrungsfrist von **einem Jahr**. Organisationen wurden aktiv für die Aufbewahrung von Kandidatendaten ohne gültige Rechtsgrundlage mit Bußgeldern belegt.

Wenn Du über EU-Grenzen hinaus tätig bist, sind die Regeln einheitlich. Die DSGVO gilt einheitlich. Nationale Behörden können sich in der Durchsetzung leicht unterscheiden, aber die Einwilligungs- und Aufbewahrungsanforderungen sind dieselben.

## Was Du in Deinen Prozess einbauen musst

Drei praktische Schritte, die die meisten Compliance-Risiken eliminieren:

**Bei der Ablehnung:** Sende eine einzige, klare E-Mail, in der Du fragst, ob der Kandidat Deinem Talent Pool beitreten möchte. Erkläre, was das bedeutet, wie lange seine Daten aufbewahrt werden, und biete ein One-Click Opt-in an.

**Bei der Einwilligung:** Protokolliere das Datum und was zugestimmt wurde. Dein ATS oder CRM sollte das automatisch erledigen. Wenn nicht, ist das ein Tooling-Problem, das sich zu lösen lohnt.

**Bei Ablauf:** Automatische Erinnerung, wenn das Einwilligungsfenster abläuft. Entweder erneut um Einwilligung bitten oder einen Löschungsworkflow auslösen.

Das ist nicht komplex zu implementieren. Es ist leicht zu übersehen. Das Übersehen ist, was die Compliance-Exposition erzeugt.

## Die Kurzversion

Abgelehnter Kandidat, keine Einwilligung: nach vier Wochen löschen. Talent Pool mit Einwilligung: bis zu einem Jahr, dann erneut fragen oder löschen. Alles protokollieren. Opt-out muss einfach sein.

Das ist die ganze Regel. Der Rest ist Implementierung.

---

# ATS oder CRM? Personalvermittlungen stellen die falsche Frage

URL: https://leadgrid.io/de/blog/ats-vs-crm-fuer-personalvermittlungen
Locale: de
Published: 2026-04-21
Author: Ralf Klein
Tags: recruitment, guides, pipeline

Die meisten Personalvermittlungen zermartern sich den Kopf über ATS vs CRM – und kaufen am Ende beides. Warum die Frage selbst das Problem ist und wie ein schlankerer Stack aussieht.

Dein bester Kandidat dieser Woche steckt im ATS. Dein heißester Kunde steckt im CRM. Am Donnerstag ruft der Kunde an und sucht genau dieses Profil. Du kopierst Notizen zwischen zwei Tabs, schickst ein Follow-up und hoffst, dass nichts verloren geht. Am Freitag nimmt der Kandidat ein Angebot woanders an, weil deine Antwort zwei Tage auf sich warten ließ.

Das ist das ATS-vs-CRM-Problem in 15 Sekunden. Zwei Tools. Zwei Tabs. Eine Lücke.

## Zwei Tools, gebaut für zwei verschiedene Teams

Das ATS wurde für interne HR-Teams entwickelt, die große Bewerbungsvolumina verwalten. Es führt Bewerbungen durch Stages, speichert Lebensläufe und trackt die Time-to-Hire. Das CRM wurde für Salesteams entwickelt, die Kundenbeziehungen pflegen. Es protokolliert Gespräche, erinnert an Follow-ups und verfolgt Deal-Stages.

Keins von beiden wurde für die Person gebaut, die beide Bewegungen gleichzeitig ausführt: den Recruiter in einer zwölfköpfigen Personalvermittlung, der den richtigen Kandidaten mit der richtigen offenen Stelle beim Kunden zusammenbringen muss, bevor beiden Seiten das Interesse erlischt. Wenn du ein ATS an ein CRM anflanscht oder beide parallel betreibst, zahlst du den Overhead zweier Systeme – ohne die Klarheit auch nur eines davon.

## Der Stack wird schwerer, während die Teams kleiner werden

[Gem's 2026 Recruiting Benchmarks Report](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report), der über 165 Millionen Bewerbende erfasste, stellte fest, dass Recruiting-Teams heute 93 % mehr Bewerbungen bearbeiten als 2021, während die Teamgröße um 14 % geschrumpft ist. Teams sollen schneller laufen auf einer Strecke, die länger geworden ist.

Ein zweites System auf diese Arbeitslast zu packen ist die falsche Antwort. Jede manuelle Synchronisierung zwischen ATS und CRM ist Zeit, die ein Recruiter nicht mit dem Kandidaten oder dem Kunden verbringt. Jeder Kontextwechsel zwischen Dashboards ist ein Moment, in dem etwas durch die Maschen fällt.

## Wie „durch die Maschen fallen" in der Praxis aussieht

Der [iHire 2025 State of Online Recruiting Report](https://www.ihire.com/about-us/press-room/articles/2025/ihire-releases-2025-state-of-online-recruiting-survey-results) fand heraus, dass 59 % der Jobsuchenden Ghosting durch Arbeitgeber als ihre größte Frustration im Bewerbungsprozess nannten. Ghosting ist selten absichtlich. Es passiert, wenn ein Recruiter den Überblick über einen Kandidaten verliert, weil seine Daten in einem anderen System liegen als das Kundengespräch.

Auf der Kundenseite zeigt sich dieselbe Lücke anders. Ein Lead erkaltet – nicht weil es keinen passenden Kandidaten gab, sondern weil der Recruiter mit dem Kopf im ATS steckte, als der Kunde still wurde, ohne gemeinsamen Überblick über den aktuellen Stand.

[SmartRecruiters' 2025 recruitment statistics](https://www.smartrecruiters.com/blog/recruitment-statistics-for-2025/) beziffern das: 22 % der Talent-Teams berichten, dass sie Schwierigkeiten haben, Bewerbende durch ihren eigenen Einstellungsprozess zu tracken. Das ist kein Recruiter-Problem. Das ist ein Tool-Problem.

## Die praktische Schlussfolgerung

Bevor du den nächsten Jahresvertrag unterschreibst, geh deine letzten fünf Placements durch und finde heraus, wo jeder Kandidat länger als 48 Stunden ohne Kontaktpunkt lag. Bei den meisten Agenturen tritt diese Verzögerung an zwei konkreten Momenten auf: direkt nach dem ersten Gespräch, wenn der Kandidat vom ATS in „E-Mail an den Kunden" wechselt, und direkt nachdem ein Kunde Interesse signalisiert, wenn der Recruiter zurück ins ATS springt, um Kandidatendetails zu holen.

Das sind die Übergabepunkte. Dort leckt deine Pipeline. Das Problem im Tool zu beheben geht schneller als die Lücke durch Training zu umgehen.

## Ein Grid für beide Bewegungen

LeadGrid ist kein ATS. Es ist kein CRM. Das ist der Punkt.

Es legt Kandidaten und Kunden in dieselbe Pipeline-Grid, mit derselben Stage-Logik, demselben Ownership-Modell und derselben Transparenz. Wenn ein Kunde eine Stelle öffnet, siehst du sofort, welche Kandidaten bereits auf der richtigen Stage sind. Wenn ein Kandidat vorankommt, ist der relevante Kundenkontext einen Klick entfernt. Kein zweiter Tab zum Wechseln, keine manuelle Synchronisierung.

Teams von 5 bis 50 Personen, die an Salesforce, HubSpot, Greenhouse oder Lever gescheitert sind, stellen oft fest, dass sie keine bessere Version eines dieser Tools brauchten. Sie brauchten ein Grid, das beide Bewegungen abbildet – ohne den Overhead von zwei Stacks.

**[Kostenlos starten →](https://leadgrid.io/signup)**

---

# Die Hälfte deiner Pipeline bricht weg, bevor du es merkst

URL: https://leadgrid.io/de/blog/halbe-pipeline-bricht-weg-bevor-du-es-merkst
Locale: de
Published: 2026-04-20
Author: Ralf Klein
Tags: recruitment, pipeline

47 % der Kandidaten nennen mangelnde Kommunikation als Grund für ihren Rückzug. Das Leck sitzt nicht oben im Funnel. Es steckt in der Übergabe.

Ein starker Kandidat absolviert zwei Gesprächsrunden. Die Hiring Managerin ist begeistert. Der Recruiter ist bereit voranzugehen. Dann vergeht eine Woche. Dann zwei. Niemand hat eine Rückmeldung geschickt. Der Kandidat geht davon aus, dass er ignoriert wurde, und nimmt woanders ein Angebot an.

Das ist kein Einzelfall. [Laut dem 2025 Ghosting Index von The Interview Guys](https://blog.theinterviewguys.com/the-2025-ghosting-index/) **wurden 61 % der Jobsuchenden nach einem Vorstellungsgespräch geghostet**, ein Anstieg von neun Prozentpunkten seit Anfang 2024. Die Zahl steigt weiter, und nicht weil Kandidaten weniger engagiert sind. Sondern weil die einstellenden Teams keine Follow-ups schicken.

Das Leck sitzt nicht oben im Funnel.

## Der Verlust passiert nach dem Interesse

Die meisten Recruiting-Teams konzentrieren sich auf Sourcing. Sie optimieren Stellenanzeigen, schalten LinkedIn-Kampagnen und verfeinern Bewerbungsformulare. Dabei sitzt der größte Abbruch weiter unten in der Pipeline, in Stages, in denen der Kandidat bereits sein Interesse signalisiert hat.

Eine Studie von [The HT Group](https://www.thehtgroup.com/how-to-fix-top-candidate-drop-off-in-the-hiring-process/) zeigt es genau: Die Interview-Stage allein verantwortet fast ein Drittel aller Kandidatenabbrüche, die Planungsphase fügt weitere 20 % hinzu. Das bedeutet: Mehr als die Hälfte aller Kandidaten, die du mühsam gewonnen hast, springt ab, nachdem sie bereits engagiert waren. Sie wollten die Stelle. Sie haben sich gezeigt. Dann hat der Prozess sie verloren.

Besseres Sourcing löst das nicht. Eine schnellere Übergabe schon.

## Schlechte Kommunikation ist der genannte Grund, keine Vermutung

Wenn Kandidaten abspringen, sagen sie warum. [Der Cronofy Candidate Expectations Report 2024](https://www.cronofy.com/reports/candidate-expectations-report-2024) ergab, dass **47 % der Kandidaten mangelnde Kommunikation als Grund für ihren Rückzug** aus einem Recruiting-Prozess angeben. Nicht das Gehalt. Nicht den Arbeitsweg. Nicht ein konkurrierendes Angebot. Kommunikation.

Der Mechanismus ist klar. Ein Recruiter beendet das Screening-Gespräch und leitet den Kandidaten weiter. Der Hiring Manager erhält die Übergabe, hat aber gerade sechs weitere offene Stellen, ein Sprint-Review und eine Board-Präsentation diese Woche. Der Kandidat wartet. Nach sieben Tagen Stille gehen 34 % davon aus, dass sie bereits abgelehnt wurden, und hören auf zu antworten.

Das ist der schmerzhafte Teil: Der Kandidat hatte nicht weniger Interesse. Der Prozess hat den Kandidaten verloren. Und wenn jemand bemerkt, dass der Datensatz seit zehn Tagen in derselben Stage steckt, hat der Kandidat längst eine neue Stelle angetreten.

## Bei der Übergabe bricht die Verantwortung weg

In den meisten Scale-ups verantwortet der Recruiter die Pipeline, bis ein Interview geplant ist. Dann geht die Verantwortung, informell, auf den Hiring Manager über. Ohne explizite Übergabe. Ohne Zeitstempel. Ohne sichtbaren nächsten Schritt. Beide gehen davon aus, dass der andere es regelt.

Die Angebotsannahmequote erzählt die ganze Geschichte. [CareerPlugs 2025 Candidate Experience Statistics](https://www.careerplug.com/candidate-experience-statistics/) zeigen, dass die Angebotsannahmequote im Q2 2025 auf 51 % gesunken ist, von 74 % noch zwei Jahre zuvor. Teams erreichen die Angebotsphase und verlieren den Kandidaten trotzdem. Das ist kein Sourcing-Problem oder Vergütungsproblem. Das ist ein Sichtbarkeitsproblem.

Wenn niemand sehen kann, wer für den nächsten Schritt verantwortlich ist, passiert der nächste Schritt nicht.

## Prüfe die Stage, in der die Verantwortung wechselt

Schau dir deine Pipeline an und finde die Stage mit dem ältesten Zeitstempel der letzten Aktivität. Das ist fast immer die Übergabe vom Recruiter zum Hiring Manager. Mach denselben Check jetzt für jede aktive Stelle, nicht nur die, um die du dir gerade Sorgen machst.

Das Muster ist in allen Teams gleich: Die Pipeline leckt am stärksten dort, wo Verantwortung angenommen statt zugewiesen wird. Ein Kandidat, der elf Tage in „Interview geplant" steckt, hat ein Verantwortungsproblem, kein Kandidatenproblem. Die Lösung beginnt damit, das sichtbar zu machen.

Markiere jeden Datensatz, bei dem die letzte Aktivität mehr als fünf Werktage zurückliegt und die Verantwortung unklar ist. Du wirst deine Abbruchstelle finden. Sie wird nicht zufällig sein. Sie häuft sich immer an derselben Stage, aus demselben Grund.

## Die Kandidaten ghosten dich nicht. Die Übergabe tut es.

Recruiting in einer Tabelle zu führen, während der Hiring Manager Notizen per E-Mail trackt, ist keine Workflow-Lücke. Es ist eine strukturelle Garantie dafür, dass etwas durchfällt. Niemand hat Sicht auf beides, also bemerkt niemand die Stille, bevor eine Einstellung verloren geht.

LeadGrid bündelt Kandidaten in einem einzigen Cockpit mit expliziter Stage-Verantwortung und einem sichtbaren Letzte-Aktivität-Marker für jeden Datensatz. Wenn ein Kandidat zu lange ohne nächsten Schritt wartet, ist das für alle sichtbar, die es sehen müssen, nicht in jemandem Posteingang vergraben oder in einem vergessenen Tab versteckt.

**[Kostenlos starten →](https://leadgrid.io/signup)**

---

# Fünf Dinge, die du automatisierst, wenn jede Pipeline-Aktion ein REST-Call ist

URL: https://leadgrid.io/de/blog/pipeline-automatisieren-mit-rest-api
Locale: de
Published: 2026-04-18
Author: Ralf Klein
Tags: api, engineering

LeadGrid stellt jede UI-Aktion über eine dokumentierte REST API bereit. Hier sind fünf Automatisierungen, die du an einem Nachmittag live schalten kannst, ohne einen einzigen CSV-Export.

Jede LeadGrid UI-Aktion, ein Dossier anlegen, eine Phase verschieben, eine Notiz hinzufügen, ein Mitglied zuweisen, ist ein dokumentierter REST-Call. Das ist kein Feature; das ist die Grundstruktur des Produkts. Es bedeutet, dass die Grenze zwischen „was LeadGrid tut" und „was dein eigener Code tut" schlicht ein HTTP-Request ist.

Hier sind fünf Automatisierungen, die weniger als einen Nachmittag kosten, sobald du dein CRM nicht mehr als etwas betrachtest, auf das man klickt.

## 1. Dossiers automatisch aus eingehenden E-Mails erstellen

Jeder Workspace erhält eine Inbound-Adresse. Leite einen Lead oder einen Lebenslauf dorthin weiter, LeadGrid parst Absender und Anhang, erstellt ein strukturiertes Dossier und feuert einen Webhook an deine Automatisierungsschicht.

Kein manuelles Durchforsten eines gemeinsamen Postfachs. Kein CSV-Upload. Dein AE leitet eine Kundenvorstellung weiter, und wenn er das Grid neu lädt, ist das Dossier bereits zugewiesen, getaggt und in der richtigen Pipeline.

## 2. Phase-basierte Slack-Benachrichtigungen mit Kontext

`dossier.stage_changed` Webhook → deine Funktion → Slack-Nachricht. Der Body enthält Dossiername, alte Phase, neue Phase, Verantwortliche(n) und Deadline. Du schreibst den Filter: `if new_stage == "Interview" and dossier.type == "candidate"` → `#recruitment-live`. Sales-Deals folgen einem anderen Kanal und einer anderen Schwelle.

Du konfigurierst keine Benachrichtigungen in einer Vendor-UI um. Du formulierst eine Regel im Code, versioniert zusammen mit dem Rest deiner Infra.

## 3. Deadline-Eskalationen, die wirklich eskalieren

LeadGrid hat eingebaute Deadlines. Der Unterschied ist, dass du `dossier.deadline_missed` abonnieren und so reagieren kannst, wie *dein* Team arbeitet: den Manager des Verantwortlichen anpingen, im Eskalationskanal posten, ein Linear-Ticket öffnen oder eine Kalendererinnerung 24 Stunden vorher auslösen.

Die API lässt dich Eskalationen aus Diensten zusammenstellen, die du bereits verwendest. Kein neues Dashboard, das du im Blick behalten musst.

## 4. Dein Data Warehouse aktuell halten, ohne ETL

Jedes Dossier-Event, erstellt, verschoben, geschlossen, kommentiert, steht als Webhook zur Verfügung. Leite sie in eine Queue, schreib sie in dein Warehouse, und deine BI-Schicht ist in Sekunden auf dem neuesten Stand statt 24 Stunden hinter einem nächtlichen Sync herzuhinken.

```ts
// pseudo-handler
app.post("/webhooks/leadgrid", async (req) => {
  const sig = req.headers["x-leadgrid-signature"];
  verify(sig, req.rawBody);            // HMAC, dokumentiert
  await queue.publish("leadgrid", req.body);
  return { ok: true };
});
```

Keine ETL-Pipeline, kein geplanter Job, kein „oh, der Sync ist schon wieder kaputt." Die Quelle der Wahrheit pusht, dein Warehouse hört zu.

## 5. Agents, die Pipelines eigenständig vorantreiben

Hier wird es spannend. Weil jede Aktion ein REST-Call mit einer sauberen OpenAPI-Spec ist, kann ein LLM LeadGrid steuern. Ein Claude- oder GPT-Agent kann:

- Den Lebenslauf eines Kandidaten aus dem Storage lesen
- Eine KI-Zusammenfassung schreiben und als Notiz posten
- Das Dossier in die nächste Phase verschieben, wenn die Zusammenfassung zur Stelle passt
- Dem Kandidaten einen strukturierten nächsten Schritt per E-Mail senden, über die Absender-Domain des Workspace

Das erfordert kein Scraping. Der Agent ruft `POST /v1/dossiers/<id>/notes` auf, genau so wie ein Mensch auf „Notiz hinzufügen" klickt.

Wir verkaufen kein geschlossenes KI-Feature auf einem geschlossenen CRM. Wir verkaufen eine programmierbare Pipeline, und du entscheidest, welche dieser Schleifen mit Menschen laufen, welche mit Automatisierung und welche mit Agents.

## Der eigentliche Punkt

Jedes CRM kann eine CSV liefern. Nur sehr wenige sind so konzipiert, dass die gesamte Oberfläche so aufrufbar ist wie eine Bibliothek. LeadGrid schon. Lies die Spec unter [`/docs/api`](/docs/api), hole dir einen API-Schlüssel aus deinen Workspace-Einstellungen und bringe deine erste Automatisierung an einem Nachmittag live.

[Kostenlos starten →](/signup)

---

# Zwei Pipelines, ein Engpass

URL: https://leadgrid.io/de/blog/zwei-pipelines-ein-engpass
Locale: de
Published: 2026-04-16
Author: Ralf Klein
Tags: pipeline, sales, recruitment

Die meisten Scale-ups betreiben Sales und Recruiting auf zwei Stacks, die nie miteinander reden. Ein einziger Hiring Manager ist gleichzeitig der Engpass in beiden Pipelines.

An einem Freitagmittag bei fast jedem Scale-up, mit dem wir arbeiten, scheitern zwei Dinge gleichzeitig im selben Gebäude, und niemand merkt, dass es eigentlich dasselbe Problem ist. Ein starker Enterprise-Lead geht verloren, weil der AE darauf wartet, dass der Hiring Manager die Kapazität bestätigt, bevor er sich auf eine Deadline festlegt. Zwei Etagen tiefer fällt ein Senior-Engineer, den die Recruiterin drei Wochen lang gepflegt hat, in die Funkstille, weil genau dieser Hiring Manager den Kalibrierungsanruf noch nicht zurückgegeben hat. Der Lead leckt. Der Kandidat kühlt ab. Montagmorgen berichtet jedes Team den Verlust im eigenen Standup, auf dem eigenen Board, mit der eigenen Erklärung.

Das sind keine zwei getrennten Probleme. Es ist ein Problem, zweimal gesehen, von Teams, die sich gegenseitig nicht sehen können.

## Die Form ist identisch, die Stacks nicht

Jeder Scale-up ab einer gewissen Größe betreibt zwei Prozesse, die auf dem Papier gleich aussehen. Sales hat Leads, die von Qualified über Discovery und Proposal bis zum Close wandern. Recruiting hat Kandidat(inn)en, die von Sourced über Screen und Interview bis zum Offer laufen. Gleiche Pipeline-Form, gleiche Phasen dem Wesen nach, gleiches Ownership-Modell, dasselbe Konzept von Last-Touch und Next-Touch. Den einen auf HubSpot oder Pipedrive einrichten, den anderen auf Greenhouse oder Workable, und schon hat man zwei Prozesse, die sich nie sehen. Die Personen, die den einen blockieren, blockieren oft auch den anderen. Der Kontext, der in dem einen relevant ist, ist es auch im anderen. Kein Tool weiß das.

## Die Daten sind schon jetzt unbequem

Die strukturellen Kosten der Fragmentierung sind quantifiziert. Eine aktuelle [Gartner-Sales-Operations-Studie](https://www.gartner.com/en/sales/trends/2025-sales-operations-leadership-vision) ergab, dass Revenue-Operations-Teams inzwischen häufig fünf oder mehr Gruppen betreuen und 68 % ihrer Zeit mit Nicht-Kunden-Arbeit verbringen. Zwei Drittel der Ops-Kapazität fließen in Koordination, Tool-Kleber, Abstimmung und das langsame Entschlüsseln dessen, was ein anderes System eigentlich meinte, als es einen Status gesetzt hat. Und das, bevor überhaupt jemand fragt, ob die zwei benachbarten Prozesse im Unternehmen, Sales und Recruiting, auch nur eine gemeinsame Phasendefinition haben.

Auf der Kandidatenseite geht das Leck schneller und ist sichtbarer. Branchenberichte zum [Einstellungsprozess 2025](https://blog.theinterviewguys.com/state-of-the-hiring-process-in-2025/) beschreiben eine klare Dynamik: Die besten Kandidat(inn)en sind in etwa 10 Tagen vom Markt, und die Abbruchquote bei Bewerbungen liegt um die 60 %, wenn der Prozess sich hinzieht. Wenn Sales die kommerzielle Antwort bekommt, die es braucht, und Recruiting noch wartet, hat der Kandidat bereits woanders Ja gesagt. Dein AE weiß es nicht. Deine Recruiterin weiß es, aber hat keine Möglichkeit, es zu signalisieren, die der AE auch sieht.

Das Gegenteil beweist den Punkt. [HubSpot Research](https://www.hubspot.com/state-of-marketing) stellte fest, dass Kundenbindung um 36 % steigt und Win-Raten um 38 % klettern, wenn Sales und Customer Success einen gemeinsamen operativen Rahmen teilen. Die Lehre daraus geht nicht speziell um CS, sie geht um Nachbarschaft. Zwei Teams, die dieselbe Kundenbeziehung bearbeiten, performen radikal besser, wenn sie sich gegenseitig sehen können. Es gibt noch keinen veröffentlichten Benchmark für Sales-plus-Recruiting-Alignment, weil kaum jemand es gemessen hat, aber der Mechanismus ist derselbe. Nachbarschaft zahlt sich einmal aus und zahlt sich zweimal aus.

## Die Anatomie eines Handoff-Versagens

Jedes Handoff-Leck, das wir bei einem Scale-up zurückverfolgt haben, lässt sich auf eine von drei Mechaniken zurückführen.

Die erste ist **veraltetes Ownership**. Ein Lead oder ein Kandidat hat einen Namen daneben stehen. Diese Person ist inzwischen in ein anderes Team gewechselt, im Urlaub oder hat sich still vom Account zurückgezogen. Der Datensatz ist nicht absichtlich falsch. Er ist falsch, weil nichts im Stack jemals eine Aktualisierung erzwungen hat. Auf einem Single-Motion-Stack ist das schmerzhaft. Auf zwei Prozessen, die sich gegenseitig blockieren, ist es multiplikativ.

Die zweite ist die **unsichtbare Phase**. Ein Lead bewegt sich im CRM von „Qualified" zu „Discovery". Die Recruiterin sieht es nicht. Warum auch? Der Lead ist ein Sales-Artefakt. Aber dasselbe Account hat auch einen Hiring Manager, der einer von vier Entscheidern im Deal ist. Wenn Sales den Datensatz verschiebt, weiß Recruiting nicht, dass sich die Temperatur gerade verändert hat. Ein Kalibrierungsanruf, der diese Woche hätte stattfinden können, findet jetzt erst in drei Wochen statt, nachdem die Phase bereits ins Stocken geraten ist.

Das dritte, und teuerste, ist der **Cross-Motion-Engpass**. Eine Person, meistens ein Hiring Manager oder ein VP Engineering, ist gleichzeitig der Flaschenhals in zwei verschiedenen Pipelines. Das Sales-Team wartet darauf, dass sie Headcount genehmigt, bevor es sich auf Scope festlegen kann. Das Recruiting-Team wartet darauf, dass sie das Angebot unterzeichnet, bevor ein Kandidat zusagt. Jedes Team eskaliert einzeln. Jedes Team schichtet auf den Stapel, den dieselbe Person abarbeiten muss. Hätte eines der beiden Teams die Warteschlange des anderen gesehen, hätte es das Gespräch gebündelt. Keines hat es gesehen.

## Was ein gemeinsames Cockpit wirklich verändert

Ownership wird zu einem Feld, nicht zu zweien. Dieselbe Person, die als verantwortlicher Owner eingetragen ist, wird in beiden Prozessen für die Accounts weitergeführt, bei denen es dieselbe Person ist. Phasen werden teamübergreifend lesbar. Ein Lead, der zu „Proposal" wechselt, markiert den Recruiting-Datensatz für dasselbe Unternehmen, weil die Rollen, die für dieses Account besetzt werden sollen, gerade zeitkritisch geworden sind. Engpässe tauchen als Engpässe auf, nicht als zwei unzusammenhängende Terminverschiebungen. Der Hiring Manager sieht in einer einzigen Ansicht, was von beiden Seiten noch offen ist, und trifft eine Entscheidung, anstatt zweimal angetrieben zu werden.

Das ist es, was es bedeutet, zwei Pipelines in ein Grid zu legen, und es ist der Grund, warum LeadGrid existiert. Nicht weil Sales-Teams ihre CRMs satt haben und Recruiting-Teams ihre ATSes, obwohl beides stimmt. Sondern weil der Handoff, der einem Scale-up das Genick bricht, nicht innerhalb eines der beiden Tools liegt, sondern zwischen ihnen.

## Das Audit, das du am Montag machst

Du brauchst keine neue Plattform, um anzufangen. Du musst herausfinden, wo deine Handoffs tatsächlich lecken. Ein paar Dinge, die du in der ersten Woche ausprobieren kannst, mit dem, was du bereits hast.

Geh Montagmorgen rein und liste alle Leads auf, die letzte Woche ins Stocken geraten sind, zusammen mit allen Kandidat(inn)en, die letzte Woche ins Stocken geraten sind. Füge sie in dasselbe Spreadsheet ein, sortiert nach der benannten Person, die auf etwas wartet. Zähl, wie oft dieselbe Person in beiden Spalten auftaucht. Diese Zahl ist deine Cross-Motion-Engpassrate. Bei den meisten Scale-ups, denen wir geholfen haben, liegt sie zwischen 15 und 30 Prozent. Das sind 15 bis 30 Prozent deiner Stockungen, die weder ein Sales-Problem noch ein Recruiting-Problem sind, sie sind ein Warteschlangen-Problem.

Prüfe dann deine Ownership-Felder. Frag für jeden aktiven Datensatz in beiden Systemen, ob die genannte Person in den letzten fünf Werktagen auf E-Mails geantwortet hat. Der Prozentsatz, der das nicht erfüllt, ist deine Rate für veraltetes Ownership. Alles über 20 % bedeutet: Der Datensatz lügt dich genau in dem Moment an, in dem du ihn am dringendsten brauchst.

Nimm dir schließlich einen offenen Account vor, bei dem das Unternehmen sowohl ein Deal als auch ein Recruiting-Ziel ist. Lege das Sales-Aktivitätsprotokoll und das Recruiting-Aktivitätsprotokoll nebeneinander. Bemerke jeden Moment, in dem ein Team dem anderen einen Tag hätte sparen können. Diese Liste ist dein Handoff-Defizit.

## Die Lösung ist ein Grid, kein größeres CRM

Der Grund, warum Umsatz an der Naht zwischen Sales und Recruiting verloren geht, ist nicht, dass dein CRM schlecht oder dein ATS falsch ist. Es ist, dass dein Prozess eine Sache ist und dein Stack zwei. Die Lösung ist kein größeres CRM. Es ist kein tieferes ATS. Es ist ein Grid, das beide Pipelines mit demselben Vokabular, demselben Owner-Feld und demselben Verständnis davon zeigt, was „feststeckend" bedeutet. Gib Ops-Leadern eine einzige Ansicht des Prozesses, und der Prozess hört auf, Menschen durch die Maschen fallen zu lassen.

**[Kostenlos starten →](https://leadgrid.io/signup)**

---

# Warum wir LeadGrid als eine API für zwei Pipelines gebaut haben

URL: https://leadgrid.io/de/blog/warum-wir-leadgrid-gebaut-haben
Locale: de
Published: 2026-04-14
Author: Ralf Klein
Tags: product, api

Die meisten Growth-Teams betreiben ein CRM und ein ATS für dieselbe Bewegung. Hier erfährst du, was zusammenbricht, wenn du Sales und Recruitment auf einem Datenmodell abbildest, und warum wir es von Anfang an programmierbar gemacht haben.

Jedes Growth-Team, mit dem ich je gearbeitet habe, führt dieselbe Bewegung zweimal aus. Sales hat ein CRM. Recruitment hat ein ATS. Dieselbe Pipeline-Form, Aufnahme, Qualifizierung, Weiterbewegen, Abschluss, aber auf zwei Stacks, die nicht miteinander reden.

Wir haben LeadGrid gebaut, weil diese Trennung eine Entscheidung ist, keine Notwendigkeit.

## Das Datenmodell ist dasselbe

Ein Lead und ein Kandidat sind beides *Menschen, die Phasen durchlaufen*. Gib ihnen einen Namen, eine Phase, eine Deadline, einen Verantwortlichen und ein paar Notizen, und du hast beide beschrieben. Die Verben sind identisch: erstellen, zuweisen, weiterschieben, kommentieren, abschließen.

Die Branche hat zwei Produktkategorien darum herum gebaut, weil es profitabel war, nicht weil die zugrunde liegende Arbeit unterschiedlich ist. Teams zahlen am Ende zwei Anbieter, integrieren zwei APIs, schulen auf zwei UIs und gleichen zwei Wahrheitsquellen ab, um dieselbe Sache zweimal zu verfolgen.

## Was zusammenbricht, wenn du vereinheitlichst

Eine Plattform für beide Pipelines zu betreiben, bringt drei konkrete Vorteile:

- **Übergaben fallen nicht mehr durch den Rost.** Sales verspricht Lieferung. Recruitment findet die Menschen, die liefern. Wenn beide dasselbe Grid sehen, passieren Eskalationen bevor der Kandidat abspringt oder der Deal verloren geht.
- **Tooling-Kosten halbieren sich.** Ein Workspace, eine Abrechnungszeile, ein Berechtigungsmodell. Sales und Recruitment hören auf, darum zu streiten, welches Tool die Wahrheitsquelle ist, es ist dasselbe.
- **Reporting wird ehrlich.** Time-to-hire und Time-to-close leben in derselben Datenbank. Du kannst endlich die Frage beantworten: „Haben wir diesen Deal verloren, weil wir die Person nicht hatten?", ohne ein Spreadsheet.

## API-first, nicht API-als-Nachgedanke

Die andere bewusste Entscheidung: Jede Aktion, die die UI ausführt, ist ein REST-Aufruf. Dossier erstellen, Phase verschieben, Notiz hinzufügen, Mitglied zuweisen, alles skriptbar, alles dokumentiert unter [`/docs/api`](/docs/api).

Das klingt nach Mindeststandard, und das sollte es auch sein, aber die meisten CRMs behalten ihre besten Features für höhere Tiers zurück, wickeln die API in Rate-Limits ein, die Dich in Professional Services treiben sollen, oder verweigern die Dokumentation von Webhooks. Wir wollten das Gegenteil: Die API ist das Produkt, die UI ist ein praktischer Weg, es zu nutzen.

Die praktische Konsequenz: Deine Automationen interessiert es nicht, ob etwas ein Lead oder ein Kandidat ist. Du schreibst eine Integration einmal, und sie funktioniert über beide Pipelines. Claude, n8n, Zapier, Dein eigenes Backend, gleiche Endpoint-Struktur, gleiche Auth, gleiches Webhook-Schema.

## Kostenlos für immer im Free-Plan

Noch eine letzte Sache. LeadGrid ist kostenlos für immer im Free-Plan, kein 14-Tage-Test, keine zeitlich begrenzte Aktion. Du kannst ein echtes Team darauf betreiben, echte Pipelines bauen und uns keinen einzigen Cent zahlen. Bezahlte Pläne schalten mehr Seats, aktive Dossiers, Flows und API-Durchsatz frei, wenn Du die kostenlosen Limits übertriffst.

Wir haben lieber, dass Du auf der Plattform baust, als dass Du auf einen ablaufenden Countdown starrst.

[Kostenlos starten →](/signup)

---

## FR posts

# Lead scoring sans ML: pourquoi une scorecard à cinq règles gagne pour la plupart des équipes

URL: https://leadgrid.io/fr/blog/lead-scoring-sans-ml-scorecard-cinq-regles
Locale: fr
Published: 2026-05-13
Author: Ralf Klein
Tags: sales, guides

La plupart des équipes qui adoptent le lead scoring en machine learning obtiendraient 80% du résultat avec une scorecard à cinq règles. Quand passer à l'échelon supérieur, et quand non.

Chaque trimestre, une nouvelle équipe commerciale me dit qu'elle a besoin de lead scoring par AI. On creuse, et ce dont elle a vraiment besoin, c'est d'une scorecard propre à cinq règles avec des poids négatifs et une fonction de décroissance. Le modèle ML fait la une, mais le levier réel se trouve dans les fondamentaux que presque personne ne prend la peine de poser d'abord.

Ce n'est pas une posture contrariante. C'est exactement ce qu'on lit, enterré au bas de chaque guide ML honnête. Le problème, c'est que la version à règles a l'air ennuyeuse, donc les équipes la sautent et paient pour un modèle qui apprend la mauvaise chose à partir de données sales.

## Le problème mathématique que la plupart des équipes ont d'abord

Un modèle prédictif a besoin d'assez d'exemples closed-won et closed-lost pour apprendre. La plupart des équipes B2B n'ont pas encore ce volume. Selon le [Prospeo guide on AI versus traditional lead scoring](https://prospeo.io/s/ai-lead-scoring-vs-traditional-lead-scoring), le seuil pratique se situe autour de 1 000 leads par an, 100 deals fermés et 12 à 24 mois de données CRM propres avant qu'un modèle ML ne produise un score défendable. En dessous, un modèle à règles bien construit battra à chaque fois un modèle AI mal entraîné.

C'est la partie que les decks des vendeurs omettent. Un modèle entraîné sur 60 conversions et un an de définitions d'étape incohérentes n'apprend pas votre acheteur, il apprend votre problème d'hygiène de données.

## Pourquoi la version à règles gagne le plus souvent

Forrester est direct là-dessus depuis des années. Le [Forrester piece on what lead scoring actually is](https://www.forrester.com/blogs/what-is-lead-scoring-anyway/) le dit clairement: la plupart des modèles de scoring en production sont bâtis sur des suppositions et des estimations aléatoires de la propension à acheter, pas sur une vraie analyse. Remplacer ça par un modèle ML entraîné sur les mêmes inputs branlants ne corrige pas les inputs, ça rend juste le score plus difficile à contester.

Une scorecard simple est auditable, rapide à modifier, et oblige les équipes commerciale et marketing à s'accorder sur ce que veut dire "qualified" avant de la mettre en production. Cet alignement est l'endroit d'où vient l'essentiel du levier réel. Le [Clueless Company breakdown of failing lead scoring models](https://www.theclueless.company/lead-scoring-techniques/) le formule bien: la raison la plus fréquente pour laquelle les projets de scoring échouent n'est pas la mauvaise logique, c'est que les commerciaux ne font pas confiance au score, donc les reps continuent à travailler les contacts qu'ils travaillaient déjà.

Tu ne peux pas construire de la confiance dans une boîte noire. Tu peux en construire dans cinq règles que tu peux lire sur un tableau blanc.

## La scorecard à cinq règles

Voici la version que nous recommandons à tout client LeadGrid sous le seuil ML. Elle tient sur un écran et s'explique d'elle-même.

```yaml
fit_score:
  icp_company_size:    { match: +20, miss: -15 }
  icp_industry:        { match: +15, miss: -10 }
  decision_maker_role: { match: +20, miss: -10 }

intent_score:
  pricing_page_visit:  +20
  demo_request:        +30
  three_emails_opened: +5
  inactivity_per_week: -5

threshold_for_sales_handoff: 50
```

Cinq règles, deux poids négatifs, une règle de décroissance. C'est tout. La structure est empruntée au [Reform guide on common lead scoring mistakes](https://www.reform.app/blog/common-lead-scoring-mistakes-and-fixes), qui est direct sur les deux modes d'échec qu'une scorecard de base doit corriger: suivre trop de signaux crée du bruit, et n'attribuer que des scores positifs inonde le CRM de leads froids que personne ne nettoie.

La règle de décroissance pèse plus lourd que les gens ne le pensent. Le [Breadcrumbs B2B lead scoring framework for 2026](https://breadcrumbs.io/blog/b2b-lead-scoring/) recommande de retirer des points pour chaque semaine d'inactivité, précisément pour que les MQLs zombies ne restent pas en haut de la file pendant qu'un lead plus chaud de ce matin se retrouve en dessous. Sans décroissance, ta scorecard est un tableau des scores, pas une file.

## Quand passer à ML

Il existe un vrai seuil où le scoring ML mérite sa complexité. Tu l'as franchi quand trois choses sont vraies en même temps.

Tu as au moins 100 enregistrements closed-won propres et 100 closed-lost propres, avec des définitions d'étape cohérentes sur tout cet historique. Le [Landbase lead scoring statistics roundup](https://www.landbase.com/blog/lead-scoring-statistics) cite des données Forrester montrant 38% de conversion en plus et 28% de cycles de vente plus courts pour les équipes qui font du AI scoring, mais ces chiffres viennent d'équipes qui avaient l'hygiène de données pour entraîner dessus. Sans cette hygiène, le modèle apprend ton CRM en désordre, pas ton acheteur.

Ton cycle de vente est assez complexe pour que les humains ne puissent plus retenir les variables en tête. Les deals enterprise multi-stakeholders avec 18+ touchpoints sur six mois sont un problème différent d'un funnel SaaS self-serve avec une porte de free trial. ML gagne sa place sur la forme complexe, pas sur la simple.

Tu as déjà livré la version à règles et tu peux nommer exactement quelle règle le modèle ML va battre. Si tu ne peux pas la nommer, le modèle ML ne résout pas un problème que tu as, il en résout un que le vendeur a.

## L'hybride honnête

Le pattern qui marche, c'est le scoring à règles comme couche de base, ML en couche au-dessus dès que tu as les données pour le justifier. Les règles te donnent un score auquel les reps font confiance dès le premier jour. La couche ML, une fois livrée, ajuste le score à partir de patterns que les règles ne voient pas, mais le score lisible par un humain reste dans l'UI.

C'est aussi vers ça que pointaient les [SiriusDecisions data on lead scoring adoption](https://salesdorado.com/en/sales-qualification/lead-scoring-useless/), qui trouvaient que 68% des entreprises pratiquaient le lead scoring mais que seuls 40% des commerciaux y voyaient une valeur. Les équipes dans les 40% avaient un modèle que les reps pouvaient expliquer. Les équipes dans les 60% restants avaient un modèle auquel les reps ne croyaient pas.

Construis d'abord la version à cinq règles. Mérite l'upgrade ML quand tes données et ton équipe commerciale sont prêtes. La plupart des équipes n'ont jamais besoin de franchir cette deuxième étape, et c'est très bien comme ça.

[Commencer gratuitement →](https://leadgrid.io/signup)

---

# Le problème du volume de candidatures pour les recruteurs : 93 % de plus, mêmes effectifs

URL: https://leadgrid.io/fr/blog/probleme-volume-candidatures-recruteurs
Locale: fr
Published: 2026-04-29
Author: Ralf Klein
Tags: recruitment, guides

Les recruteurs traitent 93 % de candidatures en plus avec des équipes 14 % plus petites. Embaucher plus de recruteurs n'est pas la solution. Refonte du processus.

Les équipes de recrutement font tourner un processus de 2021 sur un volume de 2026. Selon [Gem's 2026 Recruiting Benchmarks Report](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report), les recruteurs traitent aujourd'hui 93 % de candidatures en plus et gèrent 40 % de postes ouverts en plus qu'il y a cinq ans, alors que les équipes ont rétréci de 14 %. Les embauches par recruteur ont chuté de 43 %. Le calcul ne tombe pas juste, et ajouter des effectifs n'est pas la solution.

## Pourquoi embaucher plus de recruteurs n'est pas la réponse

Doubler le volume avec une équipe 14 % plus petite suggérerait de doubler l'équipe. Trois raisons pour lesquelles cela échoue.

D'abord, la finance n'approuve pas 2x d'embauches de recruteurs alors que les organigrammes engineering s'aplatissent. Le coût par embauche est déjà en hausse dans la plupart des segments selon les [benchmarks Gem 2026](https://www.gem.com/resource/recruiting-benchmarks). Ajouter des places empire les choses sans changer le taux de conversion.

Ensuite, le goulot a bougé. La plupart des équipes traitent le volume comme un problème de tri. Ce n'en est pas un. Les mêmes données Gem montrent que seuls 0,5 % des candidats sont embauchés, ce qui signifie que 99,5 % du temps recruteur passé à examiner des CV est gaspillé en agrégat. Plus de recruteurs, c'est plus d'heures gaspillées, pas des embauches plus rapides.

Troisièmement, la source qui convertit le mieux n'est pas du tout les nouveaux candidats. Gem rapporte que 46 % des embauches sourcées viennent désormais de candidat(e)s redécouvert(e)s déjà dans le CRM ou l'ATS, contre 26 % en 2021. Les équipes qui doublent la mise sur l'examen inbound optimisent le pire flow qu'elles aient.

## Où le temps fuit vraiment

Lance un audit du temps sur une semaine pour n'importe quelle équipe à fort inbound. Le motif se répète :

- **Examen de CV à parité.** Chaque candidat reçoit la même attention au premier passage, peu importe la source. Une candidature LinkedIn Easy Apply reçoit les mêmes 30 secondes qu'un referral. C'est la mauvaise allocation.
- **Pas de niveaux de scoring.** Les équipes sans règle d'auto-disqualification dure et règle de fast-track finissent par lire chaque CV moyen en entier.
- **Appels de tri synchrones.** Un appel téléphonique de 20 minutes pour chaque candidat(e) "peut-être" mange la journée du recruteur même quand 70 % n'avanceront pas.
- **Sourcing à froid pendant que l'inbound s'accumule.** Fouiller les candidat(e)s existant(e)s du CRM est laissé au temps libre qui n'arrive jamais.

Aucun de ces points n'est un problème d'effectifs. Ce sont des problèmes de processus et d'outillage.

## Mouvements de processus qui passent à l'échelle sans corps

**Redécouvrir avant de sourcer.** Les [données SmartRecruiters 2025 sur le recrutement](https://www.smartrecruiters.com/blog/recruitment-statistics-for-2025/) confirment la trouvaille de Gem que les pipelines historiques convertissent deux à trois fois plus que le sourcing à froid. Avant de publier un poste, interroge le CRM pour les anciens candidats qui matchent une demande similaire. C'est une recherche, pas 200 examens de CV.

**Étage le flow inbound.** Construis trois voies : auto-disqualification sur les exigences dures, fast-track sur score plus referral ou statut alumni, examen manuel pour le reste. Les règles de niveau vont dans le dossier, pas dans la tête du recruteur. La voie du milieu est celle où les effectifs paraissent chers. La diviser par deux en relevant la barre fait perdre généralement zéro embauche et libère une semaine-recruteur complète par poste.

**Async-screen les "peut-être".** Remplace l'appel de 20 minutes "tu es réel(le)" par une demande écrite asynchrone : trois questions, fenêtre de 48 heures. Les candidat(e)s qui ne répondent pas s'auto-éliminent. Ceux qui répondent fournissent une trace écrite que les hiring managers lisent en 90 secondes.

**Mets l'automatisation dans le dossier, pas autour.** Quand la relance d'étape suivante, l'e-mail de refus, le lien de planification et le passage au hiring manager vivent tous dans le dossier candidat, les recruteurs arrêtent de switcher entre cinq outils. Le [Cronofy Candidate Expectations Report 2024](https://www.cronofy.com/reports/candidate-expectations-report-2024) a trouvé que les candidats attendent une réponse sous 48 heures, et que les taux d'abandon explosent au-delà de cette fenêtre. Un outillage qui garde la prochaine action à un clic, c'est ce qui rend 48 heures possible à l'échelle.

## Ce qu'il faut mesurer à la place du temps d'embauche

Le temps d'embauche agrégé est trop grossier pour déboguer un problème de volume. Trois métriques qui séparent le signal :

- **Temps-en-étape par source.** Des candidats inbound qui stagnent 8 jours en tri pendant que les referrals passent en 2 te dit que les règles de niveau sont fausses, pas que le flow est lent.
- **Taux d'embauche par voie.** Si ta voie d'examen manuel convertit à 0,4 % et ta voie fast-track à 12 %, la voie manuelle ne mérite pas son temps recruteur.
- **Taux de redécouverte.** Quelle part des embauches venait de candidat(e)s déjà dans le système ? Si c'est sous le [benchmark Gem de 46 %](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report), ton mouvement de sourcing n'utilise pas ses propres données.

Chacune est un tag sur le dossier candidat et une étape dans la pipeline. Aucune ne demande un nouvel outil, et aucune ne demande une équipe plus grande.

## Le cadre

Le problème de volume n'est pas un problème d'effectifs. C'est un problème de processus déguisé en problème d'effectifs. Les équipes qui acceptent la nouvelle base (93 % de candidatures en plus, 14 % de recruteurs en moins) et redessinent autour, livrent des embauches à la même vitesse. Les équipes qui font du lobbying pour plus d'effectifs perdent la conversation budget et gardent le goulot.

Construis le dossier pour qu'un recruteur déplace un candidat en un clic. Étage le flow pour que 80 % des candidats soient décidés en 30 secondes. Fouille le CRM avant de sourcer. Le chiffre du volume ne baissera pas, mais le temps par candidat(e), si.

[Commencer gratuitement →](https://leadgrid.io/signup)

---

# Pourquoi l'analyse du drop-off de pipeline fonctionne pareil en vente et en recrutement

URL: https://leadgrid.io/fr/blog/analyse-drop-off-pipeline-fonctionne-pareil
Locale: fr
Published: 2026-04-28
Author: Ralf Klein
Tags: pipeline, guides

Vente et recrutement semblent être des pipelines différents. Les maths du drop-off sont identiques. Mêmes diagnostics, mêmes correctifs, juste d'autres étiquettes d'étape.

La plupart des équipes traitent le drop-off des ventes et le drop-off du recrutement comme deux problèmes distincts. Elles tirent des rapports différents, posent des questions différentes, et embauchent des spécialistes différents pour résoudre chacun. Ce clivage est avant tout culturel. Les maths sont identiques.

Un pipeline est une suite d'étapes. Les gens entrent en haut, avancent étape par étape, puis closent ou tombent. Le drop-off est le pourcentage qui tombe à chaque transition. Une fois ce cadre accepté, vente et recrutement cessent d'être des problèmes distincts et deviennent le même problème avec d'autres étiquettes sur les cases.

## Les maths de l'entonnoir se moquent du nom des étapes

En vente, les étapes canoniques sont Lead, MQL, SQL, Opportunity, Closed Won. En recrutement, ce sont Candidature, Screening, Entretien, Offre, Embauche. Cinq étapes par pipeline. Quatre transitions par pipeline. À chaque transition, un pourcentage continue, un autre tombe.

Selon le [Glue Up 2026 sales funnel benchmarks](https://www.glueup.com/blog/sales-funnel-conversion-rate-benchmarks), l'entonnoir de vente B2B typique convertit Lead vers MQL à 25 à 35%, MQL vers SQL à 13 à 26%, SQL vers Opportunity à 50 à 62%, et Opportunity vers Closed Deal à 15 à 30%. Multiplie ces taux et tu obtiens une conversion bout en bout d'environ 0,3% à 1,6%.

En recrutement, le [CareerPlug's 2025 Recruiting Metrics Report](https://www.careerplug.com/blog/recruiting-metrics-report/) a suivi plus de 10 millions de candidatures et constaté qu'environ 3% des candidat(e)s atteignent un entretien et moins de 1% finissent embauchés. Même forme. Mêmes ordres de grandeur. Le plus grand creux dans les deux entonnoirs se produit à l'étape de qualification: MQL vers SQL en vente, Candidature vers Screening en recrutement.

## Les schémas diagnostiques sont aussi les mêmes

Quand le drop-off vente s'envole entre MQL et SQL, trois choses sont en général vraies: le volume de leads a crû plus vite que la capacité commerciale, les critères de qualification sont mal alignés entre marketing et vente, ou le délai de réponse a glissé. Quand le drop-off recrutement s'envole entre Candidature et Screening, trois choses sont en général vraies: le volume de candidatures a crû plus vite que la capacité de recrutement, les critères de screening sont mal alignés entre hiring manager et recruteur, ou le délai de réponse a glissé.

Relis ces deux paragraphes. Les trois mêmes diagnostics. Le [Ashby 2025 Talent Trends Report](https://www.ashbyhq.com/resources) montre que les équipes de recrutement traitent aujourd'hui presque deux fois le volume de candidatures de 2021 avec le même effectif, ce qui produit exactement le bottleneck qu'une équipe commerciale obtient quand les leads triplent et les commerciaux restent au même niveau.

Les correctifs riment aussi. En vente, tu resserres les critères de qualification, tu poses des SLA sur le délai de réponse, ou tu investis dans le scoring avant routage. En recrutement, tu resserres les critères de screening, tu poses des SLA sur le délai de réponse, ou tu investis dans le pré-screening avant la revue par le recruteur. Le verbe est "filtrer ou accélérer". Ce verbe marche dans les deux pipelines.

## Là où l'analyse casse (et pourquoi)

La raison pour laquelle la plupart des équipes ratent cette symétrie, c'est que la donnée vit dans des systèmes différents. Le CRM stocke le pipeline de vente. L'ATS stocke le pipeline de recrutement. Les rapports sont construits par système, par des gens qui ne voient qu'un seul entonnoir. Donc, quand le drop-off vente et le drop-off recrutement sont causés par la même chose sous-jacente (l'entreprise a fait rentrer plus de demande qu'elle n'a construit de capacité), personne ne le voit, parce que personne ne regarde les deux à la fois.

La [recherche SHRM sur l'expérience candidat](https://www.shrm.org/topics-tools/news/talent-acquisition) montre que 60% des candidat(e)s abandonnent leur candidature à cause de la friction de processus. Le même pourcentage exact de leads B2B abandonnent les conversations commerciales pour la même raison: trop d'étapes, trop lent, trop flou. Un chiffre, une racine, deux rapports que personne ne relie.

## Ce que débloque une analyse de pipeline unifiée

Si tu peux passer la même requête de drop-off sur les deux entonnoirs, trois choses deviennent évidentes alors qu'elles étaient invisibles avant. Premièrement: les bottlenecks de capacité sur des ressources partagées, comme un hiring manager qui est aussi sponsor de deal, apparaissent simultanément dans les deux pipelines comme drop-off. Deuxièmement: les améliorations de processus se cumulent, un schéma de SLA qui lift la conversion vente est le même schéma de SLA qui lift l'acceptation d'offre. Troisièmement: tu cesses d'embaucher deux équipes analytics pour répondre à une seule question.

Voilà l'argument pratique pour traiter vente et recrutement comme un seul produit pipeline, pas deux. Le modèle de données est le même. Les diagnostics sont les mêmes. Les correctifs sont les mêmes. La seule différence, c'est l'étiquette sur la case.

[Commencer gratuitement →](https://leadgrid.io/signup)

---

# Quatre intégrations API LeadGrid que ton équipe utilisera vraiment

URL: https://leadgrid.io/fr/blog/integrations-api-leadgrid-que-ton-equipe-utilisera-vraiment
Locale: fr
Published: 2026-04-25
Author: Ralf Klein
Tags: api, product, guides

LeadGrid expose chaque action du pipeline comme un endpoint REST. Quatre intégrations que les équipes construisent en une après-midi, avec de vrais exemples de code.

LeadGrid est conçu API-first. Chaque action que tu peux faire dans l'interface, créer un dossier, déplacer un lead dans une étape, ajouter une note, assigner un propriétaire, est un appel REST documenté. C'est un choix de conception, pas une fonctionnalité secondaire.

Selon le [Postman 2025 State of the API Report](https://www.postman.com/state-of-api/2025/), 82% des organisations ont adopté une approche API-first. Les équipes qui construisent sur leur outil de pipeline plutôt qu'autour de lui arrêtent de faire la même tâche manuelle deux fois par semaine.

Voici quatre intégrations que les équipes construisent vraiment, avec le code pour le prouver.

## 1. La soumission d'un formulaire web crée automatiquement un dossier

C'est la plus courante. Tu as un formulaire de contact, une landing page ou un lien de recommandation partenaire. Quelqu'un le remplit. En ce moment, quelqu'un dans ton équipe copie manuellement ces données dans LeadGrid. C'est la première chose à éliminer.

L'API LeadGrid te permet d'appeler `POST /dossiers` pour créer un nouveau dossier dans n'importe quel pipeline. Un simple récepteur de webhook en Node s'occupe du reste :

```ts
// Déclenché par ton fournisseur de formulaires (Typeform, Tally, formulaire natif, peu importe)
app.post('/webhook/new-lead', async (req, res) => {
  const { name, email, company } = req.body;

  await fetch('https://api.leadgrid.io/v1/dossiers', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.LEADGRID_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      pipelineId: 'your-pipeline-id',
      title: `${name} - ${company}`,
      fields: { email, company },
    }),
  });

  res.sendStatus(200);
});
```

Nouveau lead entré. Pas de copier-coller. Personne n'oublie.

## 2. Le changement d'étape envoie une notification Slack

Les managers commerciaux regardent LeadGrid. Le reste de l'équipe regarde Slack. Si un deal passe en "Négociation" ou qu'un candidat(e) atteint l'"Entretien final", ton canal Slack devrait le savoir avant que quiconque ait à demander.

Les webhooks LeadGrid te permettent de t'abonner aux événements `dossier.stage_changed`. Quand ça se déclenche, tu transmets vers ton webhook Slack entrant :

```ts
app.post('/webhook/leadgrid-events', async (req, res) => {
  const { event, data } = req.body;

  if (event === 'dossier.stage_changed') {
    const { title, stage, pipelineId } = data;

    await fetch(process.env.SLACK_WEBHOOK_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        text: `Mise à jour pipeline : *${title}* est passé à *${stage}*`,
      }),
    });
  }

  res.sendStatus(200);
});
```

Trente lignes. Ton équipe arrête de demander : "où en est ce deal ?"

## 3. Un deal conclu envoie un dossier dans ton système RH ou ERP

Quand un placement de recrutement se conclut ou qu'un contrat commercial est signé, ton back-office doit le savoir. Exporter manuellement depuis LeadGrid et importer dans ta plateforme RH ou ton ERP, c'est exactement le genre de travail qui génère des erreurs le jeudi après-midi.

Abonne-toi aux événements `dossier.closed` et envoie les données structurées directement :

```ts
if (event === 'dossier.closed') {
  const { id, title, fields } = data;

  // Push vers ton système RH, remplace par l'API de ton fournisseur
  await fetch('https://api.your-hr-tool.com/employees', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.HR_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      name: fields.candidateName,
      email: fields.email,
      startDate: fields.startDate,
      role: fields.jobTitle,
    }),
  });
}
```

LeadGrid est le déclencheur. Ton système RH reçoit des données propres et structurées. Aucun CSV en vue.

## 4. Rapport de pipeline nocturne dans ta boîte mail

Le management veut un aperçu chaque matin. Qu'est-ce qui a bougé hier ? Qu'est-ce qui est bloqué ? Qu'est-ce qui nécessite de l'attention ?

Un simple cron job qui appelle `GET /dossiers?filter=updated_since=yesterday` et formate le résultat couvre entièrement ce besoin :

```ts
// Exécuter chaque matin à 07:00 via cron ou une fonction planifiée
const yesterday = new Date(Date.now() - 86400000).toISOString();

const response = await fetch(
  `https://api.leadgrid.io/v1/dossiers?updated_since=${yesterday}`,
  { headers: { 'Authorization': `Bearer ${process.env.LEADGRID_API_KEY}` } }
);

const { dossiers } = await response.json();
const summary = dossiers.map(d => `- ${d.title}: ${d.stage}`).join('\n');

// Envoyer via Resend, Postmark ou tout autre fournisseur d'e-mails transactionnels
await sendEmail({
  to: 'team@yourcompany.com',
  subject: `Mise à jour pipeline - ${new Date().toLocaleDateString()}`,
  text: summary || 'Aucun changement depuis hier.',
});
```

Le [Postman 2025 State of the API Report](https://www.postman.com/state-of-api/2025/) a également constaté que 52% des développeurs ont subi des breaking changes de fournisseurs externes en 2024. LeadGrid maintient des endpoints versionnés (`/v1/`) pour que tes intégrations ne tombent pas silencieusement en panne un mardi matin.

## Le schéma derrière les quatre

Chacune de ces intégrations suit la même structure : écouter un déclencheur (webhook ou planification), appeler l'API LeadGrid pour lire ou écrire des données, envoyer le résultat ailleurs. La surface de l'API est cohérente, authentifiée avec un seul bearer token, et retourne du JSON prévisible.

C'est ce que API-first signifie vraiment en pratique. Tu ne construis pas des flows *dans* LeadGrid. Tu les construis *dessus*.

Référence API complète, documentation d'authentification et catalogue d'événements webhook sur [leadgrid.io/docs](https://leadgrid.io/docs).

[Commencer gratuitement →](https://leadgrid.io/signup)

---

# Pourquoi ton équipe opérationnelle panique quand les ventes s'envolent

URL: https://leadgrid.io/fr/blog/pourquoi-ops-panique-quand-sales-gagne
Locale: fr
Published: 2026-04-23
Author: Ralf Klein
Tags: sales, recruitment, pipeline

Quand les leads s'accumulent et que le recrutement est à la traîne, ops appuie sur le bouton panique. C'est le plus souvent une crise d'information, pas une crise de capacité. Voici comment faire la différence.

Il y a un moment précis que connaît toute entreprise de 30 à 60 personnes. Les ventes signent. La pipeline est pleine. Le CRM s'enflamme. Et quelque part dans un canal Slack ou une réunion du lundi matin, un responsable ops dit: "On ne peut pas prendre de nouveaux clients en ce moment."

L'équipe commerciale ne comprend pas. Les chiffres sont bons. L'équipe ops est sous pression. Les deux ont raison, et les deux ne voient qu'une partie du tableau.

## L'écart entre la signature et la livraison

La plupart des entreprises à ce stade gèrent deux pipelines complètement séparées. Les ventes suivent les leads dans un CRM: prospect, démo, proposition, gagné. Le recrutement suit les candidats dans un ATS: candidature, tri, entretien, embauche. Même mouvement de fond, outils différents, zéro contexte partagé.

Le problème n'est pas que ces équipes avancent à des vitesses différentes. Elles l'ont toujours fait. Le problème est que personne ne peut voir les deux pipelines en même temps.

Quand ops voit une pipeline commerciale pleine et ne sait pas que trois ingénieurs sont en entretien final, ops panique. Quand les ventes voient un trimestre lent et ne savent pas que deux nouvelles recrues sont encore en onboarding, elles poussent plus fort. Chaque décision est prise avec des informations incomplètes.

## Le délai de recrutement est plus long que tu ne le crois

[Le rapport SHRM Talent Acquisition Benchmarking](https://www.shrm.org/topics-tools/research/talent-acquisition-benchmarking-report) situe le délai moyen de pourvoir un poste toutes industries confondues entre 36 et 44 jours. Pour les rôles techniques et spécialisés dans les entreprises en croissance, [les Hiring Benchmarks de Greenhouse](https://www.greenhouse.com/guidance/hiring-benchmarks) montrent que la médiane du délai d'embauche s'approche plutôt de 47 jours.

Cela signifie que le collaborateur dont tu as besoin pour livrer le contrat signé cette semaine aurait dû être sourcé il y a cinq à sept semaines. Si tu ne vois que la pipeline commerciale, cet écart est totalement invisible.

## Un problème de visibilité, pas de capacité

Voici ce qui se passe généralement en pratique: ops a raison de dire que l'équipe est surchargée. Mais ils se trompent sur la cause, et sur la solution.

Le réflexe est de ralentir les ventes. "Ne prenons pas de nouveaux clients jusqu'à ce qu'on ait recruté." Cela semble rationnel. Mais si tu pouvais voir que quatre candidats sont en tour final et commenceront probablement dans trois semaines, le calcul change complètement. L'équipe est sous pression maintenant. Dans un mois, ce ne sera plus le cas.

La question n'est pas "est-ce qu'on ralentit les ventes?" La question est: "à quelle étape de quelle pipeline se trouve réellement le goulot d'étranglement?" Tu ne peux pas répondre à cette question si tu ne regardes qu'une seule pipeline.

## Ce qui change quand tu vois les deux en même temps

Quand les pipelines de ventes et de recrutement partagent la même vue, quelques choses changent immédiatement.

**Les décisions de timing s'améliorent.** Tu vois que tu as dix leads à l'étape proposition et cinq candidats à l'étape offre, et tu peux prendre une décision éclairée: accélérer, attendre ou recruter plus vite.

**Les prévisions deviennent honnêtes.** La planification de capacité à 30-100 personnes repose principalement sur l'intuition parce que les données vivent dans deux outils qui ne se parlent pas. Une vue partagée rend la dépendance visible: chaque contrat signé a besoin d'une équipe de livraison, et cette équipe vient d'une pipeline que tu devrais surveiller en parallèle.

**La panique diminue.** La plupart du stress que vivent les équipes ops dans cette phase n'est pas une crise de capacité. C'est une crise d'information. Quand tu peux voir que le recrutement est en bonne voie, un CRM plein n'est plus une menace, c'est un objectif.

## La solution n'est pas une autre intégration

Le réflexe évident est de connecter ton ATS à ton CRM ou vice versa. C'est ce que la plupart des équipes essaient en premier. Le résultat est un fouillis: modèles de données incompatibles, champs qui se mappent mal, tableaux de bord qui affichent des chiffres mais pas de contexte.

La solution plus propre est de modéliser les deux pipelines dans le même outil dès le départ. Les leads commerciaux et les candidats sont tous deux des personnes qui progressent à travers des étapes. Donne-leur un nom, une étape, une échéance, un propriétaire, et tu as décrit les deux. La seule différence est dans le résultat: signé versus embauché.

[La recherche Global Human Capital Trends de Deloitte](https://www.deloitte.com/global/en/insights/focus/human-capital-trends.html) montre que les organisations avec des cycles de planification des talents et des activités intégrés prennent leurs décisions RH significativement plus vite que celles qui planifient séparément. À l'échelle de 10 à 100 personnes, cette rapidité n'est pas un avantage concurrentiel. C'est la différence entre une croissance fluide et un recrutement en mode panique.

## Ops n'a pas tort de s'inquiéter

L'intuition "on ne peut pas prendre ça en plus" est souvent juste dans son principe. Les équipes de 30 à 80 personnes fonctionnent vraiment en limite de capacité. Le problème n'est pas qu'ops se trompe. C'est qu'ils prennent une décision sans les données dont ils ont besoin.

Quand la pipeline de recrutement est visible à côté de la pipeline commerciale, la question passe de "est-ce qu'on ralentit?" à "qu'est-ce qui doit être vrai pour qu'on puisse dire oui à ça?" C'est une conversation beaucoup plus utile à avoir.

[Commencer gratuitement →](https://leadgrid.io/signup)

---

# Combien de temps peut-on garder un candidat dans son vivier ? Les règles RGPD expliquées

URL: https://leadgrid.io/fr/blog/duree-conservation-vivier-candidats-rgpd
Locale: fr
Published: 2026-04-22
Author: Ralf Klein
Tags: recruitment, guides

Candidats refusés, presque-matchs, profils pour l'avenir : combien de temps peut-on légalement conserver leurs données dans un vivier sous le RGPD ?

Un candidat a postulé, est arrivé en finale, et n'a pas obtenu le poste. Tu veux le garder dans ta base pour la prochaine ouverture. Ce réflexe est juste. L'exécution doit être délibérée, car sous le RGPD, "garder quelqu'un dans le système" est une activité de traitement avec une base légale et une durée de conservation.

Voici ce que disent réellement les règles.

## Le standard : quatre semaines après le refus

Quand un candidat postule pour un poste spécifique et que tu le refuses, tu peux conserver ses données pendant **quatre semaines** après le refus. Cela couvre la période durant laquelle le candidat pourrait déposer une objection ou demander à consulter son dossier.

Après ces quatre semaines, si tu n'as pas d'autre base légale, les données doivent être supprimées.

Pas de consentement, pas de pipeline actif, pas de poste ouvert : suppression.

## Extension vers un vivier : tu as besoin d'un consentement explicite

Garder un candidat plus longtemps, dans un vivier, nécessite un **consentement explicite et éclairé**. Pas un consentement implicite. Pas une case pré-cochée. Pas une ligne générale enfouie dans ta politique de confidentialité.

Le candidat doit activement accepter :

- d'être intégré dans un vivier de candidats
- pour une durée de conservation spécifique que tu indiques en amont
- pour un objectif que tu décris clairement (postes futurs, pas du marketing général)

La pratique courante en France et dans toute l'UE est un **maximum d'un an** avec un seul consentement. Au bout d'un an, tu redemandes le consentement ou tu supprimes le dossier. Certaines organisations fixent la fenêtre à deux ans, ce qui est défendable pour les fonctions avec un cycle de recrutement lent, mais un an reste la valeur par défaut la plus sûre.

## Ce que la demande de consentement doit contenir

Une demande d'opt-in pour un vivier conforme au RGPD comporte trois éléments :

1. **Ce que tu conserves.** CV, coordonnées, notes d'entretien, résultats d'évaluation. Sois précis.
2. **Pourquoi.** Les futurs postes dans ton organisation correspondant au profil du candidat.
3. **Combien de temps.** Un an à compter de la date du consentement. Pas "pour une durée indéterminée."

Ajoute un mécanisme d'opt-out clair. Le candidat peut retirer son consentement à tout moment, et le retrait doit être aussi simple que le consentement.

Si tu utilises un outil de recrutement ou un ATS, vérifie s'il enregistre les horodatages de consentement et envoie des rappels de suppression automatiques à l'expiration de l'échéance. Le suivi manuel dans un tableur est un risque de conformité à toute échelle.

## Les presque-matchs et les viviers en pratique

La règle du vivier s'applique également à :

- Les candidats refusés directement
- Les candidats qui correspondaient bien mais ont perdu face à un profil plus fort
- Les candidats ayant retiré leur candidature en cours de processus

La base légale ne change pas selon à quel point ils étaient proches. S'ils ne sont plus dans un processus actif, tu as besoin de leur consentement ou tu supprimes.

Une nuance : si le candidat a envoyé une **candidature spontanée** sans poste spécifique, l'attente implicite est que tu la conserves pour une considération future. Cela seul ne constitue pas un consentement RGPD valide, mais rend la conversation d'opt-in plus simple.

## La position de la CNIL et des autorités européennes

La CNIL et les autres autorités de protection des données européennes ont publié des orientations confirmant que le stockage dans un vivier nécessite un consentement explicite et recommandent une durée de conservation maximale d'**un an**. Des organisations ont activement été sanctionnées pour avoir conservé des données de candidats sans base légale valide.

Si tu opères au-delà des frontières de l'UE, les règles sont cohérentes. Le RGPD s'applique de manière uniforme. Les autorités nationales peuvent différer légèrement sur l'accent de l'application, mais les exigences en matière de consentement et de conservation sont les mêmes.

## Ce qu'il faut intégrer dans ton processus

Trois étapes pratiques qui éliminent la plupart des risques de conformité :

**Au moment du refus :** envoie un e-mail unique et clair demandant si le candidat souhaite rejoindre ton vivier. Inclus ce que cela signifie, combien de temps ses données seront conservées, et un opt-in en un clic.

**Au moment du consentement :** consigne la date et ce qui a été accepté. Ton ATS ou CRM devrait le faire automatiquement. Si ce n'est pas le cas, c'est un problème d'outils qui mérite d'être résolu.

**A l'échéance :** rappel automatique lorsque la fenêtre de consentement expire. Soit tu redemandes le consentement, soit tu déclenches un workflow de suppression.

Ce n'est pas complexe à mettre en place. C'est facile à ignorer. L'ignorer, c'est ce qui crée l'exposition à la conformité.

## La version courte

Candidat refusé, pas de consentement : supprimer après quatre semaines. Vivier avec consentement : jusqu'à un an, ensuite redemander ou supprimer. Tout consigner. L'opt-out doit être simple.

C'est la règle complète. Le reste, c'est de l'implémentation.

---

# ATS ou CRM ? Les agences de recrutement posent la mauvaise question

URL: https://leadgrid.io/fr/blog/ats-vs-crm-pour-agences-de-recrutement
Locale: fr
Published: 2026-04-21
Author: Ralf Klein
Tags: recruitment, guides, pipeline

La plupart des agences de recrutement s'interrogent sans fin sur ATS vs CRM, puis finissent par acheter les deux. Voici pourquoi la question elle-même est le problème, et à quoi ressemble une stack plus légère.

Ton meilleur candidat de la semaine est dans l'ATS. Ton client le plus chaud est dans le CRM. Le jeudi, le client appelle et cherche exactement ce profil. Tu fais du copier-coller de notes entre deux onglets, tu envoies un suivi et tu espères que rien ne passe à travers les mailles. Le vendredi, le candidat accepte une offre ailleurs parce que ta réponse a mis deux jours à arriver.

C'est le problème ATS vs CRM en 15 secondes. Deux outils. Deux onglets. Un fossé.

## Deux outils conçus pour deux équipes différentes

L'ATS a été conçu pour les équipes RH internes qui gèrent des volumes élevés de recrutement. Il fait avancer les candidatures à travers des stages, stocke les CV et suit le time-to-hire. Le CRM a été conçu pour les équipes commerciales qui gèrent les relations clients. Il consigne les appels, rappelle de faire des suivis et suit les stages des deals.

Ni l'un ni l'autre n'a été conçu pour la personne qui effectue les deux mouvements à la fois : le recruteur d'une agence de 12 personnes qui doit faire correspondre le bon candidat à la bonne ouverture client avant que les deux parties ne se refroidissent. Quand tu boulonnes un ATS sur un CRM, ou que tu les fais tourner côte à côte, tu paies la surcharge de deux systèmes sans la clarté d'aucun des deux.

## La stack s'alourdit à mesure que les équipes rétrécissent

Le [rapport Gem 2026 Recruiting Benchmarks](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report), qui a suivi plus de 165 millions de candidats, a constaté que les équipes de recrutement traitent aujourd'hui 93 % de candidatures supplémentaires par rapport à 2021, tandis que les effectifs ont diminué de 14 %. On demande aux équipes de courir plus vite sur une piste qui s'est allongée.

Ajouter un deuxième système à cette charge de travail est la mauvaise réponse. Chaque synchronisation manuelle entre l'ATS et le CRM est du temps qu'un recruteur ne consacre pas au candidat ou au client. Chaque changement de contexte entre tableaux de bord est une fenêtre par laquelle quelque chose peut passer à travers les mailles.

## À quoi ressemble concrètement « passer à travers les mailles »

Le [rapport iHire 2025 State of Online Recruiting](https://www.ihire.com/about-us/press-room/articles/2025/ihire-releases-2025-state-of-online-recruiting-survey-results) a révélé que 59 % des chercheurs d'emploi citent le ghosting des employeurs comme leur principale frustration dans leur recherche d'emploi. Le ghosting est rarement délibéré. C'est ce qui arrive quand un recruteur perd la trace d'un candidat parce que ses données se trouvent dans un système différent de celui de la conversation client.

Du côté client, le même fossé se manifeste autrement. Un lead refroidit non pas parce qu'il n'y avait pas de bon candidat, mais parce que le recruteur était plongé dans l'ATS quand le client s'est tu, sans vue partagée sur l'état des choses.

Les [statistiques de recrutement SmartRecruiters 2025](https://www.smartrecruiters.com/blog/recruitment-statistics-for-2025/) chiffrent ça : 22 % des équipes talent signalent des difficultés à suivre les candidats dans leur propre processus de recrutement. Ce n'est pas un problème de recruteur. C'est un problème d'outil.

## La conclusion pratique

Avant de signer un autre contrat annuel, retrace tes cinq derniers placements et identifie où chaque candidat est resté plus de 48 heures sans point de contact. Dans la plupart des agences, ce délai survient à deux moments précis : juste après le premier entretien, quand le candidat passe de l'ATS à « envoyer un e-mail au client », et juste après qu'un client manifeste son intérêt, quand le recruteur retourne dans l'ATS pour récupérer les détails du candidat.

Ce sont les points de transfert. C'est là que ta pipeline fuit. Corriger l'outil est plus rapide que de former les gens à contourner la lacune.

## Une seule grille pour les deux mouvements

LeadGrid n'est pas un ATS. Ce n'est pas un CRM. C'est tout l'intérêt.

Il place candidats et clients dans la même grille de pipeline, avec la même logique de stages, le même modèle de propriété et la même visibilité. Quand un client ouvre un poste, tu vois immédiatement quels candidats sont déjà au bon stage. Quand un candidat progresse, le contexte client pertinent est à un clic. Pas de deuxième onglet vers lequel basculer, pas de synchronisation manuelle à lancer.

Les équipes de 5 à 50 personnes qui ont rebondi sur Salesforce, HubSpot, Greenhouse ou Lever découvrent souvent qu'elles n'avaient pas besoin d'une meilleure version de l'un de ces outils. Elles avaient besoin d'une seule grille qui gère les deux mouvements sans la surcharge de deux stacks.

**[Commencer gratuitement →](https://leadgrid.io/signup)**

---

# La moitié de ton pipeline s'évapore avant que tu ne t'en rendes compte

URL: https://leadgrid.io/fr/blog/la-moitie-du-pipeline-disparait-avant-le-signal
Locale: fr
Published: 2026-04-20
Author: Ralf Klein
Tags: recruitment, pipeline

47 % des candidats citent une mauvaise communication comme raison de leur abandon. La fuite n'est pas en haut de ton funnel. Elle est dans le passage de relais.

Un candidat solide passe deux tours d'entretiens. Le hiring manager est convaincu. Le recruteur est prêt à avancer. Puis une semaine passe. Puis deux. Personne n'a envoyé de suivi. Le candidat, pensant avoir été ignoré, accepte une offre ailleurs.

Ce n'est pas un cas isolé. [D'après le Ghosting Index 2025 de The Interview Guys](https://blog.theinterviewguys.com/the-2025-ghosting-index/), **61 % des chercheurs d'emploi ont été ghostés après un entretien**, soit une hausse de neuf points de pourcentage depuis début 2024. Le chiffre continue de grimper, non pas parce que les candidats s'impliquent moins, mais parce que les équipes qui les recrutent ne donnent plus signe de vie.

La fuite ne se situe pas en haut de ton funnel.

## La perte survient après l'intérêt

La plupart des équipes de recrutement se concentrent sur le sourcing. Elles optimisent les offres d'emploi, lancent des campagnes LinkedIn et peaufinent les formulaires de candidature. Pendant ce temps, le plus grand abandon se trouve plus bas dans la pipeline, dans des stages où le candidat avait déjà manifesté son intérêt.

Une étude de [The HT Group](https://www.thehtgroup.com/how-to-fix-top-candidate-drop-off-in-the-hiring-process/) est précise : la phase d'entretien représente à elle seule près d'un tiers de toutes les pertes de candidats, et la phase de planification en ajoute encore 20 %. Cela signifie que plus de la moitié de chaque candidat que tu as eu du mal à attirer abandonne après avoir déjà été engagé. Ils voulaient le poste. Ils se sont présentés. Ensuite, le processus les a perdus.

Un meilleur sourcing ne résoudra pas ça. Un passage de relais plus rapide, si.

## La mauvaise communication est la raison déclarée, pas une supposition

Quand les candidats se retirent, ils disent pourquoi. [Le Cronofy Candidate Expectations Report 2024](https://www.cronofy.com/reports/candidate-expectations-report-2024) a constaté que **47 % des candidats citent une mauvaise communication comme raison de leur retrait** d'un processus de recrutement. Pas le salaire. Pas les trajets. Pas une offre concurrente. La communication.

Le mécanisme est simple. Un recruteur termine l'appel de présélection et fait avancer le candidat. Le hiring manager reçoit le relais mais a six autres postes ouverts, une sprint review et une présentation au board cette semaine. Le candidat attend. Après sept jours de silence, 34 % supposent qu'ils ont déjà été refusés et arrêtent de répondre.

C'est là que ça fait mal : le candidat n'avait pas perdu d'intérêt. C'est le processus qui a perdu le candidat. Et au moment où quelqu'un remarque que le dossier est resté dans le même stage depuis dix jours, le candidat est depuis deux semaines dans un nouveau poste.

## Le passage de relais est là où la responsabilité s'effondre

Dans la plupart des scale-ups, le recruteur est propriétaire de la pipeline jusqu'à ce qu'un entretien soit planifié. Ensuite, la responsabilité passe, de façon informelle, au hiring manager. Sans passation explicite. Sans horodatage. Sans prochaine étape visible. Les deux supposent que l'autre s'en occupe.

Le taux d'acceptation des offres raconte toute l'histoire. [Les statistiques d'expérience candidat 2025 de CareerPlug](https://www.careerplug.com/candidate-experience-statistics/) indiquent que le taux d'acceptation des offres est tombé à 51 % au T2 2025, contre 74 % il y a seulement deux ans. Les équipes arrivent à l'étape de l'offre et perdent quand même le candidat. Ce n'est pas un problème de sourcing ni de rémunération. C'est un problème de visibilité.

Quand personne ne peut voir qui est responsable de la prochaine étape, la prochaine étape n'arrive pas.

## Analyse le stage où la responsabilité change de mains

Regarde ta pipeline et trouve le stage où le dernier horodatage d'activité est le plus ancien. C'est presque toujours le passage de relais du recruteur au hiring manager. Fais maintenant le même check pour chaque poste actif, pas seulement celui qui t'inquiète en ce moment.

Le schéma est cohérent dans toutes les équipes : la pipeline fuit le plus là où la responsabilité est supposée plutôt qu'assignée. Un candidat qui reste onze jours dans « entretien planifié » a un problème de responsabilité, pas un problème de candidat. La solution commence par rendre ça visible.

Signale chaque dossier dont la dernière activité remonte à plus de cinq jours ouvrés et dont la responsabilité est floue. Tu trouveras ton point de fuite. Ce ne sera pas aléatoire. Ça se regroupera au même stage, pour la même raison, à chaque fois.

## Ce ne sont pas les candidats qui te ghostent. C'est le passage de relais.

Gérer le recrutement dans un tableur pendant que le hiring manager suit ses notes par e-mail n'est pas une lacune de workflow. C'est une garantie structurelle que quelque chose va tomber à travers les mailles. Personne n'a de visibilité sur les deux, donc personne ne détecte le silence avant qu'il coûte un recrutement.

LeadGrid place les candidats dans un cockpit unique avec une propriété de stage explicite et un marqueur de dernière activité visible pour chaque dossier. Quand un candidat reste trop longtemps sans prochaine étape, c'est visible pour tous ceux qui ont besoin de le voir, pas enterré dans la boîte mail de quelqu'un ni caché dans un onglet oublié.

**[Commencer gratuitement →](https://leadgrid.io/signup)**

---

# Cinq choses que tu automatises quand chaque action du pipeline est un appel REST

URL: https://leadgrid.io/fr/blog/automatiser-le-pipeline-avec-rest-api
Locale: fr
Published: 2026-04-18
Author: Ralf Klein
Tags: api, engineering

LeadGrid expose chaque action de l'interface via une REST API documentée. Voici cinq automatisations que tu peux mettre en prod dans un après-midi, sans exporter un seul CSV.

Chaque action de l'interface LeadGrid, créer un dossier, déplacer une étape, ajouter une note, assigner un membre, est un appel REST documenté. Ce n'est pas une fonctionnalité ; c'est la forme même du produit. Cela signifie que la frontière entre « ce que fait LeadGrid » et « ce que fait ton propre code » n'est qu'une requête HTTP.

Voici cinq automatisations qui prennent moins d'un après-midi dès que tu cesses de voir ton CRM comme quelque chose sur lequel tu cliques.

## 1. Créer automatiquement des dossiers depuis les e-mails entrants

Chaque workspace reçoit une adresse inbound. Transfère-y un lead ou un CV, LeadGrid parse l'expéditeur et la pièce jointe, crée un dossier structuré et envoie un webhook vers ta couche d'automatisation.

Pas de surveillance manuelle d'une boîte partagée. Pas d'upload CSV. Ton AE transfère une intro client, et quand il actualise la grille, le dossier est déjà assigné, tagué et dans le bon pipeline.

## 2. Notifications Slack contextualisées par étape

Webhook `dossier.stage_changed` → ta fonction → message Slack. Le body contient le nom du dossier, l'ancienne étape, la nouvelle étape, le responsable et la deadline. Tu écris le filtre : `if new_stage == "Interview" and dossier.type == "candidate"` → `#recruitment-live`. Les deals sales suivent un canal différent et un seuil différent.

Tu ne reconfigures pas les notifications dans une UI de fournisseur. Tu exprimes une règle dans le code, versionnée avec le reste de ton infra.

## 3. Des escalades de deadline qui escaladent vraiment

LeadGrid intègre des deadlines. Ce qui change, c'est que tu peux t'abonner à `dossier.deadline_missed` et réagir selon le fonctionnement de *ton* équipe : notifier le manager du responsable, poster dans le canal d'escalade, ouvrir un ticket Linear, ou déclencher un rappel calendrier 24 heures avant.

L'API te permet de composer des escalades à partir des services que tu fais déjà tourner. Pas de nouveau dashboard à surveiller.

## 4. Maintenir ton data warehouse à jour sans ETL

Chaque événement de dossier, créé, déplacé, clôturé, commenté, est disponible sous forme de webhook. Envoie-les dans une queue, écris-les dans ton warehouse, et ta couche BI est à jour en quelques secondes plutôt qu'avec le décalage de 24 heures d'une sync nocturne.

```ts
// pseudo-handler
app.post("/webhooks/leadgrid", async (req) => {
  const sig = req.headers["x-leadgrid-signature"];
  verify(sig, req.rawBody);            // HMAC, documenté
  await queue.publish("leadgrid", req.body);
  return { ok: true };
});
```

Pas de pipeline ETL, pas de job planifié, pas de « oh, la sync est encore cassée ». La source de vérité pousse, ton warehouse écoute.

## 5. Des agents qui font avancer les pipelines tout seuls

C'est là que ça devient intéressant. Parce que chaque action est un appel REST avec une spec OpenAPI propre, un LLM peut piloter LeadGrid. Un agent Claude ou GPT peut :

- Lire le CV d'un(e) candidat(e) depuis le storage
- Rédiger un résumé IA et le poster comme note
- Déplacer le dossier à l'étape suivante si le résumé correspond au poste
- Envoyer au/à la candidat(e) une prochaine étape structurée par e-mail via le domaine expéditeur du workspace

Tout ça sans scraping. L'agent appelle `POST /v1/dossiers/<id>/notes` exactement comme un humain clique sur « Ajouter une note ».

Nous ne vendons pas une fonctionnalité IA fermée par-dessus un CRM fermé. Nous vendons un pipeline programmable, et c'est toi qui décides quelles boucles tournent avec des humains, lesquelles avec de l'automatisation et lesquelles avec des agents.

## L'essentiel

Tout CRM peut produire un CSV. Très peu sont conçus pour que toute la surface soit aussi appelable qu'une bibliothèque. LeadGrid, si. Lis la spec sur [`/docs/api`](/docs/api), récupère une clé API dans les paramètres de ton workspace et mets en prod ta première automatisation dans l'après-midi.

[Commencer gratuitement →](/signup)

---

# Deux pipelines, un goulot d'étranglement

URL: https://leadgrid.io/fr/blog/deux-pipelines-un-goulot
Locale: fr
Published: 2026-04-16
Author: Ralf Klein
Tags: pipeline, sales, recruitment

La plupart des scale-ups font tourner leur Sales et leur recrutement sur deux stacks qui ne se parlent jamais. Un seul hiring manager devient simultanément le goulot d'étranglement des deux pipelines.

Un vendredi après-midi, dans presque chaque scale-up avec lequel on travaille, deux choses échouent en même temps dans le même bâtiment, et personne ne réalise que c'est en fait le même problème. Un lead enterprise solide s'échappe parce que l'AE attend que le hiring manager confirme la capacité avant de s'engager sur une échéance. Deux étages plus bas, un ingénieur senior que la recruteuse a soigneusement suivi pendant trois semaines se fait silencieux, parce que ce même hiring manager n'a pas rappelé pour l'entretien de calibration. Le lead fuit. Le candidat refroidit. Le lundi matin, les deux équipes rapportent la perte dans leur propre standup, sur leur propre board, avec leur propre explication.

Ce ne sont pas deux problèmes distincts. C'est un seul problème, vu deux fois, par des équipes qui ne peuvent pas se voir.

## La forme est identique, les stacks ne le sont pas

Chaque scale-up au-delà d'une certaine taille fait tourner deux processus qui se ressemblent sur le papier. Sales a des leads qui passent de qualified à discovery, puis à proposal, puis à close. Le recrutement a des candidat(e)s qui passent de sourced à screen, puis à interview, puis à offer. Même forme de pipeline, mêmes étapes dans l'esprit, même modèle d'ownership, même notion de last-touch et next-touch. Câble l'un sur HubSpot ou Pipedrive, l'autre sur Greenhouse ou Workable, et tu obtiens deux processus qui ne se voient jamais. Les personnes qui bloquent l'un bloquent souvent l'autre. Le contexte qui compte dans l'un compte souvent dans l'autre. Aucun outil ne le sait.

## Les données sont déjà inconfortables

Le coût structurel de la fragmentation est quantifié. Un récent [benchmark Gartner Sales Operations](https://www.gartner.com/en/sales/trends/2025-sales-operations-leadership-vision) a constaté que les équipes revenue operations supportent désormais couramment cinq groupes ou plus et passent 68 % de leur temps sur des tâches hors relation client. Les deux tiers de la bande passante ops partent en coordination, en colle entre outils, en réconciliation, et à décoder lentement ce qu'un système différent voulait dire en changeant un statut. Et ça, avant même que quelqu'un demande si les deux processus adjacents dans ton entreprise, Sales et recrutement, partagent ne serait-ce qu'une définition d'étape.

Côté candidat(e)s, la fuite est plus rapide et plus visible. Les analyses sectorielles sur [le processus de recrutement en 2025](https://blog.theinterviewguys.com/state-of-the-hiring-process-in-2025/) pointent une dynamique sans détour : les meilleurs candidats quittent le marché en environ 10 jours, et le taux d'abandon des candidatures avoisine 60 % quand le processus traîne. Quand Sales obtient la réponse commerciale dont il a besoin et que le recrutement attend encore, le candidat a déjà dit oui à quelqu'un d'autre. Ton AE ne le sait pas. Ta recruteuse le sait, mais n'a nulle part où le signaler de façon visible pour l'AE.

L'inverse prouve l'argument. [HubSpot Research](https://www.hubspot.com/state-of-marketing) a montré que quand Sales et Customer Success partagent un cadre opérationnel commun, la rétention grimpe de 36 % et les taux de closing de 38 %. La leçon ne porte pas spécifiquement sur le CS, elle porte sur la proximité. Deux équipes qui travaillent la même relation client performent radicalement mieux quand elles peuvent se voir. Il n'existe pas encore de benchmark publié pour l'alignement Sales + recrutement, parce que presque personne ne l'a mesuré, mais le mécanisme est le même. La proximité récompensée une fois se récompense deux fois.

## L'anatomie d'un échec de handoff

Chaque fuite de handoff qu'on a tracée dans un scale-up se ramène à l'une de trois mécaniques.

La première est **l'ownership périmé**. Un lead ou un(e) candidat(e) a un nom accolé. Cette personne a entre-temps changé d'équipe, pris des vacances, ou s'est discrètement désengagée du compte. Le record n'est pas délibérément faux. Il est faux parce que rien dans le stack n'a jamais forcé une mise à jour. Sur un stack à un seul processus, c'est douloureux. Sur deux processus qui se bloquent mutuellement, c'est multiplicatif.

La deuxième est **l'étape invisible**. Un lead passe de « qualified » à « discovery » dans le CRM. La recruteuse ne le voit pas. Pourquoi le verrait-elle ? Le lead est un artefact Sales. Mais ce même compte a aussi un hiring manager qui est l'un des quatre décideurs du deal. Quand Sales déplace le record, le recrutement ne sait pas que la température vient de changer. Un entretien de calibration qui aurait pu avoir lieu cette semaine n'a finalement lieu que dans trois semaines, après que l'étape s'est déjà bloquée.

La troisième, et la plus coûteuse, est le **goulot cross-motion**. Une personne, généralement un hiring manager ou un VP Engineering, est simultanément la limite de débit de deux pipelines différents. L'équipe Sales attend qu'elle valide les effectifs avant de pouvoir s'engager sur le périmètre. L'équipe recrutement attend qu'elle signe l'offre avant qu'un candidat accepte. Chaque équipe escalade séparément. Chaque équipe ajoute à la pile que cette même personne doit traiter. Si l'une des deux équipes avait vu la file d'attente de l'autre, elle aurait regroupé la conversation. Aucune ne l'a vue.

## Ce que change vraiment un cockpit partagé

L'ownership devient un seul champ, pas deux. La même personne, inscrite comme owner, est reportée dans les deux processus pour les comptes où c'est la même personne. Les étapes deviennent lisibles d'une équipe à l'autre. Un lead qui passe à « proposal » signale le record de recrutement pour la même entreprise, parce que les rôles à pourvoir pour ce compte viennent de devenir urgents. Les goulots apparaissent comme des goulots, pas comme deux demandes de reprogrammation sans lien. Le hiring manager voit ce qui est en attente des deux côtés dans une seule vue et prend une décision au lieu d'être relancé deux fois.

C'est ce que ça veut dire de mettre deux pipelines dans une seule grille, et c'est la raison d'être de LeadGrid. Non pas parce que les équipes Sales sont fatiguées des CRMs et les équipes recrutement de leurs ATSes, même si c'est vrai dans les deux cas. Mais parce que le handoff qui casse un scale-up ne se trouve pas à l'intérieur de l'un ou l'autre outil, il se trouve entre les deux.

## L'audit à faire lundi

Tu n'as pas besoin d'une nouvelle plateforme pour commencer. Tu dois trouver où tes handoffs fuient vraiment. Quelques choses à tester la première semaine, avec ce que tu as déjà.

Arrive lundi matin et liste tous les leads qui ont stagné la semaine dernière, ainsi que tous les candidat(e)s qui ont stagné la semaine dernière. Mets-les dans le même tableur, triés par la personne nommée qui attend quelque chose. Compte combien de fois la même personne apparaît dans les deux colonnes. Ce chiffre est ton taux de goulot cross-motion. Chez la plupart des scale-ups qu'on a accompagnés, il se situe entre 15 et 30 %. C'est 15 à 30 % de tes blocages qui ne sont ni un problème Sales ni un problème recrutement, c'est un problème de file d'attente.

Vérifie ensuite tes champs d'ownership. Pour chaque record actif dans les deux systèmes, demande-toi si la personne listée a répondu à des e-mails au cours des cinq derniers jours ouvrés. Le pourcentage qui échoue est ton taux d'ownership périmé. Tout ce qui dépasse 20 % signifie que le record te ment au moment où tu en as le plus besoin.

Enfin, prends un compte ouvert où l'entreprise est à la fois un deal et une cible de recrutement. Aligne le journal d'activité Sales et le journal d'activité recrutement côte à côte. Remarque chaque moment où une équipe aurait pu faire gagner une journée à l'autre. Cette liste, c'est ton déficit de handoff.

## La solution, c'est une grille, pas un CRM plus gros

Si les revenus fuient à la jonction entre Sales et recrutement, ce n'est pas parce que ton CRM est mauvais ou ton ATS incorrect. C'est parce que ton processus est une seule chose et ton stack en est deux. La solution n'est pas un CRM plus grand. Ce n'est pas un ATS plus profond. C'est une grille qui montre les deux pipelines avec le même vocabulaire, le même champ owner, et la même notion de ce que signifie « bloqué ». Donne aux responsables ops une seule vue du processus, et le processus arrête de laisser tomber les gens par terre.

**[Commencer gratuitement →](https://leadgrid.io/signup)**

---

# Pourquoi nous avons construit LeadGrid comme une seule API pour deux pipelines

URL: https://leadgrid.io/fr/blog/pourquoi-nous-avons-construit-leadgrid
Locale: fr
Published: 2026-04-14
Author: Ralf Klein
Tags: product, api

La plupart des équipes growth utilisent un CRM et un ATS pour le même mouvement. Voilà ce qui s'effondre quand tu modélises sales et recrutement sur un seul modèle de données, et pourquoi on l'a rendu programmable par défaut.

Toutes les équipes growth avec lesquelles j'ai travaillé font la même chose deux fois. Sales a un CRM. Le recrutement a un ATS. Même forme de pipeline, entrée, qualification, progression, closing, mais sur deux stacks qui ne se parlent pas.

On a construit LeadGrid parce que cette séparation est un choix, pas une contrainte.

## Le modèle de données est le même

Un lead et un candidat sont tous les deux des *personnes qui avancent dans des étapes*. Donne-leur un nom, une étape, une deadline, un responsable, un ensemble de notes, et tu as décrit les deux. Les verbes sont identiques : créer, assigner, faire avancer, commenter, clore.

L'industrie a construit deux catégories de produits autour de ça parce que c'était profitable, pas parce que le travail sous-jacent est différent. Les équipes se retrouvent à payer deux fournisseurs, intégrer deux APIs, se former sur deux interfaces, et réconcilier deux sources de vérité, pour suivre la même chose deux fois.

## Ce qui s'effondre quand tu unifie

Faire tourner une seule plateforme pour les deux pipelines produit trois effets concrets :

- **Les transferts n'échouent plus.** Sales promet la livraison. Le recrutement trouve les personnes qui livrent. Quand les deux regardent le même grid, les escalades se passent avant que le candidat parte ou que le deal glisse.
- **Le coût des outils est divisé par deux.** Un seul workspace, une seule ligne de facturation, un seul modèle de permissions. Sales et recrutement arrêtent de se disputer sur quel outil fait foi, c'est le même.
- **Le reporting devient honnête.** Time-to-hire et time-to-close vivent dans la même base de données. Tu peux enfin répondre à la question « est-ce qu'on a raté ce deal parce qu'on n'avait pas la bonne personne ? » sans passer par un spreadsheet.

## API-first, pas API en arrière-pensée

L'autre choix délibéré : chaque action que fait l'interface est un appel REST. Créer un dossier, changer d'étape, ajouter une note, assigner un membre, tout est scriptable, tout est documenté sur [`/docs/api`](/docs/api).

Ça devrait être la norme, et pourtant : la plupart des CRMs réservent leurs meilleures fonctionnalités aux tiers supérieurs, enveloppent l'API dans des rate limits conçues pour te pousser vers les professional services, ou refusent de documenter les webhooks. On voulait l'inverse : l'API est le produit, l'interface est juste un moyen pratique de l'utiliser.

La conséquence concrète : tes automatisations se moquent que quelque chose soit un lead ou un candidat. Tu écris une intégration une fois, et elle fonctionne sur les deux pipelines. Claude, n8n, Zapier, ton propre backend, même forme d'endpoint, même auth, même schéma de webhook.

## Gratuit pour toujours sur le plan gratuit

Une dernière chose. LeadGrid est gratuit pour toujours sur le plan gratuit, pas un essai de 14 jours, pas une promo limitée dans le temps. Tu peux faire tourner une vraie équipe dessus, construire de vrais pipelines, et ne jamais nous payer un centime. Les plans payants débloquent plus de seats, de dossiers actifs, de flows et de débit API quand tu dépasses les limites gratuites.

On préfère te voir construire sur la plateforme plutôt que regarder un compte à rebours s'écouler.

[Commencer gratuitement →](/signup)

---

## ES posts

# Lead scoring sin ML: por qué una scorecard de cinco reglas gana para la mayoría de los equipos

URL: https://leadgrid.io/es/blog/lead-scoring-sin-ml-scorecard-cinco-reglas
Locale: es
Published: 2026-05-13
Author: Ralf Klein
Tags: sales, guides

La mayoría de los equipos que adoptan lead scoring con machine learning obtendrían el 80% del valor con una scorecard de cinco reglas. Cuándo dar el salto, y cuándo no.

Cada trimestre aparece otro equipo de ventas diciéndome que necesita lead scoring con AI. Escarbamos un poco, y lo que realmente necesitan es una scorecard limpia de cinco reglas con pesos negativos y una función de decaimiento. El modelo ML es el titular, pero la mejora real está en lo básico que casi nadie se molesta en montar primero.

No es una postura contraria. Es lo mismo que aparece enterrado al final de cualquier guía honesta de ML. El problema es que la versión por reglas suena aburrida, así que los equipos la saltan y pagan por un modelo que aprende lo equivocado a partir de datos sucios.

## El problema matemático que la mayoría de los equipos tiene primero

Un modelo predictivo necesita suficientes ejemplos closed-won y closed-lost de los que aprender. La mayoría de los equipos B2B aún no tienen ese volumen. Según la [Prospeo guide on AI versus traditional lead scoring](https://prospeo.io/s/ai-lead-scoring-vs-traditional-lead-scoring), el umbral práctico está en torno a 1.000 leads al año, 100 deals cerrados y entre 12 y 24 meses de datos limpios en el CRM antes de que un modelo ML produzca un score defendible. Por debajo de eso, un modelo basado en reglas bien construido le gana cada vez a un modelo AI mal entrenado.

Esa es la parte que los decks de los vendors omiten. Un modelo entrenado con 60 conversiones y un año de definiciones de etapa inconsistentes no aprende a tu comprador, aprende tu problema de higiene de datos.

## Por qué la versión por reglas suele ganar

Forrester lleva años siendo claro al respecto. El [Forrester piece on what lead scoring actually is](https://www.forrester.com/blogs/what-is-lead-scoring-anyway/) lo señala: la mayoría de los modelos de scoring en producción se construyen sobre suposiciones y estimaciones aleatorias de la propensión de compra, no sobre análisis real. Cambiar eso por un modelo ML entrenado sobre los mismos inputs frágiles no arregla los inputs, solo hace que el score sea más difícil de discutir.

Una scorecard simple es auditable, fácil de cambiar y obliga a los equipos de ventas y marketing a ponerse de acuerdo sobre qué significa "qualified" antes de ponerla en producción. Esa alineación es de donde sale la mayor parte de la mejora real. El [Clueless Company breakdown of failing lead scoring models](https://www.theclueless.company/lead-scoring-techniques/) lo dice bien: la razón más común por la que fallan los proyectos de scoring no es la mala lógica, es que ventas no confía en el score, así que los reps siguen trabajando con quienes ya trabajaban.

No puedes construir confianza en una caja negra. Sí puedes construirla en cinco reglas que se leen de una pizarra.

## La scorecard de cinco reglas

Esta es la versión que recomendamos a cualquier cliente de LeadGrid por debajo del umbral ML. Cabe en una pantalla y se explica sola.

```yaml
fit_score:
  icp_company_size:    { match: +20, miss: -15 }
  icp_industry:        { match: +15, miss: -10 }
  decision_maker_role: { match: +20, miss: -10 }

intent_score:
  pricing_page_visit:  +20
  demo_request:        +30
  three_emails_opened: +5
  inactivity_per_week: -5

threshold_for_sales_handoff: 50
```

Cinco reglas, dos pesos negativos, una regla de decaimiento. Eso es todo. La estructura está tomada de la [Reform guide on common lead scoring mistakes](https://www.reform.app/blog/common-lead-scoring-mistakes-and-fixes), que es directa sobre los dos modos de fallo que una scorecard básica tiene que arreglar: seguir demasiadas señales crea ruido, y asignar solo puntuaciones positivas inunda el CRM de leads fríos que nadie limpia.

La regla de decaimiento pesa más de lo que la gente cree. El [Breadcrumbs B2B lead scoring framework for 2026](https://breadcrumbs.io/blog/b2b-lead-scoring/) recomienda restar puntos por cada semana de inactividad, precisamente para que los MQLs zombies no se queden arriba de la cola mientras un lead más caliente de esta mañana queda por debajo. Sin decaimiento, tu scorecard es una tabla de récords, no una cola.

## Cuándo graduarse a ML

Existe un umbral real en el que el scoring ML se gana su complejidad. Lo has cruzado cuando tres cosas son ciertas a la vez.

Tienes al menos 100 registros closed-won limpios y 100 closed-lost limpios, con definiciones de etapa consistentes en todo ese historial. El [Landbase lead scoring statistics roundup](https://www.landbase.com/blog/lead-scoring-statistics) cita datos de Forrester que muestran 38% más de conversión y 28% de ciclos de venta más cortos para equipos con AI scoring, pero esos números vienen de equipos que tenían la higiene de datos para entrenar. Sin esa higiene, el modelo aprende tu CRM desordenado, no a tu comprador.

Tu ciclo de venta es lo bastante complejo como para que los humanos ya no puedan retener las variables en la cabeza. Los deals enterprise multi-stakeholder con más de 18 touchpoints a lo largo de seis meses son un problema distinto al de un funnel SaaS self-serve con una puerta de free trial. ML se gana su sitio en la forma compleja, no en la simple.

Ya has lanzado la versión basada en reglas y puedes nombrar exactamente qué regla va a batir el modelo ML. Si no puedes nombrarla, el modelo ML no resuelve un problema que tú tengas, resuelve uno que tiene un vendor.

## El híbrido honesto

El patrón que funciona es scoring basado en reglas como capa base, ML como capa por encima cuando ya tienes los datos para justificarlo. Las reglas te dan un score en el que los reps confían desde el primer día. La capa ML, una vez lanzada, ajusta el score con patrones que las reglas no ven, pero el score legible para humanos sigue en la UI.

Hacia eso apuntaban también los [SiriusDecisions data on lead scoring adoption](https://salesdorado.com/en/sales-qualification/lead-scoring-useless/) cuando encontraron que el 68% de las empresas hacía lead scoring pero solo el 40% de los comerciales le veía valor. Los equipos en ese 40% tenían un modelo que los reps podían explicar. Los del 60% restante tenían un modelo en el que los reps no creían.

Construye primero la versión de cinco reglas. Gánate el upgrade a ML cuando tus datos y tu equipo de ventas estén listos. La mayoría de los equipos nunca necesitan dar ese segundo paso, y eso está bien.

[Empezar gratis →](https://leadgrid.io/signup)

---

# El problema del volumen de candidaturas para reclutadores: 93% más candidaturas, misma plantilla

URL: https://leadgrid.io/es/blog/problema-volumen-candidaturas-reclutadores
Locale: es
Published: 2026-04-29
Author: Ralf Klein
Tags: recruitment, guides

Los reclutadores gestionan un 93% más de candidaturas con equipos un 14% más pequeños. Contratar más reclutadores no es la solución. Rediseña el proceso.

Los equipos de reclutamiento están corriendo procesos de 2021 sobre volumen de 2026. Según [Gem's 2026 Recruiting Benchmarks Report](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report), los reclutadores gestionan ahora un 93% más de candidaturas y un 40% más de vacantes que hace cinco años, mientras que los equipos se han reducido un 14%. Las contrataciones por reclutador han caído un 43%. Las cuentas no salen, y añadir plantilla no es la solución.

## Por qué contratar más reclutadores no es la respuesta

Doblar el volumen con un equipo un 14% más pequeño sugeriría doblar el equipo. Tres razones por las que eso falla.

Primero, finanzas no aprueba 2x contrataciones de reclutadores mientras los organigramas de engineering se aplanan. El coste por contratación ya está al alza en la mayoría de segmentos según los [benchmarks Gem 2026](https://www.gem.com/resource/recruiting-benchmarks). Añadir plazas empeora la situación sin cambiar la tasa de conversión.

Segundo, el cuello de botella se ha movido. La mayoría de equipos tratan el volumen como un problema de cribado. No lo es. Los mismos datos de Gem muestran que solo el 0,5% de los candidatos son contratados, lo que significa que el 99,5% del tiempo del reclutador revisando currículums se desperdicia en agregado. Más reclutadores significa más horas perdidas, no contrataciones más rápidas.

Tercero, la fuente con mejor conversión no son nuevos candidatos en absoluto. Gem reporta que el 46% de las contrataciones sourced vienen ahora de candidato/as redescubierto/as ya en el CRM o ATS, frente al 26% en 2021. Los equipos que doblan la apuesta por la revisión inbound están optimizando el peor flow que tienen.

## Dónde se fuga el tiempo realmente

Haz una auditoría de tiempo de una semana en cualquier equipo con mucho inbound. El patrón se repite:

- **Revisión de currículums a paridad.** Cada candidato recibe la misma atención de primer pase sin importar la fuente. Un LinkedIn Easy Apply recibe los mismos 30 segundos que una referral. Esa es la asignación equivocada.
- **Sin niveles de scoring.** Equipos sin una regla dura de auto-descalificación y sin regla de fast-track terminan leyendo cada currículum mediocre en su totalidad.
- **Llamadas de cribado síncronas.** Una llamada de 20 minutos para cada candidato/a "quizás" consume el día del reclutador incluso cuando el 70% no avanzará.
- **Sourcing en frío mientras el inbound se acumula.** Rastrear candidato/as existentes del CRM se deja al tiempo libre que nunca aparece.

Ninguno de estos es un problema de plantilla. Son problemas de proceso y herramientas.

## Movimientos de proceso que escalan sin cuerpos

**Redescubre antes de sourcear.** [Los datos de SmartRecruiters 2025 sobre reclutamiento](https://www.smartrecruiters.com/blog/recruitment-statistics-for-2025/) respaldan el hallazgo de Gem de que las pipelines históricas convierten dos a tres veces más que el sourcing en frío. Antes de publicar una vacante, consulta el CRM por candidatos previos que coincidan con un puesto similar. Eso es una búsqueda, no 200 revisiones de currículum.

**Estratifica el flow inbound.** Construye tres carriles: auto-descalificación en requisitos duros, fast-track en score más referral o estatus alumni, revisión manual para el resto. Las reglas de carril van en el expediente, no en la cabeza del reclutador. El carril central es donde la plantilla se siente cara. Reducirlo a la mitad subiendo el listón normalmente pierde cero contrataciones y libera una semana-reclutador completa por puesto.

**Cribar async a los "quizás".** Reemplaza la llamada de 20 minutos "¿eres real?" con una pregunta escrita asíncrona: tres preguntas, plazo de 48 horas. Los candidato/as que no responden se autoexcluyen. Los que responden dan un registro escrito que los hiring managers leen en 90 segundos.

**Lleva la automatización al expediente, no alrededor.** Cuando el aviso de siguiente paso, el correo de rechazo, el enlace de planificación y el handoff al hiring manager viven todos en el registro del candidato, los reclutadores dejan de cambiar de contexto entre cinco herramientas. El [Cronofy Candidate Expectations Report 2024](https://www.cronofy.com/reports/candidate-expectations-report-2024) encontró que los candidatos esperan una respuesta en 48 horas, y que las tasas de abandono se disparan más allá de esa ventana. Una herramienta que mantiene la siguiente acción a un clic es lo que hace posibles las 48 horas a volumen.

## Qué medir en lugar del tiempo de contratación

El tiempo de contratación agregado es demasiado grueso para depurar un problema de volumen. Tres métricas que separan la señal:

- **Tiempo-en-etapa por fuente.** Candidatos inbound estancados 8 días en cribado mientras los referrals pasan en 2 te dice que las reglas de carril están mal, no que el flow es lento.
- **Tasa de contratación por carril.** Si tu carril de revisión manual convierte al 0,4% y tu carril fast-track al 12%, el carril manual no merece su tiempo de reclutador.
- **Tasa de aciertos por redescubrimiento.** ¿Qué proporción de las contrataciones vino de candidatos ya en el sistema? Si está por debajo del [benchmark Gem del 46%](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report), tu motor de sourcing no está usando sus propios datos.

Cada una es una etiqueta en el expediente del candidato y una etapa en la pipeline. Ninguna requiere una herramienta nueva, y ninguna requiere un equipo mayor.

## El marco

El problema de volumen no es un problema de plantilla. Es un problema de proceso disfrazado de problema de plantilla. Los equipos que aceptan la nueva base (93% más candidaturas, 14% menos reclutadores) y rediseñan en torno a ella entregan contrataciones a la misma velocidad. Los equipos que presionan por más plantilla pierden la conversación de presupuesto y conservan el cuello de botella.

Construye el expediente para que un reclutador pueda mover a un candidato en un clic. Estratifica el flow para que el 80% de los candidatos se decidan en 30 segundos. Rastrea el CRM antes de sourcear. La cifra del volumen no va a bajar, pero el tiempo por candidato/a sí.

[Empezar gratis →](https://leadgrid.io/signup)

---

# Por qué el análisis de drop-off de pipeline funciona igual en ventas y reclutamiento

URL: https://leadgrid.io/es/blog/analisis-drop-off-pipeline-funciona-igual
Locale: es
Published: 2026-04-28
Author: Ralf Klein
Tags: pipeline, guides

Ventas y reclutamiento parecen pipelines distintos. La matemática del drop-off es idéntica. Mismos diagnósticos, mismas correcciones, solo cambian las etiquetas de etapa.

La mayoría de equipos tratan el drop-off de ventas y el drop-off de reclutamiento como problemas separados. Sacan informes distintos, hacen preguntas distintas y contratan especialistas distintos para arreglar cada uno. Esa división es sobre todo cultural. La matemática es idéntica.

Un pipeline es una secuencia de etapas. La gente entra arriba, avanza etapa por etapa y o cierra o cae. El drop-off es el porcentaje que cae en cada transición. Una vez aceptas ese marco, ventas y reclutamiento dejan de ser problemas distintos y pasan a ser el mismo problema con otras etiquetas en las cajas.

## A la matemática del embudo le da igual cómo llames a las etapas

En ventas, las etapas canónicas son Lead, MQL, SQL, Opportunity, Closed Won. En reclutamiento son Solicitud, Cribado, Entrevista, Oferta, Contratación. Cinco etapas por pipeline. Cuatro transiciones por pipeline. En cada transición, un porcentaje continúa y otro cae.

Según el [Glue Up 2026 sales funnel benchmarks](https://www.glueup.com/blog/sales-funnel-conversion-rate-benchmarks), el embudo de ventas B2B típico convierte Lead a MQL al 25 a 35%, MQL a SQL al 13 a 26%, SQL a Opportunity al 50 a 62%, y Opportunity a Closed Deal al 15 a 30%. Si los multiplicas, te sale una conversión de extremo a extremo de aproximadamente 0,3% a 1,6%.

En reclutamiento, el [CareerPlug's 2025 Recruiting Metrics Report](https://www.careerplug.com/blog/recruiting-metrics-report/) siguió más de 10 millones de solicitudes y encontró que aproximadamente el 3% de los candidatos llega a entrevista y menos del 1% acaba contratado. Misma forma. Mismos órdenes de magnitud. La mayor caída en ambos embudos se da en el paso de cualificación: MQL a SQL en ventas, Solicitud a Cribado en reclutamiento.

## Los patrones diagnósticos también son los mismos

Cuando el drop-off de ventas se dispara entre MQL y SQL, suelen ser ciertas tres cosas: el volumen de leads creció más rápido que la capacidad del rep, los criterios de cualificación están desalineados entre marketing y ventas, o el tiempo de respuesta se ha resbalado. Cuando el drop-off de reclutamiento se dispara entre Solicitud y Cribado, suelen ser ciertas tres cosas: el volumen de solicitudes creció más rápido que la capacidad del recruiter, los criterios de cribado están desalineados entre hiring manager y recruiter, o el tiempo de respuesta se ha resbalado.

Relee esos dos párrafos. Los mismos tres diagnósticos. El [Ashby 2025 Talent Trends Report](https://www.ashbyhq.com/resources) muestra que los equipos de reclutamiento manejan hoy casi el doble de volumen de solicitudes que en 2021 con la misma plantilla, lo que produce exactamente el bottleneck que un equipo de ventas obtiene cuando los leads se triplican y los reps se quedan iguales.

Las correcciones también riman. En ventas aprietas los criterios de cualificación, pones SLA al tiempo de respuesta, o inviertes en scoring antes del routing. En reclutamiento aprietas los criterios de cribado, pones SLA al tiempo de respuesta, o inviertes en pre-cribado antes de la revisión del recruiter. El verbo es "filtra o acelera". Ese verbo funciona en ambos pipelines.

## Dónde se rompe el análisis (y por qué)

La razón por la que la mayoría de equipos pierden esa simetría es que los datos viven en sistemas distintos. El CRM guarda el pipeline de ventas. El ATS guarda el pipeline de reclutamiento. Los informes se construyen por sistema, por gente que solo ve un embudo. Así que cuando el drop-off de ventas y el de reclutamiento están causados por lo mismo de fondo (la empresa metió más demanda de la capacidad que construyó), nadie lo ve, porque nadie mira ambos a la vez.

La [investigación de SHRM sobre experiencia del candidato](https://www.shrm.org/topics-tools/news/talent-acquisition) encuentra que el 60% de los candidatos abandonan solicitudes por fricción de proceso. El mismo porcentaje exacto de leads B2B abandonan conversaciones de ventas por la misma razón: demasiados pasos, demasiado lento, demasiado poco claro. Un número, una causa raíz, dos informes que nadie conecta.

## Lo que desbloquea un análisis de pipeline unificado

Si puedes correr la misma consulta de drop-off contra ambos embudos, tres cosas se vuelven obvias que antes eran invisibles. Primero: los cuellos de botella de capacidad en recursos compartidos, como un hiring manager que también es sponsor de deal, aparecen como drop-off en ambos pipelines a la vez. Segundo: las mejoras de proceso se acumulan, un patrón de SLA que sube la conversión de ventas es el mismo patrón de SLA que sube la aceptación de oferta. Tercero: dejas de contratar dos equipos de analítica para responder una sola pregunta.

Ese es el caso práctico para tratar ventas y reclutamiento como un solo producto de pipeline, no dos. El modelo de datos es el mismo. Los diagnósticos son los mismos. Las correcciones son las mismas. Lo único distinto es la etiqueta en la caja.

[Empezar gratis →](https://leadgrid.io/signup)

---

# Cuatro integraciones de la API de LeadGrid que tu equipo usará de verdad

URL: https://leadgrid.io/es/blog/integraciones-api-leadgrid-que-tu-equipo-usara-de-verdad
Locale: es
Published: 2026-04-25
Author: Ralf Klein
Tags: api, product, guides

LeadGrid expone cada acción del pipeline como un endpoint REST. Cuatro integraciones que los equipos construyen en una tarde, con ejemplos de código reales.

LeadGrid está construido API-first. Cada acción que puedes realizar en la interfaz, crear un expediente, mover un lead por una etapa, añadir una nota, asignar un propietario/a, es una llamada REST documentada. Es una decisión de diseño, no una característica secundaria.

Según el [Postman 2025 State of the API Report](https://www.postman.com/state-of-api/2025/), el 82% de las organizaciones han adoptado algún nivel de enfoque API-first. Los equipos que construyen sobre su herramienta de pipeline en lugar de a su alrededor son los que dejan de hacer la misma tarea manual dos veces por semana.

Aquí tienes cuatro integraciones que los equipos realmente construyen, con el código para demostrarlo.

## 1. El envío de un formulario web crea un expediente automáticamente

Esta es la más común. Tienes un formulario de contacto, una landing page o un enlace de referido de un socio. Alguien lo rellena. Ahora mismo, alguien de tu equipo copia esos datos manualmente en LeadGrid. Eso es lo primero que hay que eliminar.

La API de LeadGrid te permite llamar a `POST /dossiers` para crear un nuevo registro en cualquier pipeline. Un simple receptor de webhook en Node se encarga del resto:

```ts
// Activado por tu proveedor de formularios (Typeform, Tally, formulario nativo, da igual)
app.post('/webhook/new-lead', async (req, res) => {
  const { name, email, company } = req.body;

  await fetch('https://api.leadgrid.io/v1/dossiers', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.LEADGRID_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      pipelineId: 'your-pipeline-id',
      title: `${name} - ${company}`,
      fields: { email, company },
    }),
  });

  res.sendStatus(200);
});
```

Nuevo lead registrado. Sin copiar y pegar. Nadie se olvida.

## 2. El cambio de etapa envía una notificación de Slack

Los managers de ventas miran LeadGrid. El resto del equipo mira Slack. Si un deal pasa a "Negociación" o un candidato/a llega a "Entrevista final", tu canal de Slack debería saberlo antes de que nadie tenga que preguntar.

Los webhooks de LeadGrid te permiten suscribirte a eventos `dossier.stage_changed`. Cuando se activa, lo reenvías a tu webhook entrante de Slack:

```ts
app.post('/webhook/leadgrid-events', async (req, res) => {
  const { event, data } = req.body;

  if (event === 'dossier.stage_changed') {
    const { title, stage, pipelineId } = data;

    await fetch(process.env.SLACK_WEBHOOK_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        text: `Actualización del pipeline: *${title}* ha pasado a *${stage}*`,
      }),
    });
  }

  res.sendStatus(200);
});
```

Treinta líneas. Tu equipo deja de preguntar: "¿dónde está ese deal ahora mismo?"

## 3. Un deal cerrado envía un registro a tu sistema de RRHH o ERP

Cuando se cierra una colocación de recruitment o se firma un contrato comercial, tu backoffice necesita saberlo. Exportar manualmente desde LeadGrid e importar en tu plataforma de RRHH o ERP es exactamente el tipo de trabajo que genera errores el jueves por la tarde.

Suscríbete a eventos `dossier.closed` y envía los datos estructurados directamente:

```ts
if (event === 'dossier.closed') {
  const { id, title, fields } = data;

  // Push a tu sistema de RRHH, sustituye por la API de tu proveedor
  await fetch('https://api.your-hr-tool.com/employees', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.HR_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      name: fields.candidateName,
      email: fields.email,
      startDate: fields.startDate,
      role: fields.jobTitle,
    }),
  });
}
```

LeadGrid es el disparador. Tu sistema de RRHH recibe datos limpios y estructurados. Ni un CSV a la vista.

## 4. Informe nocturno del pipeline en tu bandeja de entrada

La dirección quiere un resumen cada mañana. ¿Qué se movió ayer? ¿Qué está atascado? ¿Qué necesita atención?

Un simple cron job que llama a `GET /dossiers?filter=updated_since=yesterday` y formatea el resultado lo cubre completamente:

```ts
// Ejecutar cada mañana a las 07:00 mediante cron o una función programada
const yesterday = new Date(Date.now() - 86400000).toISOString();

const response = await fetch(
  `https://api.leadgrid.io/v1/dossiers?updated_since=${yesterday}`,
  { headers: { 'Authorization': `Bearer ${process.env.LEADGRID_API_KEY}` } }
);

const { dossiers } = await response.json();
const summary = dossiers.map(d => `- ${d.title}: ${d.stage}`).join('\n');

// Enviar via Resend, Postmark o cualquier proveedor de email transaccional
await sendEmail({
  to: 'team@yourcompany.com',
  subject: `Actualización del pipeline - ${new Date().toLocaleDateString()}`,
  text: summary || 'Sin cambios desde ayer.',
});
```

El [Postman 2025 State of the API Report](https://www.postman.com/state-of-api/2025/) también encontró que el 52% de los desarrolladores sufrieron breaking changes de proveedores externos en 2024. LeadGrid mantiene endpoints versionados (`/v1/`) para que tus integraciones no se rompan silenciosamente un martes por la mañana.

## El patrón detrás de las cuatro

Cada una de estas integraciones sigue la misma estructura: escuchar un disparador (webhook o programación), llamar a la API de LeadGrid para leer o escribir datos, enviar el resultado a otro lugar. La superficie de la API es consistente, autenticada con un único bearer token, y devuelve JSON predecible.

Eso es lo que API-first significa en la práctica. No construyes flows *dentro* de LeadGrid. Los construyes *encima*.

Referencia completa de la API, documentación de autenticación y catálogo de eventos webhook en [leadgrid.io/docs](https://leadgrid.io/docs).

[Empezar gratis →](https://leadgrid.io/signup)

---

# Por qué tu equipo de operaciones entra en pánico cuando ventas está ganando

URL: https://leadgrid.io/es/blog/por-que-ops-entra-en-panico-cuando-ventas-gana
Locale: es
Published: 2026-04-23
Author: Ralf Klein
Tags: sales, recruitment, pipeline

Cuando los leads se acumulan y el reclutamiento se retrasa, ops pulsa el botón de pánico. Casi siempre es una crisis de información, no de capacidad. Así puedes distinguirlas.

Hay un momento concreto que vive toda empresa de 30 a 60 personas. Ventas está cerrando tratos. La pipeline está llena. El CRM brilla. Y en algún canal de Slack o en la reunión del lunes por la mañana, alguien de ops dice: "Ahora mismo no podemos aceptar más clientes."

El equipo de ventas no lo entiende. Los números son buenos. El equipo de ops está bajo presión. Los dos tienen razón, y los dos ven solo la mitad del panorama.

## La brecha entre cerrar y entregar

La mayoría de las empresas en esta etapa gestionan dos pipelines completamente separadas. Ventas rastrea leads en un CRM: prospecto, demo, propuesta, cerrado. Reclutamiento rastrea candidatos/as en un ATS: solicitud, criba, entrevista, contratación. El mismo movimiento de fondo, herramientas distintas, cero contexto compartido.

El problema no es que estos equipos avancen a velocidades distintas. Siempre lo harán. El problema es que nadie puede ver las dos pipelines al mismo tiempo.

Cuando ops ve una pipeline de ventas llena y no sabe que tres ingenieros/as están en la ronda final, ops entra en pánico. Cuando ventas ve un trimestre lento y no sabe que dos nuevas incorporaciones aún están en el onboarding, empuja más fuerte. Cada decisión se toma con información incompleta.

## El plazo de contratación es más largo de lo que crees

[El SHRM Talent Acquisition Benchmarking Report](https://www.shrm.org/topics-tools/research/talent-acquisition-benchmarking-report) sitúa el tiempo medio de cobertura de vacantes entre sectores en 36 a 44 días. Para perfiles técnicos y especializados en empresas en crecimiento, [los Hiring Benchmarks de Greenhouse](https://www.greenhouse.com/guidance/hiring-benchmarks) muestran que la mediana del tiempo de contratación se acerca más a los 47 días.

Eso significa que la persona que necesitas para entregar el contrato que se cierra esta semana debería haber sido buscada hace cinco o siete semanas. Si solo ves la pipeline de ventas, esa brecha es completamente invisible.

## El problema es de visibilidad, no de capacidad

Esto es lo que suele ocurrir en la práctica: ops tiene razón en que el equipo está al límite. Pero se equivoca sobre la causa y sobre la solución.

El reflejo es frenar las ventas. "No aceptemos nuevos clientes hasta que contratemos." Parece racional. Pero si pudieras ver que cuatro candidatos/as están en rondas finales y probablemente empezarán en tres semanas, el cálculo cambia por completo. El equipo está al límite ahora. En un mes, ya no lo estará.

La pregunta no es "¿frenamos ventas?" La pregunta es: "¿en qué etapa de qué pipeline está el verdadero cuello de botella?" No puedes responder a eso si solo miras una pipeline.

## Qué cambia cuando ves las dos al mismo tiempo

Cuando las pipelines de ventas y reclutamiento comparten la misma vista, varias cosas cambian de inmediato.

**Las decisiones de timing mejoran.** Ves que tienes diez leads en la etapa de propuesta y cinco candidatos/as en la etapa de oferta, y puedes tomar una decisión informada: acelerar, esperar o contratar más rápido.

**La previsión se vuelve honesta.** La planificación de capacidad a 30-100 personas se basa principalmente en la intuición porque los datos viven en dos herramientas que no se comunican. Una vista compartida hace visible la dependencia: cada contrato cerrado necesita un equipo de entrega, y ese equipo viene de una pipeline que deberías estar siguiendo en paralelo.

**El pánico desaparece.** La mayor parte del estrés que viven los equipos de ops en esta fase no es una crisis de capacidad. Es una crisis de información. Cuando puedes ver que el reclutamiento va según lo previsto, un CRM lleno deja de ser una amenaza y se convierte en un objetivo.

## La solución no es otra integración

El movimiento obvio es conectar tu ATS a tu CRM o al revés. Es lo que la mayoría de los equipos intenta primero. El resultado es un caos: modelos de datos incompatibles, campos que no se mapean bien, paneles que muestran números pero no contexto.

La solución más limpia es modelar las dos pipelines en la misma herramienta desde el principio. Los leads de ventas y los candidatos/as son personas que avanzan por etapas. Dales un nombre, una etapa, un plazo, un propietario/a, y habrás descrito a ambos. La única diferencia está en el resultado: cerrado versus contratado/a.

[La investigación Global Human Capital Trends de Deloitte](https://www.deloitte.com/global/en/insights/focus/human-capital-trends.html) muestra que las organizaciones con ciclos de planificación de talento y negocio integrados toman decisiones de personal significativamente más rápido que las que planifican por separado. A la escala de 10 a 100 personas, esa velocidad no es una ventaja competitiva. Es la diferencia entre escalar con fluidez y contratar en modo pánico.

## Ops no se equivoca al preocuparse

La intuición de "no podemos asumir esto" suele ser correcta en su esencia. Los equipos de 30 a 80 personas realmente trabajan cerca de su límite de capacidad. El problema no es que ops esté equivocado/a. Es que están tomando una decisión sin los datos que necesitan.

Cuando la pipeline de reclutamiento es visible junto a la pipeline de ventas, la pregunta pasa de "¿frenamos?" a "¿qué tiene que ser cierto para que podamos decir que sí a esto?" Esa es una conversación mucho más útil.

[Empezar gratis →](https://leadgrid.io/signup)

---

# ¿Cuánto tiempo puedes guardar a un candidato en tu talent pool? Las reglas del RGPD explicadas

URL: https://leadgrid.io/es/blog/plazo-retencion-talent-pool-rgpd
Locale: es
Published: 2026-04-22
Author: Ralf Klein
Tags: recruitment, guides

Candidatos rechazados, casi-coincidencias, perfiles para el futuro: ¿cuánto tiempo puedes conservar legalmente sus datos en un talent pool bajo el RGPD?

Un candidato/a se postuló, llegó a la ronda final y no obtuvo el puesto. Quieres guardarlo para la próxima vacante. Ese instinto es correcto. La ejecución debe ser deliberada, porque bajo el RGPD, "mantener a alguien en el sistema" es una actividad de tratamiento con una base legal y un plazo de retención.

Esto es lo que dicen realmente las reglas.

## El estándar: cuatro semanas tras el rechazo

Cuando un candidato/a se postula para una función específica y lo rechazas, puedes conservar sus datos durante **cuatro semanas** tras el rechazo. Esto cubre el período en el que el candidato podría presentar una objeción o solicitar acceso a su expediente.

Después de esas cuatro semanas, si no tienes otra base legal, los datos deben eliminarse.

Sin consentimiento, sin pipeline activo, sin vacante abierta: eliminar.

## Ampliar a un talent pool: necesitas consentimiento explícito

Conservar a un candidato/a más tiempo, en un talent pool, requiere un **consentimiento explícito e informado**. No un consentimiento implícito. No una casilla pre-marcada. No una línea general enterrada en tu política de privacidad.

El candidato debe aceptar activamente:

- ser incluido en un talent pool
- durante un plazo de retención específico que indiques de antemano
- para un propósito que describas claramente (vacantes futuras, no marketing general)

La práctica estándar en España y en toda la UE es un **máximo de un año** con un solo consentimiento. Tras un año, pides de nuevo el consentimiento o eliminas el expediente. Algunas organizaciones fijan la ventana en dos años, lo que es defendible para funciones con un ciclo de contratación lento, pero un año es el valor por defecto más seguro.

## Qué debe incluir la solicitud de consentimiento

Una solicitud de opt-in para un talent pool conforme al RGPD tiene tres componentes:

1. **Qué estás almacenando.** CV, datos de contacto, notas de entrevistas, puntuaciones de evaluación. Sé específico.
2. **Por qué.** Vacantes futuras en tu organización que encajen con su perfil.
3. **Cuánto tiempo.** Un año desde la fecha del consentimiento. No "por tiempo indefinido."

Añade un mecanismo de opt-out claro. El candidato puede retirar el consentimiento en cualquier momento, y retirarlo debe ser tan fácil como darlo.

Si usas una herramienta de reclutamiento o ATS, comprueba si registra las marcas de tiempo del consentimiento y envía recordatorios de eliminación automáticos cuando el plazo de retención vence. El seguimiento manual en una hoja de cálculo es un riesgo de cumplimiento a cualquier escala.

## Casi-coincidencias y talent pools en la práctica

La regla del talent pool se aplica igualmente a:

- Candidatos/as rechazados directamente
- Candidatos/as que encajaban bien pero perdieron frente a un perfil más fuerte
- Candidatos/as que retiraron su candidatura a mitad del proceso

La base legal no cambia según lo cerca que estuvieran. Si ya no están en un proceso activo, necesitas su consentimiento o eliminas.

Un matiz: si el candidato envió una **candidatura espontánea** sin una función específica, la expectativa implícita es que la conservas para consideración futura. Eso solo no constituye un consentimiento RGPD válido, pero facilita la conversación de opt-in.

## La posición de las autoridades de protección de datos

La AEPD y otras autoridades europeas de protección de datos han publicado orientaciones que confirman que el almacenamiento en talent pool requiere consentimiento explícito y recomiendan un plazo de retención máximo de **un año**. Las organizaciones han sido sancionadas activamente por conservar datos de candidatos sin una base legal válida.

Si operas más allá de las fronteras de la UE, las reglas son coherentes. El RGPD se aplica de forma uniforme. Las autoridades nacionales pueden diferir ligeramente en el énfasis de la aplicación, pero los requisitos de consentimiento y retención son los mismos.

## Qué incorporar a tu proceso

Tres pasos prácticos que eliminan la mayor parte del riesgo de cumplimiento:

**En el rechazo:** envía un correo único y claro preguntando si el candidato quiere unirse a tu talent pool. Incluye qué significa eso, cuánto tiempo se conservarán sus datos y un opt-in con un clic.

**En el consentimiento:** registra la fecha y lo que se consintió. Tu ATS o CRM debería hacer esto automáticamente. Si no lo hace, es un problema de herramientas que vale la pena resolver.

**Al vencimiento:** recordatorio automático cuando vence la ventana de consentimiento. O pides el consentimiento de nuevo, o activas un flujo de eliminación.

Esto no es complejo de implementar. Es fácil de saltarse. Saltárselo es lo que crea la exposición al cumplimiento.

## La versión corta

Candidato rechazado, sin consentimiento: eliminar tras cuatro semanas. Talent pool con consentimiento: hasta un año, luego volver a preguntar o eliminar. Registra todo. El opt-out debe ser sencillo.

Esa es la regla completa. El resto es implementación.

---

# ¿ATS o CRM? Las agencias de reclutamiento están haciendo la pregunta equivocada

URL: https://leadgrid.io/es/blog/ats-vs-crm-para-agencias-de-reclutamiento
Locale: es
Published: 2026-04-21
Author: Ralf Klein
Tags: recruitment, guides, pipeline

La mayoría de las agencias de reclutamiento se obsesionan con ATS vs CRM y al final compran los dos. Aquí está la razón por la que la pregunta en sí es el problema, y cómo luce un stack más ligero.

Tu mejor candidato de esta semana está en el ATS. Tu cliente más caliente está en el CRM. El jueves, el cliente llama preguntando exactamente por ese perfil. Copias notas entre dos pestañas, envías un seguimiento y esperas que nada se escape. El viernes, el candidato acepta una oferta en otro lugar porque tu respuesta tardó dos días en llegar.

Ese es el problema ATS vs CRM en 15 segundos. Dos herramientas. Dos pestañas. Un hueco.

## Dos herramientas diseñadas para dos equipos distintos

El ATS fue diseñado para equipos de RRHH internos que gestionan grandes volúmenes de contratación. Mueve solicitudes a través de stages, almacena currículums y hace seguimiento del time-to-hire. El CRM fue diseñado para equipos de ventas que gestionan relaciones con clientes. Registra llamadas, recuerda hacer seguimientos y rastrea los stages de los deals.

Ninguno fue diseñado para la persona que ejecuta ambos movimientos a la vez: el reclutador de una agencia de 12 personas que necesita conectar al candidato correcto con la apertura de cliente correcta antes de que cualquiera de los dos lados se enfríe. Cuando le pegas un ATS a un CRM, o los corres en paralelo, pagas el costo operativo de dos sistemas sin la claridad de ninguno.

## El stack se vuelve más pesado a medida que los equipos se reducen

El [informe Gem 2026 Recruiting Benchmarks](https://www.gem.com/blog/key-takeaways-from-the-2026-recruiting-benchmarks-report), que rastreó más de 165 millones de candidatos, encontró que los equipos de reclutamiento ahora manejan un 93 % más de solicitudes que en 2021, mientras que el headcount se redujo un 14 %. Se le pide a los equipos que corran más rápido en una pista que se ha vuelto más larga.

Añadir un segundo sistema a esa carga de trabajo es la respuesta equivocada. Cada sincronización manual entre el ATS y el CRM es tiempo que un reclutador no está dedicando al candidato ni al cliente. Cada cambio de contexto entre dashboards es una ventana por la que algo se puede colar.

## Cómo luce "colarse por las grietas" en la práctica

El [informe iHire 2025 State of Online Recruiting](https://www.ihire.com/about-us/press-room/articles/2025/ihire-releases-2025-state-of-online-recruiting-survey-results) encontró que el 59 % de los candidatos señaló el ghosting por parte de los empleadores como su mayor frustración en la búsqueda de empleo. El ghosting rara vez es deliberado. Es lo que pasa cuando un reclutador pierde el rastro de un candidato porque sus datos viven en un sistema distinto al de la conversación con el cliente.

Del lado del cliente, la misma brecha aparece de forma diferente. Un lead se enfría no porque no hubiera un buen candidato, sino porque el reclutador estaba con la cabeza en el ATS cuando el cliente se quedó en silencio, sin una vista compartida del estado de las cosas.

Las [estadísticas de reclutamiento 2025 de SmartRecruiters](https://www.smartrecruiters.com/blog/recruitment-statistics-for-2025/) lo cuantifican: el 22 % de los equipos de talento reportan dificultades para rastrear candidatos dentro de su propio proceso de contratación. Ese no es un problema del reclutador. Es un problema de la herramienta.

## La conclusión práctica

Antes de firmar otro contrato anual, rastrea tus últimas cinco colocaciones y encuentra en qué momento cada candidato estuvo más de 48 horas sin un punto de contacto. En la mayoría de las agencias, ese retraso ocurre en dos momentos específicos: justo después del primer filtro, cuando el candidato pasa del ATS a "enviarle un email al cliente", y justo después de que un cliente muestra interés, cuando el reclutador vuelve al ATS para buscar los detalles del candidato.

Esos son los puntos de traspaso. Ahí es donde tu pipeline tiene fugas. Arreglar la herramienta es más rápido que entrenar a la gente para que evite el hueco.

## Una sola grilla para ambos movimientos

LeadGrid no es un ATS. No es un CRM. Ese es el punto.

Pone candidatos y clientes en la misma grilla de pipeline, con la misma lógica de stages, el mismo modelo de ownership y la misma visibilidad. Cuando un cliente abre una posición, ves qué candidatos ya están en el stage correcto. Cuando un candidato avanza, el contexto del cliente relevante está a un clic. No hay segunda pestaña a la que cambiar ni sincronización manual que ejecutar.

Los equipos de 5 a 50 personas que han rebotado en Salesforce, HubSpot, Greenhouse o Lever suelen descubrir que lo que necesitaban no era una versión mejor de ninguna de esas herramientas. Necesitaban una sola grilla que manejara ambos movimientos sin el overhead de dos stacks.

**[Empieza gratis →](https://leadgrid.io/signup)**

---

# La mitad de tu pipeline se cae antes de que te des cuenta

URL: https://leadgrid.io/es/blog/la-mitad-del-pipeline-cae-antes-del-aviso
Locale: es
Published: 2026-04-20
Author: Ralf Klein
Tags: recruitment, pipeline

El 47 % de los candidatos cita la mala comunicación como motivo de abandono. La fuga no está en la parte alta de tu funnel. Está en el traspaso.

Un candidato sólido completa dos rondas de entrevistas. El hiring manager está convencido. El recruiter está listo para avanzar. Entonces pasa una semana. Luego dos. Nadie envió un seguimiento. El candidato, asumiendo que lo ignoraron, acepta una oferta en otro lugar.

Esto no es un caso excepcional. [Según el Ghosting Index 2025 de The Interview Guys](https://blog.theinterviewguys.com/the-2025-ghosting-index/), **el 61 % de los candidatos ha sido ghosteado tras una entrevista de trabajo**, un aumento de nueve puntos porcentuales desde principios de 2024. El número sigue subiendo, y no porque los candidatos se hayan vuelto menos comprometidos. Es porque los equipos que los contratan no hacen seguimiento.

La fuga no está en la parte alta de tu funnel.

## La pérdida ocurre después del interés

La mayoría de los equipos de selección se centran en el sourcing. Optimizan las descripciones de puestos, lanzan campañas en LinkedIn y refinan los formularios de solicitud. Mientras tanto, el mayor abandono se encuentra más abajo en la pipeline, en stages donde el candidato ya había mostrado su interés.

Una investigación de [The HT Group](https://www.thehtgroup.com/how-to-fix-top-candidate-drop-off-in-the-hiring-process/) lo precisa: la fase de entrevista sola representa casi un tercio de toda la pérdida de candidatos, y la fase de planificación añade otro 20 %. Eso significa que más de la mitad de cada candidato que te costó atraer abandona después de ya estar comprometido. Querían el puesto. Se presentaron. Luego el proceso los perdió.

Un mejor sourcing no resolverá esto. Un traspaso más rápido, sí.

## La mala comunicación es el motivo declarado, no una suposición

Cuando los candidatos abandonan, dicen por qué. [El Cronofy Candidate Expectations Report 2024](https://www.cronofy.com/reports/candidate-expectations-report-2024) encontró que **el 47 % de los candidatos cita la mala comunicación como su razón para retirarse** de un proceso de selección. No el salario. No el desplazamiento. No una oferta competidora. La comunicación.

El mecanismo es sencillo. Un recruiter termina la llamada de cribado y hace avanzar al candidato. El hiring manager recibe el traspaso pero tiene otras seis posiciones abiertas, una sprint review y una presentación para el consejo esta semana. El candidato espera. Después de siete días de silencio, el 34 % asume que ya ha sido rechazado y deja de responder.

Esta es la parte que duele: el candidato no perdió el interés. El proceso perdió al candidato. Y cuando alguien se da cuenta de que el registro lleva diez días en el mismo stage, el candidato ya lleva dos semanas en su nuevo trabajo.

## El traspaso es donde la responsabilidad se rompe

En la mayoría de los scale-ups, el recruiter gestiona la pipeline hasta que se programa una entrevista. Luego la responsabilidad pasa, de forma informal, al hiring manager. Sin traspaso explícito. Sin marca de tiempo. Sin siguiente paso visible. Ambos asumen que el otro lo está gestionando.

La tasa de aceptación de ofertas cuenta toda la historia. [Las estadísticas de experiencia de candidatos 2025 de CareerPlug](https://www.careerplug.com/candidate-experience-statistics/) informan que la tasa de aceptación de ofertas cayó al 51 % en el T2 de 2025, frente al 74 % de solo dos años antes. Los equipos llegan a la fase de oferta y aún así pierden al candidato. Eso no es un problema de sourcing ni de compensación. Es un problema de visibilidad.

Cuando nadie puede ver quién es responsable del siguiente paso, el siguiente paso no ocurre.

## Analiza el stage donde cambia la responsabilidad

Mira tu pipeline y encuentra el stage donde la marca de tiempo de la última actividad es más antigua. Casi siempre es el traspaso del recruiter al hiring manager. Haz ahora la misma comprobación para cada posición activa, no solo la que te preocupa ahora mismo.

El patrón es consistente en todos los equipos: la pipeline pierde más donde la responsabilidad se asume en lugar de asignarse. Un candidato que lleva once días en "entrevista programada" tiene un problema de responsabilidad, no un problema de candidato. La solución empieza por hacer eso visible.

Marca cada registro donde la última actividad fue hace más de cinco días hábiles y la responsabilidad no está clara. Encontrarás tu punto de fuga. No será aleatorio. Se agrupará en el mismo stage, por el mismo motivo, siempre.

## Los candidatos no te están ghosteando. El traspaso sí.

Llevar el reclutamiento en una hoja de cálculo mientras el hiring manager anota en correos electrónicos no es una brecha de flujo de trabajo. Es una garantía estructural de que algo se va a perder. Nadie tiene visibilidad de ambos, así que nadie detecta el silencio antes de que cueste una contratación.

LeadGrid coloca a los candidatos en una única cabina de mando con responsabilidad de stage explícita y un marcador de última actividad visible para cada registro. Cuando un candidato lleva demasiado tiempo sin un siguiente paso, eso es visible para todos los que necesitan verlo, no enterrado en la bandeja de entrada de alguien ni oculto en una pestaña que olvidaron revisar.

**[Empezar gratis →](https://leadgrid.io/signup)**

---

# Cinco cosas que automatizas cuando cada acción del pipeline es una llamada REST

URL: https://leadgrid.io/es/blog/automatizar-el-pipeline-con-rest-api
Locale: es
Published: 2026-04-18
Author: Ralf Klein
Tags: api, engineering

LeadGrid expone cada acción de la interfaz a través de una REST API documentada. Aquí tienes cinco automatizaciones que puedes poner en marcha en una tarde, sin exportar ni un CSV.

Cada acción de la interfaz de LeadGrid, crear un expediente, mover una etapa, añadir una nota, asignar un miembro, es una llamada REST documentada. Eso no es una funcionalidad; es la forma del producto. Significa que la frontera entre "lo que hace LeadGrid" y "lo que hace tu propio código" es simplemente una petición HTTP.

Aquí tienes cinco automatizaciones que tardan menos de una tarde en estar listas, en cuanto dejas de ver tu CRM como algo en lo que haces clic.

## 1. Crear expedientes automáticamente desde el correo entrante

Cada workspace recibe una dirección inbound. Reenvía un lead o un CV a esa dirección, LeadGrid parsea el remitente y el adjunto, crea un expediente estructurado y lanza un webhook hacia tu capa de automatización.

Sin revisar manualmente una bandeja compartida. Sin subir CSVs. Tu AE reenvía una intro de cliente y, cuando actualiza la grid, el expediente ya está asignado, etiquetado y en el pipeline correcto.

## 2. Notificaciones de Slack por etapa con contexto

Webhook `dossier.stage_changed` → tu función → mensaje de Slack. El body incluye nombre del expediente, etapa anterior, nueva etapa, responsable y fecha límite. Tú escribes el filtro: `if new_stage == "Interview" and dossier.type == "candidate"` → `#recruitment-live`. Los deals de ventas siguen otro canal y otro umbral.

No estás reconfigurando notificaciones en la UI de un proveedor. Estás expresando una regla en código, versionada junto al resto de tu infra.

## 3. Escalados de fecha límite que realmente escalan

LeadGrid tiene fechas límite integradas. La diferencia es que puedes suscribirte a `dossier.deadline_missed` y reaccionar como trabaja *tu* equipo: avisar al manager del responsable, publicar en el canal de escalado, abrir un ticket en Linear, o disparar un recordatorio de calendario 24 horas antes.

La API te permite componer escalados a partir de los servicios que ya tienes en marcha. Sin ningún nuevo dashboard que vigilar.

## 4. Mantener tu data warehouse actualizado sin ETL

Cada evento de expediente, creado, movido, cerrado, comentado, está disponible como webhook. Envíalos a una cola, escríbelos en tu warehouse y tu capa de BI estará al día en segundos en lugar del retraso de 24 horas de una sincronización nocturna.

```ts
// pseudo-handler
app.post("/webhooks/leadgrid", async (req) => {
  const sig = req.headers["x-leadgrid-signature"];
  verify(sig, req.rawBody);            // HMAC, documentado
  await queue.publish("leadgrid", req.body);
  return { ok: true };
});
```

Sin pipeline ETL, sin job programado, sin "oh, la sincronización ha vuelto a romperse". La fuente de verdad empuja, tu warehouse escucha.

## 5. Agentes que mueven pipelines por su cuenta

Aquí es donde se pone interesante. Como cada acción es una llamada REST con una spec OpenAPI limpia, un LLM puede manejar LeadGrid. Un agente de Claude o GPT puede:

- Leer el CV de un/a candidato/a desde el storage
- Escribir un resumen con IA y publicarlo como nota
- Mover el expediente a la siguiente etapa si el resumen encaja con el puesto
- Enviar al/a la candidato/a un siguiente paso estructurado por correo usando el dominio remitente del workspace

Nada de esto requiere scraping. El agente llama a `POST /v1/dossiers/<id>/notes` igual que un humano hace clic en "Añadir nota".

No vendemos una funcionalidad de IA cerrada sobre un CRM cerrado. Vendemos un pipeline programable, y tú decides qué bucles se ejecutan con personas, cuáles con automatización y cuáles con agentes.

## El punto fundamental

Cualquier CRM puede producir un CSV. Muy pocos están diseñados para que toda la superficie sea tan invocable como una biblioteca. LeadGrid sí lo es. Lee la spec en [`/docs/api`](/docs/api), obtén una clave API en la configuración de tu workspace y lanza tu primera automatización en una tarde.

[Empezar gratis →](/signup)

---

# Dos pipelines, un cuello de botella

URL: https://leadgrid.io/es/blog/dos-pipelines-un-cuello-de-botella
Locale: es
Published: 2026-04-16
Author: Ralf Klein
Tags: pipeline, sales, recruitment

La mayoría de las scale-ups gestionan Sales y reclutamiento en dos stacks que nunca se comunican. Un solo hiring manager es el cuello de botella en ambos pipelines a la vez.

Un viernes por la tarde, en casi cada scale-up con la que trabajamos, dos cosas fallan al mismo tiempo en el mismo edificio, y nadie se da cuenta de que en realidad es el mismo problema. Un lead enterprise sólido se escapa porque el AE está esperando a que el hiring manager confirme capacidad antes de comprometerse con un plazo. Dos pisos más abajo, un ingeniero senior al que la reclutadora ha estado cultivando durante tres semanas desaparece, porque ese mismo hiring manager no ha devuelto la llamada de calibración. El lead se escapa. El candidato se enfría. El lunes por la mañana ambos equipos reportan la pérdida en su propio standup, en su propio board, con su propia explicación.

No son dos problemas separados. Es un solo problema, visto dos veces, por equipos que no pueden verse entre sí.

## La forma es idéntica, los stacks no

Cada scale-up por encima de cierto tamaño opera dos procesos que sobre el papel parecen iguales. Sales tiene leads que avanzan de qualified a discovery, luego a proposal y finalmente a close. Reclutamiento tiene candidatos/as que pasan de sourced a screen, luego a interview y después a offer. La misma forma de pipeline, las mismas etapas en esencia, el mismo modelo de ownership, la misma noción de last-touch y next-touch. Conecta uno en HubSpot o Pipedrive, el otro en Greenhouse o Workable, y tienes dos procesos que nunca se ven. Las personas que bloquean uno a menudo bloquean el otro. El contexto que importa en uno a menudo importa en el otro. Ninguna herramienta lo sabe.

## Los datos ya incomodan

El coste estructural de la fragmentación está cuantificado. Un reciente [benchmark de Gartner Sales Operations](https://www.gartner.com/en/sales/trends/2025-sales-operations-leadership-vision) encontró que los equipos de revenue operations ahora habitualmente dan soporte a cinco o más grupos y dedican el 68 % de su tiempo a trabajo sin relación directa con clientes. Dos tercios del ancho de banda de ops se va en coordinación, pegamento entre herramientas, reconciliación y el lento descifrado de qué quería decir realmente otro sistema cuando estableció un estado. Y eso es antes de que alguien pregunte si los dos procesos adyacentes en tu empresa, Sales y reclutamiento, comparten aunque sea una definición de etapa.

En el lado de los candidatos/as, la fuga es más rápida y más visible. Los informes del sector sobre [el proceso de contratación en 2025](https://blog.theinterviewguys.com/state-of-the-hiring-process-in-2025/) apuntan a una dinámica directa: los mejores candidatos salen del mercado en aproximadamente 10 días, y el abandono de candidaturas ronda el 60 % cuando el proceso se alarga. Cuando Sales obtiene la respuesta comercial que necesita y reclutamiento sigue esperando, el candidato ya le ha dicho que sí a otra empresa. Tu AE no lo sabe. Tu reclutadora lo sabe, pero no tiene dónde señalarlo de forma que el AE lo vea.

Lo contrario prueba el argumento. [HubSpot Research](https://www.hubspot.com/state-of-marketing) descubrió que cuando Sales y Customer Success comparten un marco operativo, la retención sube un 36 % y las tasas de cierre suben un 38 %. La lección no es específicamente sobre CS, es sobre la proximidad. Dos equipos que trabajan la misma relación con el comprador rinden radicalmente mejor cuando pueden verse. No existe aún un benchmark publicado para la alineación Sales más reclutamiento, porque casi nadie lo ha medido, pero el mecanismo es el mismo. La proximidad recompensada una vez se recompensa dos veces.

## La anatomía de un fallo de handoff

Cada fuga de handoff que hemos rastreado en una scale-up se reduce a una de tres mecánicas.

La primera es el **ownership obsoleto**. Un lead o un/a candidato/a tiene un nombre junto a él. Esa persona desde entonces ha pasado a otro equipo, se ha ido de vacaciones o se ha desconectado silenciosamente del account. El registro no está mal a propósito. Está mal porque nada en el stack ha forzado nunca una actualización. En un stack de un solo proceso esto es doloroso. En dos procesos que se bloquean mutuamente, es multiplicativo.

La segunda es la **etapa invisible**. Un lead pasa de "qualified" a "discovery" en el CRM. La reclutadora no lo ve. ¿Por qué iba a verlo? El lead es un artefacto de Sales. Pero ese mismo account también tiene un hiring manager que es uno de los cuatro decisores del deal. Cuando Sales mueve el registro, reclutamiento no sabe que la temperatura acaba de cambiar. Una llamada de calibración que podría haber ocurrido esta semana ocurre en cambio en tres semanas, después de que la etapa ya se haya estancado.

La tercera, y la más cara, es el **cuello de botella cross-motion**. Una persona, generalmente un hiring manager o un VP de Ingeniería, es el límite de velocidad en dos pipelines distintos a la vez. El equipo de Sales está esperando a que apruebe headcount antes de comprometerse con el alcance. El equipo de reclutamiento está esperando a que firme la oferta antes de que el candidato acepte. Cada equipo escala de forma individual. Cada equipo añade a la pila que esa misma persona tiene que despejar. Si cualquiera de los dos equipos hubiera visto la cola del otro, habrían agrupado la conversación. Ninguno la vio.

## Lo que cambia realmente un cockpit compartido

El ownership se convierte en un campo, no en dos. La misma persona, registrada como owner, se traslada a ambos procesos para los accounts en los que es la misma persona. Las etapas se vuelven legibles entre equipos. Un lead que avanza a "proposal" marca el registro de reclutamiento para la misma empresa, porque los roles que se están contratando para ese account acaban de volverse urgentes. Los cuellos de botella aparecen como cuellos de botella, no como dos solicitudes de reprogramación sin relación. El hiring manager ve lo que está pendiente de ambos lados en una sola vista y toma una decisión en lugar de ser empujado dos veces.

Esto es lo que significa poner dos pipelines en un solo grid, y es la razón por la que existe LeadGrid. No porque los equipos de Sales estén hartos de los CRMs y los equipos de reclutamiento de los ATSes, aunque ambas cosas son ciertas. Sino porque el handoff que rompe una scale-up no está dentro de ninguna de las dos herramientas, está entre ellas.

## La auditoría que haces el lunes

No necesitas una plataforma nueva para empezar. Necesitas encontrar dónde tus handoffs realmente se escapan. Algunas cosas que probar durante la primera semana, con lo que ya tienes.

Entra el lunes por la mañana y lista cada lead que se estancó la semana pasada junto con cada candidato/a que se estancó la semana pasada. Ponlos en el mismo spreadsheet, ordenados por la persona nombrada que está esperando algo. Cuenta con qué frecuencia aparece la misma persona en ambas columnas. Ese número es tu tasa de cuello de botella cross-motion. En la mayoría de scale-ups a las que hemos ayudado, se sitúa entre el 15 y el 30 %. Eso es el 15 al 30 % de tus estancamientos que no son un problema de Sales ni un problema de reclutamiento, son un problema de cola.

Luego comprueba tus campos de ownership. Para cada registro activo en ambos sistemas, pregúntate si la persona listada respondió a un correo en los últimos cinco días laborables. El porcentaje que falla es tu tasa de ownership obsoleto. Cualquier cosa por encima del 20 % significa que el registro te está mintiendo en el momento en que más lo necesitas.

Por último, elige un account abierto donde la empresa sea tanto un deal como un objetivo de reclutamiento. Alinea el registro de actividad de Sales y el registro de actividad de reclutamiento uno al lado del otro. Fíjate en cada momento en que un equipo podría haberle ahorrado un día al otro. Esa lista es tu déficit de handoff.

## La solución es un grid, no un CRM más grande

La razón por la que los ingresos se escapan en la unión entre Sales y reclutamiento no es que tu CRM sea malo o tu ATS esté equivocado. Es que tu proceso es una sola cosa y tu stack son dos. La solución no es un CRM más grande. No es un ATS más profundo. Es un grid que muestra ambos pipelines con el mismo vocabulario, el mismo campo de owner y la misma noción de qué significa "atascado". Dale a los líderes de ops una sola vista del proceso, y el proceso deja de dejar caer a la gente al suelo.

**[Empieza gratis →](https://leadgrid.io/signup)**

---

# Por qué construimos LeadGrid como una sola API para dos pipelines

URL: https://leadgrid.io/es/blog/por-que-creamos-leadgrid
Locale: es
Published: 2026-04-14
Author: Ralf Klein
Tags: product, api

La mayoría de los equipos de crecimiento usan un CRM y un ATS para el mismo movimiento. Esto es lo que se desmorona cuando modelas sales y reclutamiento sobre un único modelo de datos, y por qué lo hicimos programable por defecto.

Todos los equipos de crecimiento con los que he trabajado ejecutan el mismo movimiento dos veces. Sales tiene un CRM. Reclutamiento tiene un ATS. La misma forma de pipeline, entrada, calificación, avance, cierre, pero sobre dos stacks que no se hablan.

Construimos LeadGrid porque esa separación es una elección, no una limitación.

## El modelo de datos es el mismo

Un lead y un candidato son ambos *personas moviéndose por etapas*. Dales un nombre, una etapa, una fecha límite, un responsable y un conjunto de notas, y habrás descrito a ambos. Los verbos son idénticos: crear, asignar, mover, comentar, cerrar.

La industria construyó dos categorías de producto alrededor de esto porque era rentable hacerlo, no porque el trabajo subyacente sea diferente. Los equipos terminan pagando a dos proveedores, integrando dos APIs, formándose en dos interfaces y reconciliando dos fuentes de verdad, para rastrear lo mismo dos veces.

## Lo que se desmorona cuando unificas

Operar una sola plataforma para ambos pipelines hace tres cosas concretas:

- **Los traspasos dejan de perderse.** Sales promete entrega. Reclutamiento encuentra a las personas que entregan. Cuando ambos miran el mismo grid, las escaladas ocurren antes de que el candidato se vaya o el deal se escape.
- **El coste de herramientas se reduce a la mitad.** Un solo workspace, una sola línea de facturación, un solo modelo de permisos. Sales y reclutamiento dejan de pelearse sobre qué herramienta es la fuente de verdad, es la misma.
- **El reporting se vuelve honesto.** Time-to-hire y time-to-close viven en la misma base de datos. Por fin puedes responder "¿perdimos este deal porque no teníamos a la persona?" sin necesidad de una hoja de cálculo.

## API-first, no API como ocurrencia tardía

La otra decisión deliberada: cada acción que hace la interfaz es una llamada REST. Crear un dossier, mover una etapa, añadir una nota, asignar un miembro, todo scriptable, todo documentado en [`/docs/api`](/docs/api).

Eso debería ser el mínimo exigible, y sin embargo: la mayoría de los CRMs reservan sus mejores funciones para tiers superiores, envuelven la API en rate limits diseñados para empujarte hacia professional services, o se niegan a documentar los webhooks. Nosotros queríamos lo contrario: la API es el producto, la interfaz es una forma cómoda de usarlo.

La consecuencia práctica: tus automatizaciones no se preocupan de si algo es un lead o un candidato. Escribes una integración una vez, y funciona en ambos pipelines. Claude, n8n, Zapier, tu propio backend, misma forma de endpoint, misma auth, mismo esquema de webhook.

## Gratis para siempre en el plan gratuito

Una última cosa. LeadGrid es gratis para siempre en el plan gratuito, no una prueba de 14 días, no una promo por tiempo limitado. Puedes operar un equipo real, construir pipelines reales y no pagarnos ni un céntimo. Los planes de pago desbloquean más seats, dossiers activos, flows y mayor capacidad de API cuando superas los límites del plan gratuito.

Preferimos tenerte en la plataforma construyendo que mirando una cuenta atrás.

[Empieza gratis →](/signup)

---