End-to-End Client Acquisition System

This project engineered the core operations infrastructure for BlinkWeb, a CRM and client-acquisition engine that integrated the Norwegian Brønnøysund Register and three phone registries (1881, 180, Gule Sider) via REST APIs to automate data enrichment and contact verification.

Geospatial lead-matching algorithms reduced false positives in candidate identification, and automated outreach plus real-time contract generation eliminated manual handoffs end-to-end.

The system saved approximately 450 hours per year and reduced third-party API costs by roughly $10,000, serving as core infrastructure behind BlinkWeb's operations in 2024.

Affiliation

BlinkWeb

Keywords

CRM
Data Enrichment
Data Validation
Python
REST APIs
MySQL
Web Scraping

From a web studio to a scraping problem

I finished upper secondary school in June 2022 and wanted a part-time job to run alongside university. The one thing I had always been good at was web design, so I registered my own company, BlinkWeb, and started building websites for small Norwegian businesses.

Two photographs side by side under the labels 'from' and 'to': a modern upper-secondary school building on the left, a historic university building flying Norwegian flags on the right, with an arrow between them. — A part-time idea in the gap between videregående and my degree that quietly turned into a company.

Building the sites was never the hard part. Finding people to build them for was.

The time sink

Every new client started with a cold call, and every call started with hours of manual work. Each morning I pulled the companies that had just registered in Brønnøysundsregisteret, then hunted for a phone number for each one across 1881, Gule Sider, and 180, because the registry’s API never hands out phone numbers. Then I stripped out everyone who had opted out of marketing calls, since calling a reserved number is illegal under the Norwegian Marketing Control Act. Only what survived became a call list.

That was hours gone before the first dial, every day. So I built a pipeline that does the whole thing while I sleep.

How it works

Flowchart of the pipeline. The Brønnøysund registry API feeds a data collector that enriches each company from the 1881, 180, and Gule Sider directories. A comparator resolves the phone number by majority vote. Surviving leads are checked against the do-not-call registry; reserved numbers are discarded and the rest are written to MySQL and exported as CSV. — The end-to-end pipeline. Green is a lead that reaches the call list; red is data dropped along the way.

Pulling in the day’s companies. The collector asks the open registry API for every unit registered in the last 24 hours, filtered to the industries I sell to. That gives name, organisation number, and address, but never a phone number. That single gap is what the rest of the pipeline exists to close.

Finding a number, at a human pace. The collector works the public directories in a fixed order, 1881 first, Gule Sider as fallback, 180 as last resort, moving on only when the previous one comes up empty. Every request is spaced by a random, human-sized delay with the occasional long pause, so the scraper reads like one person browsing rather than a bot hammering the site.

Diagram of human-paced request timing: a pacer sleeps a random amount before each call; directories are tried in order; a timeline shows jittered gaps of 31 s, 12 s, 44 s, 19 s, a 2 min 47 s long pause, 27 s, 38 s, averaging near 53 seconds. — Each request waits a random 10 to 45 seconds, with an occasional long pause that mimics someone stepping away.

Making sure it’s the right number. Norwegian names are not unique, so a naive lookup happily hands you the number of a different “John Doe”. The system verifies each candidate geographically: it compares the postal code of the person’s home address against the registered business address and keeps the closest match. Same name on the other side of the country is rejected; same name a few kilometres away is almost certainly the owner.

A map of south-eastern Norway. Several people named 'John Doe' are pinned at different home addresses, each compared against a business address in Skien. Distant candidates are rejected in red; the nearest, in Porsgrunn, is accepted in green. — Disambiguating by postal-code distance. When several records share a name, the one closest to the business address wins.

Resolving, filtering, and storing. When several directories return a number, a comparator settles it by majority vote; if none does, the company is dropped. Every surviving number is checked in bulk against the do-not-call registry, and anyone who has opted out is removed here, at the pipeline boundary, so a reserved number can never leak into a call list downstream. What is left goes into a MySQL database keyed on the organisation number, which makes reruns idempotent and deduplicates leads across days.

Where it runs. The collector, the comparator, and the daily scheduler all run on an old Linux computer repurposed into a headless server at home. The only hosted piece is the database, so the leads are backed up and always available. My BlinkWeb site pulls fresh call lists straight from it.

Infrastructure diagram. A repurposed Linux computer at home runs the collector, comparator, and cron scheduler, reaching the registry API and phone directories over HTTPS. Verified leads go to a MySQL database on managed hosting, which the BlinkWeb website queries to serve CSVs. — The pipeline runs on a second-hand machine at home; only the database is hosted. No cloud bill.

Results

A multi-hour manual routine became a scheduled job that leaves a deduplicated, legally compliant call list waiting every morning.

~450 hours per year reclaimed from manual list-building.
~$10,000 per year saved against the two realistic alternatives: paying someone part-time, or paying for the commercial 1881 API at the volume the business needed.

What I took away

What started as a way to avoid a boring morning chore was the thing that made running a company and studying full-time at the same time possible.