0. Introduction: The Hidden Complexity of Staff Matching
I’m working on a service that matches staff members with customer requests.
At first glance, the problem looks trivial:
- Pick the nearest staff member
- Or assign someone who is available
But in reality, staff matching quickly becomes complicated once you consider real-world constraints:
- Each job has a fixed start time and duration
- Staff members already have scheduled jobs
- Different locations imply travel time
- Skill requirements must be satisfied
Once you try to handle all of these at the same time,
simple nearest-neighbor searches or availability checks start to break down.
At the same time, we often have strong practical requirements:
- We need to select one staff member in real time
- We don’t want heavy optimization (ILP / MIP solvers)
- The logic must be explainable and operable in production
This article describes a practical matching approach that actually works under those constraints.
What This Article Covers (and What It Doesn’t)
What this article covers
- A practitioner-oriented way to frame the problem
- A simple but powerful insertion-based algorithm
- Why this approach works well in real systems
- Engineering decisions that make it maintainable
What this article does not cover
- Mathematical formulations
- Exact optimization models
- Detailed solver implementations
This is intentionally not an academic treatment.
1. Problem Setting (From a Practitioner’s Perspective)
We consider the following matching problem.
Job (Request)
Each job has:
- Start time
- Duration (e.g. 30-minute units, up to several hours)
- Location (latitude / longitude)
- Required skills
Staff
Each staff member has:
- A set of skills
- Existing scheduled jobs (each with time and location)
- A base location (e.g. office or home)
Constraints
- A staff member cannot work on overlapping jobs
- Travel time between locations must be considered
- A free time slot does not necessarily mean feasibility
Goal
Given a single job request, select the best staff member in real time.
This is closer to a recommendation problem than a global assignment problem.
2. Common but Broken Approaches
Before describing the solution, it’s useful to look at approaches that often fail in practice.
Picking the Nearest Staff Member
- Ignores the staff member’s previous job
- Travel time may make the job infeasible
- Schedules look valid on paper but fail in reality
Picking Anyone Who Is Available
- Time gaps are misleading
- Feasibility depends on adjacent jobs
- Decisions are hard to explain afterward
Global Optimization (ILP / MIP)
- Computationally expensive
- Complex to implement and operate
- Poor fit for real-time, online decisions
These approaches are reasonable in theory, but often don’t survive production constraints.
3. A Shift in Perspective: From Assignment to Insertion
Here is the key mental shift.
A staff member’s day can be represented as a sequence of (time, location) pairs:
[ 09:00 @ A ] → [ 11:00 @ B ] → [ 15:00 @ C ]
A new job is not something to assign globally.
It is a block that might be inserted somewhere into this sequence.
So the core question becomes:
Can this job be inserted into the staff member’s schedule without breaking feasibility?
This framing turns a complex matching problem into a series of local feasibility checks.
4. Insertion Heuristics (In Plain Terms)
After implementing this approach, I later learned that it has a name:
Insertion heuristics.
They are commonly used in:
- Vehicle Routing Problems (VRP)
- Technician Scheduling Problems
- Dynamic routing and scheduling
The general idea is:
- Take an existing route or schedule
- Try inserting a new job at a feasible position
- Choose the insertion with the lowest cost
In our case:
- Jobs arrive online, one by one
- We must decide immediately
- We only select one staff member
5. Algorithm Overview (Implementation-Oriented)
The algorithm itself is surprisingly simple.
- Filter by required skills
- Filter by coarse time availability
- Find the immediately previous and next jobs
- Check feasibility including travel time
- Compute an insertion cost
- Select the staff member with the lowest score
Two principles matter most:
- Check feasibility before scoring
- Only score candidates that actually work
This keeps the algorithm fast and robust.
6. Why This Works Well in Practice
This approach works well in real systems for clear reasons:
- Low computational cost
- Suitable for real-time responses
- No need for post-hoc constraint fixing
- Business logic fits naturally into the scoring function
It feels like optimization,
without behaving like heavy optimization.
7. Engineering Design: Keep the Algorithm Pure
One important design choice is keeping the matching logic as a pure function.
Key principles
- No database access inside the algorithm
- All required data is passed as a snapshot
- Same input always produces the same output
Benefits
- High reproducibility
- Easy unit testing
- Simple A/B testing
- Easy replacement or extension in the future
This separation pays off quickly in real projects.
8. Why We Don’t Encode This in SQL
It’s tempting to push matching logic into complex SQL queries.
In practice, this often leads to:
- Large JOINs
- Window functions everywhere
- Hard-to-debug logic
- Unstable query performance
Matching logic is procedural by nature:
- Find adjacent jobs
- Check travel feasibility
- Evaluate insertion cost
These steps are far more naturally expressed in application code than in SQL.
9. Practical Notes on Data Loading
This does not mean loading everything into memory.
In production systems:
- Pre-filter candidate staff members
- Load only nearby or relevant scheduled jobs
- Keep snapshots minimal and fresh
Final booking should still be handled by a separate, transactional process.
Separating recommendation from commitment keeps the system stable.
10. Limitations and Trade-Offs
This approach is not perfect.
- It does not produce a global optimum
- It is not suitable for batch optimization of many jobs
However, for the question:
“Who should handle this job right now?”
…it delivers more than enough value.
11. Conclusion
- Real-world constraints naturally lead to insertion-based thinking
- Heavy optimization is not always the right tool
- Choosing not to optimize globally is also a design decision
Even with time, travel, and skill constraints,
a practical and maintainable solution is possible.
Top comments (0)