Custom manufacturing CRM for dealer leads, quotations, and production-adjacent follow-ups

Project overview

The client — a leading manufacturing company we refer to here under NDA — produces industrial components sold primarily through authorized dealers and regional distributors across India. Their sales motion is relationship-heavy: enquiries arrive by phone, email, WhatsApp, trade shows, and dealer walk-ins. Quotations often depend on SKU mix, volume breaks, freight zones, and negotiated dealer tiers that do not fit cleanly into a product catalog. Production planning sits adjacent to sales — when a large dealer order lands, operations needs visibility early enough to slot capacity without treating every CRM record as a firm production commitment.

Before this engagement, the company had evaluated Zoho CRM and two vertical manufacturing packages. Sales leadership rejected them for the same reasons we hear often in Surat and broader Gujarat industrial regions: licensing per seat added up across twelve regional offices, pricing rules could not express dealer-specific floors and promotional overrides without painful workarounds, and WhatsApp — where a majority of dealer conversations actually happen — was either missing or bolted on as an afterthought. IT wanted something they could host with audit trails, integrate later with their existing ERP export routines, and extend without waiting on a vendor roadmap.

Web6 was engaged for sixteen weeks to build a bespoke CRM from the ground up. The stack is Laravel on the API layer, React for the sales-facing UI, PostgreSQL as the system of record for leads and quotations, Redis for queues and session caching, Docker for reproducible deployments on AWS behind Cloudflare. WhatsApp Business API integration logs inbound dealer messages to the correct lead or account where phone numbers match, with manual linking when they do not. We scoped deliberately: phase one replaces Excel tracking and quotation chaos; deep ERP two-way sync was documented as phase two rather than risking timeline slip.

The engagement included five Web6 team members — backend, frontend, DevOps, QA, and a delivery lead — working daily with client SMEs from sales operations, one regional sales head, and IT. Outcomes were measured operationally: faster first response to dealer enquiries, elimination of parallel Excel trackers, and full weekly adoption by field sales. We did not publish revenue percentages or fabricated ROI multiples; leadership cared about control, visibility, and stopping pricing mistakes before they reached production.

Engagements like this are delivered through Web6 custom CRM development for manufacturers .

Business and operational challenges

Lead intake was fragmented. Regional managers maintained separate Excel files for dealer enquiries, often emailed as attachments with conflicting version numbers. A dealer might call the Surat office Monday, WhatsApp a junior rep Tuesday, and email a quotation request Wednesday — with no single thread tying those touchpoints together. Duplicate leads were common; so were leads that went cold because follow-up responsibility was unclear when territories overlapped during a distributor transition.

Quotation workflows lived outside any system of record. Reps built quotes in Word templates or spreadsheet calculators, applied discounts from memory or hidden tabs, and saved PDFs to shared drives with filenames like “Final_v3_revised.pdf”. Finance discovered sub-floor pricing only at order booking. Production occasionally received verbal “rush” flags that never made it into a structured handoff, creating tension between sales promises and shop-floor reality.

Pricing visibility had to differ by role without exposing confidential rate cards. Area sales managers needed to see floor and target bands for their region; junior reps needed guardrails that blocked or flagged quotes below floor; leadership needed audit history when exceptions were approved. Off-the-shelf CRM price books assumed SKU-list simplicity this business did not have — their logic mixed category discounts, dealer tier, freight zone, and seasonal promotions with explicit precedence.

WhatsApp was the unofficial CRM. Dealers preferred it for quick stock checks, photo-based defect reports, and informal negotiation. None of that was logged against CRM records unless a rep manually copied messages into Excel notes — which almost never happened on busy days. Leadership wanted WhatsApp logging that respected privacy and did not spam dealers with bot messages, while still giving managers a defensible history when disputes arose.

• ✓ Dealer and distributor leads scattered across Excel and WhatsApp
• ✓ Quotation errors from manual pricing outside guardrails
• ✓ No unified follow-up ownership across regional offices
• ✓ Production-adjacent urgency invisible until too late
• ✓ Rejected Zoho and vertical SaaS for flexibility and TCO
• ✓ Need for role-based pricing without exposing full rate cards

Goals and success criteria

The primary product goal was a single CRM where every dealer enquiry — regardless of channel — lands as a lead with owner, stage, and next-action date. Reps create quotations inside the CRM with SKU lines pulled from a maintained product master, pricing computed from tier rules, and PDF export that matches what finance expects. Managers approve exceptions through a queue with mandatory reason codes rather than Slack threads.

