The matching & routing engine behind your lead operation
Match every request privacy-safe on relevance, region and field, and distribute on your own rules, caps and distribution models. All under your own brand, without building it yourself.
A request is only valuable if it lands with the right buyer. An employment-law case from the north of the country does not belong with a specialist in the far south, and a buyer who has already reached their daily cap does not want an eleventh lead that ends up sitting idle anyway. Matching and routing are the two steps that take care of this: first deciding which buyers substantively qualify, then who the request ultimately goes to.
OXIAE’s routing engine does this in real time and verifiably, as a standard part of your lead platform. Every verified request is assessed against your matching criteria the moment it arrives, and then distributed according to your own rules, priorities and limits. No manual cutting and pasting from a spreadsheet, no distribution key that lives in someone’s head, but a transparent model that scales with your volume, runs under your own brand, and where every decision can be traced back in the audit trail.
Smart matching
Every request lands with the buyer that fits it best: substantively, geographically and operationally.
Relevance & intent
Match requests on topic, intent and context, so buyers only get what genuinely fits them.
Region
Distribute requests by postal code, service area or radius, so the request reaches a buyer nearby.
Field & specialization
Route on specialization and expertise, from service category to niche, for a substantively correct match.
Capacity & availability
Factor in current capacity and availability, so requests land where they will actually be picked up.
Quality thresholds
Only verified requests that meet the agreed quality requirements are passed through.
Privacy-safe
Matching happens on the necessary attributes only, with data minimization and consent as the starting point.
What does privacy-safe matching mean?
Privacy-safe matching means the distribution decision is made on as little personal data as possible. The engine matches on pseudonymous attributes (topic, intent, field, region at postal-code level and capacity) and not on name, address, email or phone number. You simply do not need that direct data to make a good match.
The full contact details only become visible to a buyer after they have accepted the request. Until that moment the buyer only sees what is needed to assess whether the request fits. This way, data minimization is built into the flow: data is never shared more broadly than strictly necessary, and every release is tied to consent and provenance, traceable in the audit trail. GDPR-compliant, without you having to build a separate layer around it yourself.
What a buyer sees, and when
Before acceptance
Field, intent, region (postal-code level), quality score and capacity: pseudonymous, no traceable contact details.
After acceptance
Full contact details, tied to recorded consent and provenance.
The distribution models explained
How you distribute requests largely determines your acceptance and utilization. These are the four base models you can combine in the engine, plus price-based routing that sends volume to the best bid. Each model has its own pros and cons.
Round-robin
Requests go in turn to each suitable buyer in the pool. Fair and simple: everyone gets roughly the same volume.
Weighted distribution
Each buyer is assigned a weight. Whoever has more capacity, higher acceptance or a larger budget receives proportionally more requests.
Exclusive
One request goes to exactly one buyer. No one else receives the same lead, ideal for high-value, scarce requests.
Shared
The same request goes to a limited, pre-agreed number of buyers. The requester can choose, and buyers compete on speed and offer.
Price-based routing
Let price weigh in: requests go to the buyer with the best bid that meets your rules. You set floors and conditions in advance, so revenue never comes at the expense of relevance or quality. Combinable with any of the four models above.
A routing rule in practice
Say you want to preferentially send employment-law requests from the north of the country to Buyer A, as long as they still have room. If Buyer A’s daily cap is reached, the request should go to Buyer B. With an if-then rule you capture that in one go, no code, in your own dashboard.
The engine evaluates this rule in real time on every incoming, verified request. The conditions (field, region and capacity) are tested on pseudonymous attributes, so without any contact details involved. The outcome and the conditions traversed are logged, so you can later trace exactly why the request ended up with Buyer A or B.
Routing rule
IF field = employment law
AND postal code in region North
AND Buyer A under daily cap
THEN -> route to Buyer A
ELSE -> route to Buyer BThe order of conditions determines the priority. You can stack rules and choose a different outcome per pool, label or segment.
Routing on your rules
You decide how requests are distributed: the engine executes it in real time and verifiably, under your own brand.
Rules & priority
Decide for yourself the order and conditions under which buyers qualify.
Distribution
Round-robin, weighted, exclusive or shared: distribute requests exactly how you want.
Limits & caps
Set daily, weekly or monthly limits per buyer, label or segment.
Real-time
Decisions and routing in milliseconds, the moment a request arrives.
How do you set up matching?
From an empty configuration to a live distribution model in four steps, no code, with rules you can adjust at any moment.
Define your buyers and pools
Record per buyer which field, which service area and which quality requirements apply. Group buyers into pools that respond to the same kind of requests.
Set your matching criteria
Determine which pseudonymous attributes you match on: topic, intent, region at postal-code level and capacity. Full contact details stay out of the match decision.
Build your routing rules and limits
Capture the order, priority and conditions with if-then rules, and set daily, weekly or monthly caps per buyer, label or segment.
Test, publish and monitor
Run rules first in test mode against real requests, then publish them and track acceptance, lead time and distribution live in the dashboard.
OXIAE’s routing engine vs. manual distribution
What you gain when you move from a spreadsheet and manual work to rule-driven, privacy-safe distribution.
Why OXIAE’s routing engine
Smart distribution is not a standalone feature, but the link between verification and payout in your platform. Three reasons why it works differently at OXIAE than in traditional lead trading.
Higher acceptance
Relevant, verified requests reaching the right buyer lead to more acceptance and less drop-off.
Privacy-safe matching
Matching on only the necessary attributes, with consent and provenance demonstrably recorded.
Under your control
Your rules, limits and priorities determine the routing: transparent, white-label and adjustable at any moment.
Frequently asked questions about matching & routing
The most-asked questions about how requests are matched and distributed in the platform.
What is the difference between matching and routing?
Matching determines which buyers substantively qualify for a request, on topic, intent, region and specialization. Routing then determines who the request actually goes to, based on your rules, priorities, limits and distribution model. Matching is the substantive filter, routing is the final distribution decision.
On which attributes exactly does the platform match?
The routing engine matches on the attributes needed to make a good match: topic, intent, field or specialization, region at postal-code level, quality thresholds and the current capacity of buyers. Directly identifiable data such as name, email address and phone number play no role in the match decision.
When does a buyer see the full contact details?
Only after the buyer has accepted the request. Until that moment the buyer only sees the pseudonymous attributes needed to assess whether the request fits. Data minimization is thereby built into the flow, not something you have to arrange afterward.
Can I use multiple distribution models at the same time?
Yes. You can choose a different model per pool, label or segment. High-value requests can be distributed exclusively, while larger volumes run through weighted distribution or round-robin. Price-based routing sends requests to the buyer with the best bid. The rules determine which model applies when.
What happens when a buyer reaches their daily cap?
As soon as a buyer hits their configured cap, they are automatically skipped in the routing and the request goes to the next suitable buyer according to your rules. This prevents leads from piling up with someone who can no longer follow up on them.
How fast does a routing decision happen?
Real-time, in milliseconds, the moment a verified request arrives. Every decision is logged immediately in the audit trail, so you can always trace why a request ended up with a particular buyer.
Ready to distribute requests more smartly?
Book a demo and see how the routing engine, with privacy-safe matching and rules on your terms, brings the right request to the right buyer, under your own brand.