Finding EPC Projects Before They Become Tenders
Designing a multi-source lead intelligence system for the industrial capex sector.
Sector: specialty chemicals, petrochemicals, fertilisers, pharma APIs, refining · Engagement type: systems design, data architecture, and validated prototype
Domain
Industrial capex project intelligence for an EPC engineering firm
Core problem
Business development discovers projects at tender stage, too late to shape them
Approach
Monitor upstream regulatory and procurement signals instead of downstream news
What we designed
A five-stage ingestion-to-serving pipeline with AI qualification and composite lead scoring
What we built
A working prototype dashboard, seeded with real Indian capex pipeline data, to validate the model before committing to a full build
Signal lead time
Roughly 6-18 months ahead of public tender
EPC firms compete on a funnel that leaks at the top.
By the time a project appears on a public tender portal, the scope is frozen, the technology licensor is chosen, and every competitor in the country is looking at the same notice on the same day. What's left is a price fight on someone else's specification.
Manual discovery
Four to six hours a day of someone checking a handful of portals by hand.
Narrow coverage
Two or three sources monitored consistently; dozens more that matter, ignored.
No prioritisation
Every lead looks equally urgent, so gut feel decides what gets worked.
Missing contacts
A project is identified, but nobody knows who the decision-maker is, so the lead dies in a spreadsheet.
No memory
Pipeline history scattered across inboxes, WhatsApp threads, and personal notes.
Existing approaches in the market mostly scrape news articles. News is a downstream signal. A project is reported once it's already public knowledge, and that's the same day everyone else finds out.
Industrial projects leave a regulatory paper trail long before they leave a news trail.
Before a plant is built, its promoter has to ask permission repeatedly, publicly, and in a predictable sequence. Environmental clearance filings, industrial land allotments, corporate disclosures, and statutory approvals all become public record months or years before a tender is floated. That sequence is the map. The engineering problem isn't “get more data.” It's connect fragmented sources, resolve them into a single project entity, and score what matters.
A five-stage pipeline, one distinct failure mode per stage.
Stage 1
Ingestion (Collectors)
A collector layer polling several hundred catalogued sources across seven categories: environmental and statutory clearance portals, corporate announcements and disclosures, government information portals, corporate affairs and registry filings, tender portals, trade publications, and supplementary signals like customs records and site-level hiring activity. Each source is documented with its access method, parsing strategy, and polling cadence. High-frequency sources are swept daily, slow-moving registries weekly. Nothing is discarded at ingestion, because a weak signal today is often corroboration tomorrow.
Stage 2
Parsing & normalisation
Sources arrive as HTML tables, scanned PDFs, structured APIs, and free text. This stage flattens all of it into a common Lead Event record: a single observation, from a single source, at a single point in time, with its own confidence and provenance attached. Language models do the extraction work regex can't, pulling promoter names, project descriptions, capacity figures, locations, and capex values out of unstructured filings.
Stage 3
Entity resolution
This is where most systems of this kind quietly fail. One real-world project generates many events: a clearance application, a land allotment, a corporate announcement, a hiring post, arriving weeks apart under slightly different names. The resolution layer collapses those events into a single Project record, matching on promoter identity, geography, sector, and capacity. The output is one project with a history, not five duplicate leads competing for attention.
Stage 4
Scoring & validation
Each resolved project receives a composite score across six weighted dimensions: sector fit, capex band, stage, geography, confirmation, and recency. A business rules engine applies hard qualifying and disqualifying logic, the deterministic constraints that shouldn't be left to a probabilistic model. Every score is decomposable in the interface, so a BD lead can see exactly which sub-scores drove the ranking and disagree with it.
Stage 5
Serving
Scored, ranked projects surface into a dashboard built for a BD team's actual working day, not for a demo.
Sector fit
How closely the project maps to the firm's actual engineering strengths
Capex band
Whether project size falls inside the firm's viable range
Stage
How far the project has progressed through the approval sequence
Geography
Proximity to the firm's execution and site-management capability
Confirmation
How many independent sources corroborate the project
Recency
How fresh the most recent signal is, decaying older, quieter projects
An AI-assigned score is a prioritisation aid, not a verdict. Every score is decomposable in the interface, so a BD lead can see exactly which sub-scores drove the ranking and disagree with it.
What does a BD lead need in the first ten minutes of their morning?
The interface was specified around that single question, built for a BD team's actual working day, not for a demo.
Daily ranked leads
The top opportunities of the day, with composite score and source attribution visible before any click.
Pipeline board
A kanban view tracking projects across the real approval sequence (MoU → Form-1 → EAC → EC granted → CTE granted → construction), mirroring how projects actually move.
Lead drawer
Full detail on a single project: score breakdown by sub-score, status timeline, every contributing source, and verified decision-maker contacts.
Contact enrichment
Multi-source decision-maker discovery with AI-assisted verification, closing the gap where good leads used to die.
Drafted outreach
AI-generated first-touch sequences, held behind a mandatory human review gate. Nothing sends itself.
Live alerting
Notifications when a tracked project changes stage.
Source monitoring
A health view showing which collectors are running, which are failing, and when each last returned data.
Analytics
Coverage, throughput, and pipeline movement over time.
Access control
Designed for private deployment. Password reset and new-user registration are both admin-gated rather than self-service, which is appropriate for a system holding a firm's commercial pipeline.
Deployment posture
Designed to run on the client's own infrastructure. The client controls the deployment, the database, and every record in it.
Designed and roadmapped.
Lead generation is the top of the funnel. The heaviest unbillable cost inside an EPC firm sits further down, in proposal engineering. Three additional modules were specified against that cost.
BOQ extraction
Automated bill-of-quantities extraction from tender documents and drawings, replacing days of manual take-off.
P&ID intelligence
Identifying instruments, valves, lines, and tags against ISA standards; cross-referencing against project specs and the instrument index; auto-generating equipment lists and deviation reports. Covers symbol recognition, tag extraction and validation, line tracing, and deviation detection.
Electrical calculations
Cable sizing, load calculations, and protection coordination, applying relevant IEC and IS standards plus project-specific constraints, producing calculation sheets an engineer reviews and signs off.
The pattern across all three is the same one we apply everywhere: the machine does the repeatable logical work; the human keeps the judgement.
Prototype before build.
We did not go from architecture document to production build. Instead we built a working prototype dashboard, the full interaction model, seeded with real Indian capex pipeline data, not lorem ipsum, and put it in front of the people who'd have to use it. That's a deliberate methodology, not a shortcut. A prototype on real data does three things a slide deck can't:
01
It proves the source strategy actually returns projects worth looking at.
02
It surfaces the disagreements early, about scoring, about stages, about what “qualified” means, while they're still cheap to resolve.
03
It gives the client something to react to rather than something to imagine.
What it validated: that upstream regulatory monitoring surfaces genuine, contactable industrial capex opportunities well ahead of the tender cycle, and that composite scoring across those signals produces a ranking a domain expert agrees with.
Multi-source data architecture: designing ingestion across hundreds of heterogeneous, unreliable, and largely undocumented public sources
Entity resolution at scale: the unglamorous problem that determines whether a system like this is usable or noise
LLM-assisted extraction and classification applied to unstructured regulatory and corporate filings
Composite scoring model design that stays transparent, decomposable, and arguable by the humans using it
Domain-native product design: a pipeline board that follows the statutory clearance sequence, because a generic CRM funnel would have been wrong
Deep sector engineering literacy across ISA standards, P&IDs, BOQs, and IEC/IS electrical practice
Prototype-first validation, proving the concept on real data before committing to a full build
Client-owned deployment, with architecture designed for private infrastructure and full client data control
The specifics here are EPC. The pattern isn't.
Any business whose best opportunities are legible in public data before they're legible in the market has this same system waiting to be built: the fragmented sources, the entity resolution problem, the scoring question, the “who do I actually call” gap.
We don't automate your workflows. We engineer your intelligence.
Client identity withheld. This case study describes Inficore's capability, methodology, and design approach.
Have a similar
problem to solve?
Tell us how the work flows today, and we'll show you the system it deserves.
Book an Operations Systems Audit