WhatsApp integration goals were narrow and honest: capture inbound messages to mapped dealer accounts, allow reps to reply from the CRM web UI using WhatsApp Business API templates where required, and attach conversation snippets to lead timelines. We explicitly did not promise AI summarization or chatbot qualification — the client wanted reliable logging first.

Role-based pricing visibility was non-negotiable. Junior reps see computed quote lines with green/yellow/red indicators against floor rates; they cannot export hidden columns from a spreadsheet because those columns do not exist in their view. Area managers see bands and can approve overrides; leadership sees cross-region exception reports weekly.

Production-adjacent follow-ups were modeled as lead stages and tasks, not as a full MRP module. When a quotation crosses a configurable value threshold or includes SKUs flagged as capacity-sensitive, the CRM creates an operations notification task with read-only quote context — enough for planning to acknowledge without duplicating ERP BOM logic in phase one.

Discovery and research

Discovery began in Surat with two days of workshops at the client plant and sales office. We shadowed three reps — one senior, one mid-level, one inside sales coordinator — through real enquiry handling from WhatsApp ping to quotation send. We collected anonymized Excel samples: twelve regional variants, four quotation calculator spreadsheets, and an export of “lost reasons” that had never been structured. The pattern was clear — high discipline individuals compensating for absent system design.

We interviewed operations and finance separately. Operations cared about early signal, not CRM novelty; they wanted fewer surprise rush orders without access to edit dealer pricing. Finance cared about floor enforcement and PDF quotation numbers matching booking entries. IT documented existing nightly ERP CSV exports, SMTP relay constraints, and identity expectations — email domain login with optional MFA for managers.

Competitive review documented why Zoho CRM failed the fit test: dealer tier pricing needed custom modules and Deluge scripts that IT did not want to maintain; WhatsApp integration required third-party connectors with per-message costs that scaled poorly; reporting on production-adjacent tasks was generic. Vertical manufacturing CRM demos looked strong on paper but could not adapt to the client’s mixed direct-dealer-distributor model without expensive customization packages.

Technical spikes in week one validated Laravel quotation rule evaluation performance on five hundred SKU price rows, React datagrid behavior on modest regional-office laptops, WhatsApp Business API webhook signature verification, and Redis-backed job processing for PDF generation. We prototyped role-based field visibility in the API layer — not just UI hiding — so curious users could not bypass restrictions via browser devtools.

System architecture

The CRM follows a modular monolith pattern that fits team size and maintainability: Laravel 11 serves a versioned REST API consumed by a React SPA. PostgreSQL holds leads, accounts, contacts, products, price tiers, quotations, quotation lines, activities, tasks, approval records, and WhatsApp message metadata. Redis backs Laravel queues for PDF rendering, outbound WhatsApp sends, and notification fan-out, and caches hot reference data like product lists per region.

Authentication uses Laravel Sanctum with SPA cookie sessions for browser clients and token capability reserved for future mobile apps. Authorization is policy-driven: roles include Inside Sales, Field Sales, Area Manager, Operations Viewer, Sales Leadership, and System Admin. Policies enforce row-level scoping — reps see leads in assigned territories; managers see roll-ups; operations sees tasks and read-only quote summaries without dealer rate details.

The quotation engine lives in a dedicated domain service layer. Rules compile from admin-maintained tier tables: dealer category, SKU group, volume breaks, freight zone, and date-bounded promotions. Evaluation runs server-side on every line add or quantity change; the API returns computed unit price, floor, target, and margin band indicator. Overrides create approval rows before PDF finalization when below floor or above discount ceiling.

WhatsApp Business API webhooks hit a Cloudflare-protected endpoint forwarded to Laravel queue workers. Inbound messages normalize to a canonical phone format, attempt fuzzy match against dealer contacts, and attach to open leads when confidence is high; otherwise they land in an “unassigned inbox” inside sales coordination. Outbound replies use approved templates for first contact outside the twenty-four-hour session window; session replies use standard message types. Media downloads store in S3 with virus scanning via ClamAV sidecar in staging and production.

• ✓ Laravel REST API with policy-based authorization
• ✓ React SPA — territory-scoped leads and quotations
• ✓ PostgreSQL — auditable quote revisions and pricing rules
• ✓ Redis queues — PDF generation and WhatsApp processing
• ✓ WhatsApp Business API — inbound logging and templated outbound
• ✓ AWS + Docker + Cloudflare — staging/production parity

User experience for sales and operations

Sales users spend most time on three screens: lead inbox, account profile, and quotation builder. The lead inbox supports filters by stage, owner, region, overdue follow-up, and “WhatsApp unassigned.” Keyboard shortcuts jump between leads; bulk reassignment helps managers when territories change mid-quarter. Account profiles consolidate contacts, open leads, quote history, logged WhatsApp threads, and notes — replacing the mental map reps kept in personal notebooks.

