Customer Intelligence Agent

Customer Intelligence Agent is an N8N-based multi-agent automation workflow built for Product Managers. It takes a simple natural-language input — a customer name like "ACME" or "ACME Corp" — and orchestrates multiple AI agents and sub-workflows to pull live CRM (Customer Relationship Management) tickets and FRS (Feature Request System) data from Jira, synthesize them through Google Gemini (Gemma 4 31B), and deliver a complete customer intelligence report. The output is available in two formats: a rich interactive HTML dashboard returned via webhook, or a downloadable PowerPoint presentation generated by an external microservice. The system eliminates hours of manual Jira trawling and spreadsheet consolidation, giving PMs an instant, AI-analyzed account health briefing with actionable recommendations.

Product Managers manage large enterprise accounts — banks, tech companies, and similar — each generating dozens of CRM tickets (bugs, escalations) and Feature Requests across multiple product areas. Before every customer QBR (Quarterly Business Review) or internal account review, a PM had to:

This process took 2–4 hours per customer and was error-prone, inconsistent across PMs, and often outdated by the time the meeting happened.

• —Manually search Jira across two separate projects (CRM and FRS), filtering by customer name.
• —Tally ticket counts — open, closed, in-progress, by priority, by product area.
• —Analyze aging tickets — identify which P1/P2 tickets have been open too long and who owns them.
• —Assess feature request delivery — which features are planned vs. unplanned, what versions they target.
• —Synthesize a health score — a subjective judgment call combining all the above.
• —Write an account narrative and action items from scratch.
• —Format everything into a presentation or report.

The vision is to build a zero-effort, on-demand customer intelligence system:

"Type a customer name — even abbreviated — and receive within seconds a complete, AI-analyzed account health report with scores, risks, and actionable recommendations, without opening Jira or building a single query."

The system delivers:

• —A health score (0–100, color-coded GREEN/YELLOW/RED).
• —Full CRM and FRS ticket summary with KPIs.
• —Open ticket analysis with root-cause and recommended actions per ticket.
• —Feature request assessment with planned/unplanned status.
• —Risk flags tied to specific ticket IDs.
• —Actionable PM to-do items.
• —Output as either an interactive HTML report or a downloadable PPTX.
• —Accessible via both a chat interface (N8N chat trigger) and a webhook API (for integration with custom portals).

• —N8N as orchestration layer: Chosen for its visual workflow builder, native AI agent support, sub-workflow composition, and dual trigger capability (chat UI + webhook API). N8N's `$fromAI()` function enables the AI agent to dynamically decide which tools to call and with what parameters.
• —Multi-agent tool pattern: Rather than a monolithic prompt, the system uses N8N's tool-calling architecture where the central AI Agent has access to two sub-workflow tools — `getCRMDetails` and `getFeatureDetails` — each a standalone workflow querying Jira's REST API. This separation of concerns means each data source can be maintained, tested, and extended independently.
• —Google Gemini (Gemma 4 31B): Selected as the LLM for its strong structured-output compliance (strict JSON schema adherence) and ability to normalize abbreviations, calculate derived metrics, and generate actionable recommendations.
• —Dual output path: A Switch node inspects whether the user requested PPT or HTML format. The PPT path calls an external Python microservice that takes the structured JSON and produces a `.pptx` file. The HTML path renders a full styled dashboard server-side using JavaScript template literals.
• —Robust parsing: Multiple Code nodes handle edge cases where the AI returns markdown-wrapped JSON, plain text instead of JSON, or partially structured output — using regex fallbacks to extract health scores, narratives, and risk flags from free text.

The workflow consists of 17 nodes organized into four stages:

This workflow validates the core hypothesis: multi-agent tool-calling with structured output schemas can reliably replace hours of manual data gathering and synthesis, while defensive parsing keeps the system resilient against LLM output variability.

• —Stage 1 — Ingestion: Dual entry points (webhook API and chat UI) feed into an Edit Fields node and a JavaScript extractor that normalizes the customer name and output mode.
• —Stage 2 — AI Intelligence: The Gemini-powered AI Agent orchestrates two sub-workflow tools (`getCRMDetails` and `getFeatureDetails`), each querying Jira independently. The agent's system prompt defines a strict JSON output schema covering health score, ticket summary, open ticket analysis, feature request analysis, risk flags, and PM action items.
• —Stage 3 — Output Routing: A Switch node routes to either PPT generation or HTML rendering.
• —Stage 4a — PPT Path: A chain of Code nodes parses the AI output, prepares the payload, calls the Python PPTX microservice, and returns the binary file to the webhook caller.
• —Stage 4b — HTML Path: A server-side JavaScript renderer generates a complete styled HTML page with KPI cards, health banner, ticket tables with priority badges, feature request panels, risk flags, and PM action items.

For a PM team managing 50+ enterprise accounts, this translates to roughly 100–200 hours saved per quarter on report preparation alone, with higher quality and consistency.

• —Time savings: Reduces account review preparation from 2–4 hours of manual work to ~30 seconds of automated processing.
• —Data freshness: Reports use real-time Jira queries instead of stale data prepared days before the meeting.
• —Consistency: Standardized JSON schema and uniform health scoring replace subjective PM judgment calls.
• —Dual output formats: Auto-generated HTML dashboards and downloadable PPTX presentations replace manual slide-building.
• —Intelligent normalization: AI automatically resolves abbreviations (SCB, Infy) and alternate customer names.
• —Risk identification: AI flags aging P1s, unplanned feature requests, and stalled tickets with specific ticket IDs — risks that were often missed in manual reviews.
• —Actionable recommendations: Structured action items tied to specific tickets with "why" and "how" replace ad-hoc notes.
• —Integration surface: Webhook API makes the system usable by any internal portal or dashboard.

• —Strict JSON schema prompting is essential but not sufficient. Despite detailed schema instructions and "STRICTLY FORBIDDEN" rules in the system prompt, the LLM occasionally returns markdown-wrapped JSON or free-text responses. The workflow includes multiple fallback parsers (regex-based text extraction) as a safety net — any production AI pipeline must be defensive about output format.
• —Multi-agent tool-calling beats monolithic prompts. Splitting CRM queries and FRS queries into separate sub-workflows gave the AI agent the ability to call them independently and in parallel. It also made each data source independently testable and deployable.
• —Dual entry points multiply value. Supporting both a chat trigger (for ad-hoc PM use) and a webhook (for portal/API integration) from the same workflow doubled the system's utility with minimal additional complexity.
• —Binary file generation needs a sidecar service. N8N's JavaScript Code nodes are powerful but not suited for generating complex binary formats like PPTX. Offloading this to a dedicated Python microservice (using python-pptx) was the right architectural boundary.
• —Health scoring requires guardrails. Letting the AI freely assign a 0–100 score is convenient but can be inconsistent across runs. A future improvement would be to calculate the health score deterministically from ticket metrics and use the AI only for narrative and recommendations.
• —Customer name normalization is a hidden complexity. Abbreviations, informal names, and alternate spellings are common in PM conversations. Embedding normalization in the AI prompt works for known names but fails for new or unusual abbreviations. A lookup table or fuzzy-match pre-processor would improve reliability.
• —HTML rendering in Code nodes scales poorly. The ~200-line inline HTML template inside a JavaScript Code node works but is hard to maintain. Extracting this into an external template engine would improve maintainability.