Lead scoring
Transparent by design
Budget, company size, seniority, urgency, service interest, source, engagement, and completeness contribute explicit points to a 0–100 score.
score = Σ weighted, capped factorsRevenue & CRM operations automation platform
Building a reliable operating layer between lead sources and the CRM.
OpsForge is a production-shaped portfolio project for a fictional B2B company. It turns fragmented lead intake into validated, deduplicated, explainable, and observable revenue operations.
01
Business problem
The CRM was not the source of truth. It was the last place errors appeared.
Leads arrived from seven channels with inconsistent fields and no shared orchestration layer. Duplicate records, manual assignment, slow follow-up, silent failures, and unreliable attribution made every downstream report harder to trust.
01Duplicate identities
02Missing qualification
03Wrong territory owner
04Slow first response
05Silent automation failure
06Weak audit trail
Design principleProtect correctness before optimizing speed. Every automated decision should be explainable, reversible, and observable.
02
Proposed architecture
A layered event flow with provider adapters at the boundary.
Core normalization, scoring, routing, and quality logic stays provider-agnostic. Live credentials can replace mock adapters without rewriting the operating rules.
SourcesWebsiteLinkedInAdsReferralWebinarImports
Intake Signed webhooks Schema validation Idempotency
OPSFORGE OPERATIONS ENGINE
NormalizeDeduplicateScoreQualifyRouteFollow up
AdaptersHubSpotSlackGmailCalendarSheetsn8n
Audit eventsRun logsRetriesDead-letter queueOperator alerts
03
CRM data model
Operational entities, not dashboard-shaped data.
The model separates customer records, work, automation configuration, delivery infrastructure, and immutable-style history. This avoids hiding workflow state inside a lead record.
LeadContactCompanyDealOwnerActivityAutomationWebhookIntegrationTaskPipeline StageNotificationAudit EventQuality Issue
Identity
Contact, company, domain, normalized email, and phone support exact and reviewable duplicate matching.
Work state
Activities, tasks, stages, and next actions keep operator work separate from qualification data.
System state
Automations, webhooks, integrations, notifications, and audit events support recovery and accountability.
04
Decision systems
Lead routing
Ordered and versioned
Territory, segment, score, quality, and owner capacity rules execute in a visible priority order with a documented fallback queue.
first complete match → assignmentAI qualification
Supplement, never authority
AI generates summaries, objections, and recommended next steps. Structured mock output takes over when no provider credential exists.
AI output ≠ score or final ownerReliability
Fail visibly
Transient events retry three times. Exhausted failures preserve payload and trace context for operator replay and escalation.
fail → backoff ×3 → manual review05
Current → future state
The workflow becomes a controlled system, not a chain of hidden handoffs.
BEFORESeven unvalidated sourcesManual spreadsheet cleanupUnrecorded assignment decisionsFollow-up depends on memoryFailures discovered through complaints
OPSFORGESingle validated intake contractNormalized and deduplicated queueExplainable score and routing outcomeStage-aware follow-up workflowsRetries, alerts, and replayable history
06
Results from demo
Measured system behavior—without invented business impact.
Because this is a synthetic portfolio environment, the evidence is about product behavior and engineering coverage. It does not claim financial lift or production conversion improvements.
112Synthetic leads
52Synthetic companies
8Pipeline stages
10Versioned SOPs
7Documented APIs
0Paid credentials needed
Verified demo capabilities
- Lead creation validates input, produces a deterministic score, selects a route, and creates feedback.
- Pipeline cards persist stage movement locally and add an audit event.
- Quality review supports fix, ignore, duplicate confidence, and safe-merge gating.
- Webhook tests update delivery status without sending a real external request.
- Provider cards clearly distinguish demo connected, simulated, and credential-required states.
07
Limits & next steps
What this demo intentionally does not claim.
Current limitations
- No real customer or personal data
- No live CRM, email, or AI provider calls
- Local session persistence for interactive mutations
- Synthetic workflow volumes and timing metrics
Production path
- PostgreSQL/Supabase with row-level security
- Managed queues and idempotency store
- OAuth provider connections and secret rotation
- Role-based access and organization boundaries
- Distributed tracing and retention policies