The quotation builder mirrors how reps already thought — line items, quantities, freight line, optional installation add-on — but removes manual price lookup. SKU search debounces against regional product subsets so catalogs feel fast even on 4G hotspots. Floor breaches show inline with explanation required on save; managers receive in-app and email queue items they can approve from mobile browsers during plant walks.

Operations viewers get a simplified dashboard: capacity-sensitive open quotes, tasks awaiting acknowledgment, and SLA timers for high-value enquiries. They cannot edit pricing or reassign leads — reducing accidental scope creep while giving production planning the early signal they asked for in discovery.

Admin screens for tier maintenance use guarded forms with effective dates and preview mode — leadership can simulate a quote for a test dealer before activating a promotion. Training materials were embedded as short Loom links inside a Help panel; Gujarati and Hindi glossaries for field labels were provided where regional reps requested them, though the UI remained English for consistency with existing business documents.

Delivery process

Weeks 1–3: discovery, data model, auth and roles, product master import from ERP CSV. Weeks 4–7: lead pipeline, account views, quotation engine v1, PDF templates. Weeks 8–10: WhatsApp integration, approval queues, operations task notifications. Weeks 11–13: reporting, migration from Excel, UAT with three regions. Weeks 14–16: performance hardening, training rollout, hypercare.

Fortnightly demos to sales leadership with working staging credentials. Pilot region went live first — Saurashtra — while Surat HQ kept Excel fallback for two weeks only as contingency; fallback was never needed after day nine. Hypercare included daily standups for fourteen days post go-live, then weekly for a month.

Training blended Gujarati voice-over Loom videos with live office sessions because senior field reps preferred phone walkthroughs to reading PDF manuals. Product master import from ERP CSV ran twice in staging — once with deliberate bad rows so regional coordinators learned validation report triage before production data arrived. IT received runbooks for webhook replay, RDS failover, and WhatsApp template approval workflows so first-line support did not default to Web6 for operational questions.

SEO and discoverability

This engagement was CRM-first; public SEO was not the primary deliverable. We did coordinate with the client marketing team on a lightweight lead-capture landing page promoting authorized dealer enquiries — built on their existing website stack with a form that POSTs into the CRM API and creates leads with source attribution. That page targets practical manufacturing CRM keywords in meta title and description without keyword stuffing, uses a single H1 aligned to enquiry intent, and loads fast on mobile because regional dealers often discover contact details on phones.

Internal findability mattered as much as Google rankings: CRM global search indexes dealer names, GSTIN fragments, quote numbers, and phone tails with PostgreSQL full-text helpers so reps stop asking “which Excel had that dealer?” Marketing asked for the public case study page itself to carry valid Organization and BreadcrumbList JSON-LD — Web6 implemented that on web6.in’s case study template so this story is structurally clear to search engines without claiming fake AggregateRating scores.

We recommended canonical URLs for the dealer enquiry landing page and disallowing staging CRM hostnames in robots.txt so test environments never leak into index. Sitemap inclusion for the landing page only — authenticated CRM routes correctly stay noindex behind login.

Performance and reliability

API p95 response targets under three hundred milliseconds for lead list queries on typical filters, achieved via indexed territory scopes and pagination defaults of twenty-five rows. Quotation recalculation for fifty-line quotes stays under one second on production RDS instance sizes chosen for cost discipline, not over-provisioning.

Redis queues decouple PDF generation and WhatsApp sends from web request threads; workers scale horizontally during month-end quotation bursts. Cloudflare caching applies only to static SPA assets; API routes bypass cache with appropriate cache-control headers.

Regional office connectivity informed UX: optimistic UI on task completion with server reconciliation, retry toasts on failed saves, and draft quotation autosave every thirty seconds to reduce data loss on flaky 4G. Uptime monitoring pings health endpoints from three Indian metros; on-call runbooks document RDS failover and webhook replay procedures.

PDF quotation generation — often fifty-line SKUs with freight and installation add-ons — was the heaviest user-facing operation. Queue workers with horizontal scaling during month-end kept web requests responsive; reps see job status toast rather than a blocking spinner. Load test at one hundred concurrent PDF jobs completed within acceptable queue latency on chosen RDS instance size — deliberately not oversized to teach client IT realistic scaling triggers.

Security and compliance

Security was designed for industrial SMB threat models: credential stuffing, insider over-permissioning, and webhook spoofing — not nation-state theatrics. Laravel policies enforce authorization on every API route; UI hiding alone is never sufficient. Manager MFA enforced via TOTP; password rotation aligned with client IT policy.

