GENZAX AI Client Acquisition System

A schedule trigger at 00:00 Asia/Karachi starts the run; a webhook does the same thing on demand when a specific target is being tested. The controller normalises whichever input arrived, reads campaign settings, resolves the day's target and validates it — an invalid target creates an error campaign rather than failing quietly halfway through. It then calls Lead Discovery, splits the returned prospects and walks them one at a time through research, problem detection, service matching and qualification, with a deliberate rate-limit wait between calls. Only qualified leads reach the email generator. When the loop drains, the controller reads the leads back, computes the run's counts and closes the campaign record.

Called by the controller rather than triggered on its own. It reads the campaign settings, builds the targeting criteria from them, and hands those to a discovery agent whose output is forced through a structured parser, so downstream nodes receive consistent fields instead of prose they would have to guess at. Everything it finds is checked against the existing lead table before a single row is written: only genuinely new prospects are inserted, and the workflow returns a summary of what it actually added rather than what it looked at.

Takes a lead ID, loads the record and marks it as being researched before doing any work, so a second run cannot pick up the same prospect and duplicate the effort. The research stage gathers publicly available signals about the business — what the site is like to use, what services it lists, how it asks people to get in touch, how it captures leads — and the result is written back onto the lead itself before being returned to the controller. Every later module reads that same record, which is what lets them run independently.

Reads the researched lead and asks for one real, evidence-backed problem, with a structured parser holding the answer to a fixed shape rather than a paragraph. A gate then decides what happens next: a lead whose evidence supports a genuine problem has it stored and continues down the pipeline, and a lead where it does not is rejected here. That branch is the point of the module — it is cheaper to drop a prospect at this stage than to write a confident email about a problem nobody has.

Loads the lead and checks first whether it was already rejected upstream — those return unmatched immediately and cost nothing further, which is why the rejection branch sits before the model call rather than after it. Everything else goes to a matching step that maps the detected problem onto the service that actually addresses it: AI Automation, AI Agents, Voice AI, Web Development, SaaS Development, SEO or Digital Marketing. The chosen service is stored on the lead, and it is what the email generator later writes from.

Loads the lead together with the campaign settings, then scores it in code rather than through a model, so the same inputs always produce the same number and a score can be explained after the fact. The score combines service fit, problem severity, business quality, buying potential, contact quality, personalization potential and how much confidence the evidence supports. A threshold that lives in settings — not in the workflow — splits the result: qualified leads are marked and passed on, and the rest are marked rejected and stop here.

Runs only for leads that passed qualification; anything else returns skipped without spending a model call. For the rest it drafts a short email from that specific lead's research and detected problem, parses the result into subject and body fields, and stores the draft on the lead record. Nothing is sent from here. Generating and sending are deliberately different workflows, which is what makes it possible to review a whole batch of drafts before any of them can go anywhere.

Runs hourly on its own schedule rather than inside the daily run, so approvals are not held hostage to when the pipeline happens to finish. It reads settings, pulls the leads carrying a pending draft, and loops them one at a time. Each one stops at a human approval step: the draft is read and the decision is resolved before anything else happens. A second gate then decides whether an approved message is actually sent or only simulated, and the two outcomes are marked differently on the lead — which is how the whole path can be exercised end to end without mail leaving the building.

The only module triggered by incoming mail rather than a clock. It parses each message, looks the sender up against the lead table, and branches on whether it found a match. A matched reply is recorded against that lead, and that record is precisely what stops the follow-up engine from continuing to chase somebody who has already answered. Mail that matches nothing is logged rather than discarded, so an address that changed or a forward from a colleague leaves a trace instead of vanishing.

Runs daily at 09:00 Asia/Karachi. It reads the leads that were sent to, then immediately filters out everyone who must not be contacted again — replied, bounced, do-not-contact, or manually stopped — before any dates are calculated, so a suppressed lead never reaches the part of the workflow that could message it. What survives goes through a due-date calculation, and only the follow-ups genuinely scheduled for today enter the loop. Each one gets a short generated follow-up and passes the same live-or-test gate the outreach manager uses, with test sends recorded separately from live ones.

The last thing to run, at 23:30 Asia/Karachi, once the day's work has finished. It reads the campaign record and every lead attached to it, aggregates the run into one summary, and stores that report alongside the campaign so days can be compared rather than just observed. It is the only place in the system that looks at a run as a whole, which is what makes it the place to notice that discovery found plenty but qualification passed almost nothing.