Automatic detection
The service runs continuously and picks up every approval request the moment the agent files it in the CRM. Nobody has to trigger anything.
Case study2025
Approval Engine — automating CRM quality checks
A business rules engine for internal processes
Managers were checking by hand, request after request, whether an agent had actually done the work: how many calls, across how many days, at what hours, with what follow-up. We built the engine that runs those checks for them and pre-fills the approval sheet — without ever making the final call.
StackNode.jsTypeScriptZodLuxonCRM API (Laravel)
- Client
- Travel agency · sales + QA/management
- Project type
- Internal process automation (rules engine)
- Our role
- Architecture, development, CRM integration
- Status
- Delivered · Phase 1 live
The context
The manager was doing detective work.
In the client's CRM, every flight request from a prospect is a sales opportunity. When an agent fails to convert one — because they couldn't reach the customer, say — they can't simply close it. They have to request a manager's approval.
And the manager had to verify it by hand, every single time: did the agent actually call? How many times? On different days? At different hours? Did they leave a voicemail? Send the follow-up emails? Send a price quote? That meant a human digging through call history, counting, comparing timestamps, checking emails — for every request. Dozens a day.
- Manual digging through CRM history for every close request
- Dozens of requests a day — slow and draining
- Inconsistent: some checked rigorously, others waved through
- Gaps in the sales process, exactly where they cost the most
“
They needed a system that applies the rules identically to every request — no matter who reviews it, or how busy the day is.
What we built
A rules engine that does the groundwork.
The service runs continuously in the background. For every new approval request it detects it, gathers the evidence, applies the company's rules and ticks the results straight into the approval screen. When the manager opens the request, they no longer face an empty checklist — they see a completed sheet showing what was met and what wasn't.
Request in CRM
Approval Engine
Pre-filled sheet
The agent files the request, the engine picks it up in the background, and the manager opens a sheet that's already checked — green on what was met, red on what wasn't.
How it works, step by step
Gathers all the evidence
Full call history, follow-up emails, price quotes sent, and the customer's contact details — pulled together in one place.
Applies the company's rules
The real rules, written by management. If the customer has both a phone and a valid email: at least 4 worked days out of 7, at least 2 calls a day at different hours (a minimum of an hour apart), a daily follow-up, a voicemail and a price quote. Email only — a different set. Phone only — another.
Pre-fills the approval sheet
Results are ticked automatically in the approval screen, green and red on every criterion. The manager reads instead of digging.
The core principle
The human decides, not the robot.
We built the system around one firm rule, agreed with the client from day one: nothing is ever approved automatically. The engine checks, measures and pre-fills, but the final Approve/Reject call stays 100% with the manager. It saves their time; it doesn't take their responsibility.
And where the engine can't verify something with certainty — the actual content of an email it has no access to, for instance — it doesn't guess and it doesn't assume. It explicitly flags the criterion as “to be checked manually”.
Zero automatic approvals
The engine never presses the button. Approve/Reject stays a human decision, signed off by a manager.
No false confidence
Anything that can't be verified with certainty is flagged “check manually” — never assumed to be met.
Full transparency
The manager knows exactly what was checked automatically and what is still theirs to do. No black boxes.
Details that make the difference
The hard part isn't the rule. It's what “a day” means.
01
Getting “worked days” right
The “4 days out of 7” rule looks simple, but it depends on the time zone: a call at 23:30 and one at 00:30 may be the same day or two different days, depending on where you look from.
Details that make the difference
We group calls into days using a configurable time zone — the company's business zone — so the result is always the one management expected, not the one a naive UTC calculation produces.
02
It doesn't reprocess for nothing
Blindly re-evaluating every request on every cycle would burn resources and keep constant load on the CRM.
Details that make the difference
The system keeps a fingerprint of each request and re-evaluates only when something relevant actually changed — a new call, a new email, an edited contact. With a safety net: periodically, every request is fully re-checked anyway, to catch silent changes such as a call recording that arrives late.
03
Restart-proof
A service that runs continuously will be stopped, updated and restarted — and mid-evaluation that can mean duplicated results or dropped requests.
Details that make the difference
State is persisted to disk and writes back to the CRM are idempotent. The service can be stopped and restarted at any time without duplicating results or losing requests.
04
Thresholds change without touching code
Sales policy changes. If “2 calls a day” is buried in the logic, every adjustment becomes a code change.
Details that make the difference
“2 calls a day” and “at least 60 minutes apart” are configuration, not logic. When management changes the policy, a value changes — a rule doesn't get rewritten.
The outcome
Managers open the request, see it, and decide.
Managers no longer do detective work through the CRM history. The rules apply identically to every request, no matter who reviews it or how busy the day is — which means an agent can no longer close an opportunity without having actually done the work, and one who did is approved immediately, with zero friction.
The architecture is modular: every close reason is its own rule module. Phase 1 shipped the most frequent and most expensive reason to verify — “couldn't reach the customer” — and the next phases add the remaining reasons without touching what already works.
0
Automatic approvals — the manager still decides
3
Rule sets, based on available contact details
4/7
Worked days — the threshold checked automatically
24/7
Running continuously in the background
Got a process that depends on who happens to review it?
We turn it into a rules engine that applies the same criteria every time — without taking the human out of the decision.