WhatsApp webhook signatures verified before queueing; failed verifies increment metrics and alert IT. S3 objects encrypted at rest; presigned URLs expire quickly for PDF downloads. PII fields minimized in application logs; audit logs retain business identifiers finance requires.

Penetration testing was scoped to OWASP ASVS level one checks internally plus client IT vendor review of AWS security groups, RDS exposure, and Cloudflare WAF rules. Dealer rate data classified confidential — database backups encrypted, restore drills documented quarterly.

• ✓ Policy-based API authorization by role and territory
• ✓ MFA for manager and admin roles
• ✓ WhatsApp webhook signature verification
• ✓ Encrypted RDS and S3 at rest
• ✓ Audit trails for pricing and quote changes
• ✓ Cloudflare WAF and rate limiting on public endpoints

Testing and quality assurance

Automated tests cover quotation rule precedence edge cases, role visibility matrix permutations, WhatsApp webhook parsing fixtures, and PDF snapshot regression for two template variants. Feature tests simulate lead assignment and approval flows end-to-end with Pest.

UAT spanned three regions with scripted scenarios: duplicate lead merge, below-floor approval, operations notification on high-value quote, WhatsApp unassigned resolution. Finance signed off on ten generated PDFs against legacy Word templates for field alignment and numbering format.

Load testing simulated one hundred concurrent reps browsing leads and twenty parallel PDF jobs — within acceptable queue latency on chosen infrastructure. Hypercare tracked defect SLAs: critical pricing bugs same-day, cosmetic UI within sprint backlog.

Measured outcomes

Within sixty days of full rollout across all regions, median first response time to new dealer enquiries dropped from “next business day or later” — the honest baseline when Excel was the tracker — to under four business hours measured from lead creation timestamp to first logged call, WhatsApp reply, or email sent from the CRM. Inside sales coordinators drove much of this improvement because unassigned WhatsApp messages became visible in one inbox instead of personal phones.

Parallel Excel enquiry trackers were formally retired; IT archived read-only copies and disabled shared-drive write links. Sales leadership verified through spot audits that regional managers were not maintaining shadow spreadsheets — when they tried during week two of hypercare, managers said the CRM search and mobile browser access were faster than Excel anyway.

Weekly active usage among field sales hit one hundred percent within five weeks of training completion — measured as at least one login and one logged activity per user per week. Adoption succeeded because the CRM replaced work reps already did, enforced pricing guardrails they were tired of defending informally, and met them on WhatsApp instead of asking them to change dealer habits overnight.

We did not publish revenue lift percentages. Directional ops outcomes leadership cited internally included fewer sub-floor quotes reaching finance, faster handoff on capacity-sensitive orders, and improved lost-reason reporting for quarterly reviews — qualitative plus the metrics above, not fabricated ROI slides.

Lessons learned

Custom CRM beat Zoho here because pricing logic and WhatsApp logging were the product — not modules to configure. Owning the rule engine in Laravel let us match how dealers actually buy without fighting a generic price book abstraction.

Role-based pricing visibility had to be enforced in the API, not just hidden in React tables. One afternoon of curious rep poking during UAT justified the policy investment.

Operations did not want a second ERP; they wanted signal. Framing production follow-ups as notifications rather than MRP features kept scope honest and built trust between sales and shop floor.

Pilot one region, but train HQ coordinators first — they became internal champions and reduced Web6 support tickets during rollout.

“We did not need another spreadsheet with a login screen. Web6 built quotation rules we could explain to finance, logged WhatsApp where our dealers actually talk, and gave production early visibility without pretending the CRM was an ERP. Excel trackers are gone; our reps use this every week.”

Suggested project visuals

• Territory-scoped pipeline view replaces regional Excel trackers with one auditable system of record.

  File: manufacturing-crm-dealer-pipeline-dashboard.webp

  ALT: Manufacturing CRM dashboard showing dealer lead pipeline by region and stage

• Server-side pricing rules show traffic-light guardrails without exposing confidential rate tables to junior reps.

  File: manufacturing-crm-quotation-builder-pricing-guardrails.webp

  ALT: Quotation builder with role-based pricing indicators and floor breach warnings

• WhatsApp Business API messages appear on dealer timelines alongside calls, tasks, and quotation events.

  File: manufacturing-crm-whatsapp-lead-timeline.webp

  ALT: CRM activity timeline with logged WhatsApp messages attached to a dealer lead

• Production-adjacent notifications give operations early visibility without duplicating ERP production orders.

  File: manufacturing-crm-operations-notification-queue.webp

  ALT: Operations task queue showing high-value quotations flagged for planning review