When people picture a ticketing system, they usually imagine a basic support inbox — customer sends a message, agent replies, ticket closed.
What we built at Casa Retail AI is something very different.
Ticket Desk is not just a helpdesk. It is the customer issue resolution layer of a full-stack retail CRM and CDP platform, tightly integrated with products, stores, digital receipts, journeys, leads, and analytics. Every ticket is a thread connected to the customer's purchase history, their store, their product, and the SLAs a brand has committed to.
This is the story of how we built it — and what made it genuinely complex.
The Context: What is Casa Retail AI?
At Casa Retail AI, we build a multi-vendor, multi-tenant CRM and Customer Data Platform designed for the Indian retail ecosystem.
A single deployment of Casa serves multiple retail brands — each brand is a tenant. Each tenant may have dozens of stores, hundreds of agents, thousands of customers, and millions of interactions across channels.
Our platform handles marketing automation, loyalty, product catalogs, digital receipts, lead management, and customer support — all under one roof. Every module is interconnected.
Ticket Desk is the customer support module. But the word "support" undersells it.
Making It Multi-Tenant
The first and most foundational challenge was retrofitting multi-tenancy into a system that wasn't designed for it.
Every record — tickets, agents, groups, users, SLA policies, triggers — had to be scoped to a tenant. Every query, every API response, every background job needed to be tenant-aware.
Beyond isolation, each tenant needed their own:
- Agent and group hierarchy
- Role and permission configuration
- SLA policies and business hours
- Custom ticket fields
- Channel configurations
And because Ticket Desk sits inside the Casa ecosystem, every tenant's data had to stay in sync with their stores, their product catalog, and their customer base — all of which live in other modules.
This tenant boundary is not just a database concern. It shapes every layer of the system: routing, authorization, background jobs, analytics pipelines, and API design.
Multi-Source Ticket Ingestion
Once multi-tenancy was in place, the next challenge was how tickets enter the system.
Customers don't raise issues through a single channel. A retail brand receives complaints and requests from:
- Direct — agents creating tickets on behalf of walk-in customers
- Email — customer emails routed into the system as tickets
- WhatsApp — messages received via WhatsApp Business API, converted into ticket threads
- Digital Receipt — a customer raising a ticket directly from the e-bill they received after purchase
Each channel has a different payload shape, different metadata, and different expectations for how the ticket should be created.
But once a ticket is created — regardless of source — it flows through the same core pipeline. Same SLA tracking, same agent assignment logic, same trigger-based workflows.
The channel is context. The ticket is the unit of work.
The Digital Receipt Flow
The digital receipt integration deserves its own mention because of how seamlessly it closes the loop between purchase and support.
When a customer makes a purchase at a retail store, they receive a digital receipt — delivered via WhatsApp, SMS, or email. That receipt is not just a bill. It is an entry point back into the platform.
Embedded in that receipt is a way for the customer to raise a ticket. They can report a damaged product, request a replacement, or flag a service issue — all without knowing they're interacting with a helpdesk system.
When they do, the ticket is created automatically, pre-populated with:
- The store where the purchase happened
- The product they bought
- The invoice details
The agent receiving that ticket has full context before they say a word.
Product and Store Mapping
One of the biggest extensions we built on top of Zammad's core was the ability to link tickets to specific products and stores.
In a retail context, this matters enormously.
When a customer raises a complaint about a refrigerator they bought, the agent needs to know:
- Which product (brand, model, SKU)
- Which store it was purchased from
- Which store is responsible for resolution
We built a product-linking widget inside the ticket view that connects directly to Commerce Connect — our internal Product Information Management system. Agents can search and attach the relevant product to a ticket in seconds.
Store-level grouping works alongside this. Tickets can be routed to the group responsible for a specific store, ensuring the right team handles the issue.
This transforms the ticket from a generic support record into a rich operational object tied to real retail data.
Journey-Driven Ticket Creation
Not all tickets are created by humans.
Some of our most valuable tickets are created automatically by our Journey module — a trigger-based automation engine that can initiate actions based on customer data and time conditions.
The clearest example comes from consumer electronics and appliance retailers like large electronics chains.
When a customer buys an appliance, their purchase is recorded. The journey engine monitors the elapsed time:
- 6 months after purchase → a service ticket is auto-created, prompting a routine check-in
- 1 year after purchase → a follow-up service ticket is created, aligned with warranty terms
The agent receives a fully formed ticket with all the context: who the customer is, what they bought, when they bought it, and what the service expectation is.
This is not reactive support. It is proactive, scheduled, warranty-aware customer service — driven by business rules configured once and executed at scale.
Ticket-to-Lead Conversion
Sometimes a support issue reveals a sales opportunity.
Consider a customer who calls in because the display on their phone is cracked. The agent checks with the service team and finds that the spare part is not available. The product cannot be repaired.
In most systems, that ticket would be closed as unresolved.
In Ticket Desk, the agent can convert that ticket into a lead — flagging the customer as a potential buyer for a replacement or upgrade. The lead flows directly into our Lead Management module, where a sales agent can follow up with the right product recommendation.
This is a business workflow that only makes sense inside a unified CRM platform. Ticket Desk is connected to the lead pipeline because they share the same customer record, the same product catalog, and the same organizational hierarchy.
Beyond Customer Support: Internal and Operational Tickets
Not every ticket in Ticket Desk originates from a customer complaint.
One of the less obvious — but genuinely useful — uses of the system is as an internal coordination and operations layer.
Journey Opportunity Suggestions
The Journey module identifies segments of customers who qualify for a targeted campaign — a loyalty offer, a win-back promotion, a seasonal push. But acting on those insights requires a human to sign off, configure, and launch.
Instead of that decision sitting in a dashboard nobody checks, Ticket Desk creates an internal ticket assigned to the relevant marketing or CRM team.
The ticket surfaces:
- The customer segment identified
- The opportunity type (reactivation, upsell, event-based)
- The suggested journey to run
- Context on why this segment was flagged
The team reviews it, approves or modifies the journey, and closes the ticket once executed. It keeps the insight actionable and the process auditable — every opportunity suggestion has a paper trail.
Operational Tickets
Beyond journey suggestions, Ticket Desk also handles general operational work that doesn't fit neatly into a customer support flow — store onboarding tasks, internal escalations, vendor coordination items, and process exceptions that need assignment and tracking.
Using the same ticket infrastructure for internal operations meant we didn't have to build or integrate a separate project management or task tracking tool. The same SLA rules, group routing, trigger workflows, and reporting pipeline that handles customer tickets handles operational ones too.
It is a small thing architecturally, but it significantly increased how much the platform was used day-to-day across teams.
Analytics: What the Tickets Tell Us
After a ticket is resolved, the work isn't done.
All ticket data — creation, updates, resolution times, linked products, linked stores, assigned groups, and SLA outcomes — is synchronized to ClickHouse. This is the same ClickHouse cluster that powers analytics across the rest of the Casa platform.
On top of this data, we built dashboards that let brand and operations teams answer questions like:
- Which stores are generating the most complaints?
- Which products have the highest issue frequency?
- Which categories have the worst resolution times?
- How are agents performing against SLA targets?
- Are certain store clusters systematically underperforming?
This is not just a support dashboard. It is a retail operations intelligence tool.
The connection between tickets and products means that a pattern of complaints about a specific SKU shows up in the data before it becomes a brand reputation problem. Store managers can act on it. Buyers can flag it with the vendor. The loop closes.
What Made This Hard
Looking back, the technical challenges weren't in any single feature. They were in the integration surface.
Ticket Desk talks to nearly every other Casa module:
- Commerce Connect for product data
- Store Management for store and agent hierarchy
- Digital Receipts for purchase context
- Journey Engine for automated ticket creation
- Lead Management for ticket-to-lead conversion
- ClickHouse for analytics
Keeping all of these integrations consistent — as each module evolved independently — required careful API design, reliable event handling, and a shared understanding of the tenant boundary across teams.
The other challenge was the Zammad fork itself. Extending an open-source platform that wasn't designed for your requirements means you own every deviation. Every upstream change becomes a merge decision. Every extension has to live alongside the original code without breaking what already worked.
That discipline — knowing what to extend, what to replace, and what to leave alone — was as important as any technical decision we made.
What I Learned
Building Ticket Desk reinforced something I believe more firmly with every product I ship:
The value of a platform is not in its individual features. It is in how those features connect.
A digital receipt by itself is just a bill. A ticket by itself is just a support record. A product record by itself is just a data entry.
But when a customer raises a complaint from their receipt, the ticket arrives pre-loaded with their product and store context, gets assigned to the right team by a trigger, tracked against an SLA, and — if the product can't be repaired — flows into the lead pipeline for a sales follow-up…
That is not just engineering. That is a complete customer experience, built out of many small, well-connected systems.
That is what we built with Ticket Desk.
Ticket Desk is part of the Casa Retail AI platform — a multi-tenant CRM and CDP for the Indian retail ecosystem.
Top comments (0)