Home / Work / Acquisition signal engine

Internal build · acquisition operations

From public signal to a clear next step.

Public notices can reveal timely work, but an alert alone does not tell us whether we can deliver it, who owns the project, or what to do next. We built a workflow that brings dated signals into our CRM, shows why an account is worth reviewing, and puts a human in charge of the approach.

Built for TARG.DIGITAL's own business. This is a system case study, not a client result.

SIGNAL → DECISION → ACTIONWorkflow illustration
Illustrative workflowToday · by priority

One place to see why an account surfaced and whether it is ready for a next step.

01 / SOURCEPublic procurement noticedated

Original URL, buyer, scope and deadline stay with the signal.

02 / REVIEWAccount and delivery fitexplainable

Priority reflects the signal and contactability; a person checks the actual work and route.

03 / NEXT STEPDraft or follow-up taskhuman owned

The draft is prepared in context. Sending remains a deliberate decision.

Illustration of the workflow; no company, notice or contact data is shown.
ProjectInternal acquisition system
Our workProduct design · software engineering
Core stackPython · Twenty CRM · MCP
27 October 2026 snapshot

What exists in the running system

These are operating counts from our own instance, not sales outcomes or a forecast.

66active dated signalswith source URLs
348scored accountspriority from visible factors
235first-touch draftsfor human review
15open follow-up tasksthe deliberate queue cap

The CRM holds 374 companies after a mixed-era list of 644 records was cleaned and narrowed. The counts have different denominators and should not be read as a conversion funnel.

The operating problem

An alert can start a conversation. It cannot decide one.

Our prospects include integrators and teams working on GIS, transport and other public-sector systems. Relevant work appears across procurement and funding sources, often with short decision windows. Earlier research had left us with a large, uneven list and no consistent path from notice to account to next action.

The useful unit is a dated reason to investigate: the source, the potential interface task, the organisation involved, the deadline and the person who must check it. We designed the system around that unit, so a title match never becomes a qualified opportunity by itself.

The workflow

Five decisions between a notice and a conversation

Each stage leaves enough context for the next person to accept, reject or revisit the lead.

  1. 01

    Watch the right sources

    Adapters check TED, UK Find a Tender and Romanian SEAP, then narrow notices to sectors and tasks we can plausibly deliver.

  2. 02

    Match and verify

    The engine links a notice to a named account and keeps the original URL and date. A person checks the actual scope, buyer and contract route.

  3. 03

    Prioritise with reasons

    A 0–100 working priority uses signal type, deadline, contactability and named people. The score orders review; it is not a probability of winning.

  4. 04

    Prepare the approach

    The system drafts a short LinkedIn note and first message from the verified signal. The operator edits or discards them before any contact.

  5. 05

    Carry the next step

    Five rules create follow-up tasks. The open queue stops at 15 so the daily view remains something one person can work through.

What an operator sees

A decision card, not another list of names

A notice is only useful when the operator can answer four practical questions before opening a message draft.

01 / Evidence

What changed?

Open the original notice and confirm its date, scope and deadline.

02 / Fit

Can we do this part?

Separate a real interface task from a broad project keyword.

03 / Route

Who can engage us?

Identify the buyer, prime or partner route before calling it an opportunity.

04 / Action

What happens next?

Review a draft, set a task, defer the account or close it with a reason.

Under the hood

A small system around the CRM

The logic lives in Python, with Twenty CRM as the place where an operator works. The build remains specific to our own workspace.

Input

Public signals

Source adapters collect notices and preserve the record needed to verify them.

Decision layer

Match, score, draft

Scripts connect the signal to an account, explain priority and prepare a relevant first touch.

Working surface

CRM, digest, scoreboard

The daily queue and weekly deltas make both action and lack of action visible.

AI access

Six MCP tools

A small MCP server lets an AI client query the pipeline through five read-only tools and one guarded write.

Current stack: Python · self-hosted Twenty CRM · TED v3 API · Find a Tender · SEAP · MCP over stdio. This is an internal, single-workspace implementation; a client deployment would require its own scope and data design.

Control and scope

Where the automation stops

Source before score

Keyword and code matches can be wrong. The original notice and its documents remain the basis for qualification.

Person before send

Drafts are working material. LinkedIn invitations are manual, and email requires the recorded permission and suppression checks configured for our workflow.

Outcome before claim

We distinguish source records, active signals, drafts, tasks, replies and opportunities. Only a buyer response can move the last two.

Apply the pattern

Have signals your team does not act on?

Show us one source, your current CRM and the decision your team makes after an alert. We can map a bounded workflow around that handoff.