DEV Community: Indra Gunanda

How We Designed an MCP Interface So AI Agents Can Talk to a WhatsApp CRM

Indra Gunanda — Thu, 13 Aug 2026 07:02:42 +0000

How We Designed an MCP Interface So AI Agents Can Talk to a WhatsApp CRM

Most CRM APIs are CRUD endpoints bolted onto a database. You can create a contact, update a field, fetch a list. That works for dashboards and spreadsheet syncs. It does not work for AI agents that need to reason about conversations.

When we started seeing developer teams build custom AI workflows on top of Hallo Zetta, the REST API wasn't enough. They needed something that gave their agents structured context — not raw database rows, but meaningful conversation state.

So we built an MCP (Model Context Protocol) interface. This is the story of why, how, and what we learned.

The Problem: AI Agents Need Context, Not Just Data

Imagine you're building a custom sales agent. It needs to:

Read the last 10 messages in a conversation
Check what labels are attached to the contact
Look up relevant knowledge base entries
Decide whether to reply, escalate, or stay silent
If replying, send a message back through WhatsApp

With a traditional REST API, that's 4-5 separate HTTP calls, response parsing, error handling, and context assembly — all before your agent even starts thinking. Every integration team was writing the same glue code.

MCP changes this. Instead of your agent calling endpoints and assembling context manually, it connects to an MCP server that exposes tools and resources the agent can use naturally.

What Is MCP (Quick Primer)

Model Context Protocol is an open standard for connecting AI models to external systems. Think of it as a structured way for an LLM-based agent to:

Discover what tools are available (send message, search contacts, read knowledge base)
Call those tools with proper parameters
Receive structured results back into its context window

The key difference from REST: MCP is designed for agent consumption, not human consumption. The tool descriptions, parameter schemas, and response formats are optimized for LLMs to understand and use correctly.

Our MCP Architecture for Hallo Zetta

Here's what the integration looks like:

┌─────────────────────────────────────────────────────┐
│           Developer's Custom AI Agent            │
│  (Claude, GPT, local model, custom pipeline)    │
└────────────────────────┬────────────────────────────┘
                         │ MCP Protocol
                         ▼
┌─────────────────────────────────────────────────────┐
│            Hallo Zetta MCP Server                │
│                                                 │
│  Tools:                                         │
│  ├── send_message(contact, text)                │
│  ├── search_contacts(query, labels)             │
│  ├── get_conversation(contact_id, limit)        │
│  ├── add_label(contact_id, label)               │
│  ├── search_knowledge_base(query)               │
│  ├── handoff_to_human(contact_id, reason)       │
│  └── get_inbox_summary()                        │
│                                                 │
│  Resources:                                     │
│  ├── conversation://active                      │
│  ├── contacts://recent                          │
│  └── knowledge://topics                         │
└────────────────────────┬────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│              Hallo Zetta Core                    │
│   WhatsApp Gateway + CRM + Knowledge Base       │
└─────────────────────────────────────────────────────┘

The MCP server is a thin layer that translates between agent intent and CRM operations. It handles authentication, rate limiting, and context formatting.

Tool Design: Making Actions Agent-Friendly

The hardest part wasn't building the MCP server. It was designing tool interfaces that LLMs use correctly without excessive prompting.

Here's what we learned:

1. Descriptive tool names beat generic ones

Bad: update_entity(type, id, fields)
Good: add_label_to_contact(contact_id, label_name)

Agents make fewer mistakes when tools are specific. A generic CRUD tool forces the agent to reason about parameters. A specific tool communicates intent through its name.

2. Return context, not just confirmation

When an agent sends a message, don't just return {"status": "sent"}. Return:

{
  "status": "sent",
  "message_id": "msg_abc123",
  "conversation_summary": "4 messages exchanged today, last human reply 2h ago",
  "contact_labels": ["hot-lead", "enterprise"],
  "suggested_next": "Customer asked about pricing in previous message — consider following up on enterprise plan details"
}

The extra context helps the agent make better decisions on the next turn without additional API calls.

3. Guard rails belong in the tool layer

We don't trust any agent to self-regulate. The MCP server enforces:

Rate limits: Max 5 outbound messages per contact per hour
Quiet hours: No messages between 22:00-07:00 local time (configurable)
Group silence: Tools that send messages reject group targets unless explicitly allowed
Handoff locks: Once a human takes over, agent tools return "conversation locked" until released

These are not suggestions in a system prompt. They're hard blocks in the tool implementation. An agent literally cannot violate them.

4. Search over list

We initially exposed a list_all_contacts() tool. Agents would call it, get 500 contacts back, and then hallucinate about which one to message.

We replaced it with search_contacts(query, labels, last_active_within). Now the agent describes what it's looking for, and the tool returns a focused, relevant set. Much better results.

Real-World Use Cases We've Seen

Developer teams connecting to Hallo Zetta via MCP have built:

Custom sales qualification agents
An agent that reads incoming conversations, scores lead quality based on company-specific criteria, applies labels, and routes hot leads to the sales team — all without the team manually triaging every new conversation.

Multi-language support routing
A middleware agent that detects message language, searches the appropriate knowledge base section, and either auto-replies in the customer's language or routes to a team member who speaks it.

Proactive follow-up systems
Agents that monitor conversation state and send follow-ups when a prospect goes quiet for 48 hours — with context-aware messages that reference the previous conversation, not generic templates.

Internal dashboard bots
Team leads connecting their Slack bot to Hallo Zetta's MCP to get inbox summaries, SLA alerts, and workload distribution without switching apps.

The DX Decisions That Mattered

Building a good MCP interface is as much about developer experience as it is about protocol compliance.

Local testing without WhatsApp
Developers can connect to the MCP server in sandbox mode. Messages go to a simulated inbox instead of real WhatsApp. This means you can build and test your agent without risking real customer conversations.

Typed schemas with examples
Every tool includes parameter descriptions AND example values. This helps both human developers reading docs and AI agents understanding expected input format.

Event streaming
Besides request-response tools, we expose a resource stream for real-time events. New message arrives, label changes, handoff triggers — the agent can subscribe and react without polling.

Composable with Zetta CRM core
The MCP layer works with the full Zetta CRM stack. Contact data, labels, analytics, team assignments — everything accessible. If you're already using Zetta CRM for your team inbox, adding an AI agent layer is connecting one more MCP client.

Lessons From Production

After running MCP in production with developer teams for several months:

Agents are only as good as their guardrails. Without rate limits and handoff locks, even well-prompted agents occasionally spam customers. Build safety into the tool layer, not the prompt.

Context windows fill fast. A single WhatsApp conversation can be hundreds of messages. We added server-side summarization — the MCP server returns a compressed conversation summary for older messages and full text only for the recent window.

Tool descriptions are documentation. The text you put in MCP tool descriptions is the most-read documentation you'll ever write. Make it precise. Every ambiguous word costs you failed agent actions.

Observability is non-negotiable. We log every MCP tool call with the calling agent's identity, parameters, and result. When something goes wrong (wrong message sent, wrong contact labeled), you need an audit trail.

Getting Started

If you're building AI agents that need to interact with WhatsApp conversations:

Set up Hallo Zetta — connect your WhatsApp number and publish your knowledge base
Enable MCP access — generate credentials in the developer settings
Connect your agent — point your MCP client at the server endpoint
Test in sandbox — validate tool calls against simulated conversations
Go live — switch to production mode with guardrails active

The MCP interface is available on all Hallo Zetta plans. No separate API pricing, no per-call charges.

What's Next

We're working on:

Multi-agent coordination — multiple MCP clients sharing one inbox with conflict resolution
Agent performance analytics — measuring resolution rate, response quality, and customer satisfaction per agent
Template marketplace — pre-built agent configurations for common workflows (sales qualification, support triage, appointment booking)

All built on the same MCP foundation, all accessible from Zetta CRM's unified platform.

Build With Us

If you're a developer building AI-powered customer communication tools — or a team that wants custom agent workflows on WhatsApp — the MCP interface gives you full programmatic access without reinventing the messaging infrastructure.

Explore the docs, connect a test number, and see what your agent can do with real conversation context.

Built by Cipta Dusa — software development for teams that move fast.

How We Architect AI Chatbots That Actually Work in Production

Indra Gunanda — Thu, 06 Aug 2026 07:01:46 +0000

How We Architect AI Chatbots That Actually Work in Production

Most AI chatbot demos look incredible. Most AI chatbots in production disappoint users within 48 hours.

The gap between demo and production is where engineering actually matters. At Cipta Dusa, we've shipped conversational AI systems for clients across e-commerce, education, healthcare admin, and B2B SaaS. Not as experiments — as tools that handle real customer conversations every day.

This is a technical walkthrough of how we design, build, and deploy chatbots that survive contact with real users.

Why Most Chatbot Projects Fail

Before the architecture, let's name the failure modes we've seen (and helped clients recover from):

Hallucination without guardrails — the bot invents pricing, policies, or product details
Latency kills UX — 8-second response times on WhatsApp feel broken
No fallback path — when the AI doesn't know, the user gets stuck
Context amnesia — every message feels like talking to a stranger
One-size-fits-all prompts — the same system prompt for sales, support, and onboarding

Every architecture decision we make targets one or more of these failure modes.

The Stack: What We Actually Deploy

Here's the production architecture we use for most client chatbot projects at Cipta Dusa:

┌─────────────────────────────────────────────────────────┐
│                   Channel Adapters                        │
│   (WhatsApp, Telegram, Web Widget, Instagram DM)         │
└──────────────────────────┬──────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────┐
│                  Conversation Engine                      │
│                                                         │
│  ┌──────────┐  ┌───────────────┐  ┌──────────────────┐ │
│  │ Session  │  │  Intent       │  │  Response        │ │
│  │ Manager  │  │  Classifier   │  │  Generator       │ │
│  └──────────┘  └───────────────┘  └──────────────────┘ │
└──────────────────────────┬──────────────────────────────┘
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
       ┌───────────┐ ┌──────────┐ ┌──────────────┐
       │ RAG       │ │ Action   │ │ Human        │
       │ Pipeline  │ │ Engine   │ │ Handoff      │
       └───────────┘ └──────────┘ └──────────────┘

Let's walk through each layer.

Layer 1: Channel Adapters

A chatbot that only works on your website isn't useful for most Indonesian businesses. Their customers live on WhatsApp. Their internal team uses Telegram. Their marketing runs on Instagram.

We built a channel adapter layer that normalizes messages from any platform into a unified format:

{
  "channel": "whatsapp",
  "sender_id": "+628123456789",
  "message_type": "text",
  "content": "Harga paket enterprise berapa ya?",
  "media_url": null,
  "timestamp": "2026-08-05T10:30:00Z",
  "context": {
    "is_group": false,
    "quoted_message_id": null
  }
}

This abstraction means the conversation engine doesn't care which channel a message came from. We write business logic once. Channels are plugins.

For WhatsApp specifically, we handle the quirks that trip up most implementations:

Media messages (images, PDFs, voice notes) need to be downloaded and processed separately
Group messages need mention detection and quote-reply awareness
Phone number normalization across country codes
Rate limiting per WhatsApp's sending rules

Layer 2: Session Management

Context amnesia is the number one complaint users have about chatbots. The fix is proper session management.

Our session manager maintains:

Conversation history — last N messages with sliding window
Entity memory — extracted facts (name, order number, product interest)
State machine position — where in a flow the user currently is
Channel metadata — device type, language preference, timezone

We use Redis for active sessions (sub-millisecond reads) and PostgreSQL for long-term conversation history. Sessions expire after 24 hours of inactivity, but entity memory persists indefinitely per contact.

Session lifecycle:
  New message → Load session from Redis
                    ↓ (miss)
                Load from PostgreSQL
                    ↓ (miss)
                Create new session
                    ↓
  Process message → Update session → Write back to Redis
                                         ↓ (async)
                                    Persist to PostgreSQL

The dual-store pattern gives us speed for active conversations and durability for history.

Layer 3: RAG Pipeline — Grounding Answers in Truth

This is where we kill hallucination.

RAG (Retrieval-Augmented Generation) means the LLM doesn't answer from its training data. It answers from documents the client has approved. Product catalogs, pricing sheets, FAQ docs, policy documents.

Our RAG pipeline:

Ingest: Client uploads documents (PDF, Notion export, Google Docs, raw markdown)
Chunk: Split into semantically meaningful segments (not arbitrary 500-token blocks)
Embed: Generate vector embeddings using a multilingual model (critical for Bahasa Indonesia + English mixed content)
Index: Store in a vector database with metadata filters
Retrieve: On each query, fetch top-K relevant chunks
Generate: LLM produces answer grounded in retrieved chunks only

The key engineering decision: we use a multilingual embedding model. Indonesian businesses mix Bahasa and English constantly. A customer might ask "berapa harga enterprise plan?" and the answer lives in an English pricing document. The embedding model needs to bridge that gap.

We also enforce source attribution. Every generated answer internally tracks which document chunks it drew from. If the retrieval confidence is below threshold, the bot says "I don't have that information" instead of guessing.

Layer 4: The Fallback Chain

No AI system should be a dead end. When the bot can't help, the user needs a path forward.

Our fallback chain, in order:

RAG answer — if confident, respond directly
Clarification — if ambiguous, ask one focused follow-up question
Suggested actions — offer 2-3 buttons ("Talk to sales", "Browse FAQ", "Leave a message")
Human handoff — route to available team member with full context attached

The handoff is seamless. The human agent sees the entire conversation history, the bot's confidence scores, and the retrieved documents. They pick up exactly where the AI left off.

This is the same pattern we implemented in Hallo Zetta for WhatsApp-native support, and it works across all our client deployments.

Latency Budget: The 2-Second Rule

On WhatsApp, users expect replies in seconds. A chatbot that takes 8 seconds to respond feels broken. Our latency budget:

Step	Budget	Technique
Channel adapter	<50ms	Edge processing
Session load	<10ms	Redis
RAG retrieval	<200ms	Optimized vector search
LLM generation	<1500ms	Streaming + model selection
Response delivery	<100ms	Direct API call
Total	<2000ms

To hit that 1.5s LLM budget, we make pragmatic model choices:

Simple FAQ-style questions → smaller, faster model
Complex multi-turn reasoning → larger model with streaming
Structured actions (booking, order lookup) → no LLM needed, direct function call

This tiered approach means 70% of messages get sub-second AI responses.

Deployment: Not Just "Deploy to Cloud"

Shipping the bot is half the work. Keeping it reliable is the other half.

Our deployment stack for client chatbots:

Infrastructure: Docker containers on cloud VMs (we prefer Hetzner or DigitalOcean for Southeast Asian latency)
Monitoring: Response time percentiles, fallback rates, handoff rates, user satisfaction signals
Knowledge updates: Clients can update their knowledge base without redeploying — hot-reload via webhook
A/B testing: Different system prompts for different user segments, measured by resolution rate

We also run a weekly accuracy audit. Sample 50 conversations, check if the bot's answers were correct and helpful. This catches drift before users complain.

Real Numbers From Client Deployments

Across our Cipta Dusa chatbot projects in the last quarter:

Average first-response time: 1.4 seconds
Accuracy rate (answer matches source material): 94%
Deflection rate (resolved without human): 78%
Human handoff rate: 22% (these are the conversations that SHOULD go to humans)
Average deployment time: 5 working days from kickoff to live

The 5-day deployment is possible because of our reusable architecture. The channel adapters, session management, RAG pipeline, and handoff system are battle-tested modules. Client-specific work is mainly: ingesting their knowledge base, tuning the system prompt, and configuring their channel connections.

When NOT to Use AI

Honesty moment: not every client needs an AI chatbot.

We actively recommend against it when:

The business gets <20 messages per day (just reply manually)
Every conversation requires complex human judgment (legal, medical diagnosis)
The knowledge base changes hourly (the RAG pipeline can't keep up)
The team wants to replace humans entirely (AI-first ≠ AI-only)

For those cases, we often recommend a simpler solution: a shared inbox tool like Zetta CRM where the team collaborates on replies without AI complexity.

The Builder's Perspective

If you're building chatbots (or evaluating vendors), here's what to look for:

Ask about hallucination prevention. If they can't explain their RAG pipeline, walk away.
Test the fallback path. Ask the bot something it shouldn't know. Does it gracefully hand off or confidently lie?
Measure latency under load. Demo performance means nothing. Ask for p95 response times in production.
Check the update workflow. Can business teams update knowledge without a developer? If not, the bot will rot within weeks.
Verify channel support. WhatsApp is not the same as web chat. Media handling, group behavior, and rate limits are entirely different engineering challenges.

What's Next

We're currently working on:

Voice note understanding — transcribe and respond to voice messages natively
Proactive outreach — AI that initiates follow-ups based on conversation patterns
Multi-agent orchestration — specialized bots that route between each other (sales bot → support bot → billing bot)

All built on the same modular architecture, all deployable within a week.

Work With Us

If your business needs a chatbot that works in production — not just in demos — we'd like to talk. Cipta Dusa builds custom AI systems, web applications, and mobile apps for teams that need to move fast without breaking things.

We don't do 6-month projects. We ship working systems in days, not quarters.

Built by Cipta Dusa — software development for teams that move fast.

Designing a Shared Team Inbox for WhatsApp: Lessons From Building Zetta CRM

Indra Gunanda — Thu, 30 Jul 2026 07:02:25 +0000

Designing a Shared Team Inbox for WhatsApp: Lessons From Building Zetta CRM

When your entire sales and support operation runs on WhatsApp, the inbox becomes the most critical piece of infrastructure you own. Not your website. Not your dashboard. The inbox.

This is the story of how we designed the shared team inbox inside Zetta CRM — the architectural trade-offs, the problems that only show up at scale, and the patterns that survived contact with real teams.

The Starting Constraint: WhatsApp Is Not Email

Email inboxes have decades of tooling built around them. Folders, rules, threading, assignment. WhatsApp has none of that infrastructure. Messages arrive as a flat stream. There's no native concept of "assign this conversation to Sarah" or "label this contact as VIP."

So we had to build all of that from scratch — but shaped around how WhatsApp actually behaves:

Messages are real-time (not pull-based)
Conversations span text, images, documents, voice notes, and locations
Group chats have multiple participants with different roles
Phone numbers can change identity (device switches, number porting)
Read receipts and presence are expected by customers

Zetta CRM treats WhatsApp as a first-class protocol, not a bolt-on channel.

Architecture Overview

Here's the high-level system design:

┌─────────────────────────────────────────────────────┐
│                  WhatsApp Gateway                     │
│   (multi-device connection, message normalization)    │
└──────────────────────┬──────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────┐
│              Message Processing Pipeline             │
│                                                     │
│  ┌──────────┐  ┌───────────┐  ┌──────────────────┐ │
│  │ Contact  │  │  Label    │  │  Assignment      │ │
│  │ Resolver │  │  Engine   │  │  Router          │ │
│  └──────────┘  └───────────┘  └──────────────────┘ │
└──────────────────────┬──────────────────────────────┘
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
   ┌───────────┐ ┌──────────┐ ┌──────────────┐
   │ Team      │ │ AI Agent │ │ Webhook /    │
   │ Inbox UI  │ │ (Hallo)  │ │ Integrations │
   └───────────┘ └──────────┘ └──────────────┘

Every incoming message passes through three stages before reaching a human or AI agent: contact resolution, label evaluation, and assignment routing.

Contact Resolution: The Identity Problem

WhatsApp identifies users by phone number, but phone numbers are not stable identities. People change numbers, share devices, or use WhatsApp Business with a different number than their personal account.

Zetta CRM maintains a unified contact database that:

Deduplicates by phone number + country code normalization
Merges contact records when a known customer messages from a new number
Preserves history — conversation threads follow the contact, not the number
Enriches with metadata from previous interactions (labels, notes, custom fields)

The contact resolver runs in under 10ms per message. At 10,000+ messages per day across our platform, that latency budget matters.

Labels: Lightweight but Powerful

We debated building a full tagging taxonomy versus simple flat labels. We chose labels with one key addition: automation triggers.

A label in Zetta CRM is not just metadata. It can:

Route a conversation to a specific team member or group
Trigger a webhook to an external system
Change AI agent behavior (e.g., label "escalated" disables auto-reply)
Filter the inbox view for focused work

Label: "hot-lead"
  → auto-assign to Sales Team
  → push to Google Sheets (webhook)
  → AI: switch to sales-qualified prompt

Label: "support-tier-2"
  → route to senior agent
  → AI: disabled (human-only)
  → SLA timer: 30 minutes

Labels are applied manually by team members, automatically by the AI agent based on conversation content, or via API by external systems. This flexibility means teams can start simple and add automation incrementally.

Role-Based Access: Who Sees What

A 3-person team and a 30-person team have very different access needs. We designed a role system that scales without becoming bureaucratic:

Owner — full access, billing, can delete workspace
Admin — manage team members, configure AI, view all conversations
Agent — sees assigned conversations + unassigned queue
Viewer — read-only access to conversations and analytics (for managers)

The key insight: agents should see their own conversations plus the unassigned pool. They should NOT see other agents' active conversations by default. This prevents stepping on each other's toes and gives customers a consistent experience.

Admins get a bird's-eye view across all conversations for quality monitoring and load balancing.

Real-Time Sync: The WebSocket Challenge

WhatsApp users expect instant delivery. If a customer sends a message and the agent sees it 30 seconds later, the experience feels broken.

Our real-time layer uses WebSocket connections to push messages to the inbox UI with sub-second latency:

WhatsApp → Gateway → Redis Pub/Sub → WebSocket Server → Browser
                                         │
                                         ├── typing indicators
                                         ├── presence (online/offline)
                                         ├── read receipts (synced back)
                                         └── assignment notifications

We chose Redis Pub/Sub over a dedicated message broker (Kafka, RabbitMQ) for this layer because:

Message durability isn't critical here (we persist to DB separately)
Latency is the priority — Redis delivers in microseconds
Operational simplicity — one less system to maintain
Our scale (thousands of concurrent connections, not millions) fits Redis comfortably

If we hit connection limits, the upgrade path to a dedicated broker is clean because the pub/sub interface is abstracted.

Multi-Number Support

Many businesses operate multiple WhatsApp numbers: one for sales, one for support, one for a specific product line. Zetta CRM supports connecting multiple numbers to a single workspace.

This sounds simple but introduces routing complexity:

Which number should outbound messages come from?
If a customer messages Number A, can an agent on Number B see it?
How do we prevent cross-contamination between brands sharing a workspace?

Our solution: number-level permissions. Each number has its own team assignment, and conversations are scoped to the number they arrived on. Cross-number visibility is opt-in at the admin level.

Analytics: Measuring What Matters

A shared inbox without analytics is a black box. Teams need to know:

Response time: How long until first reply? (We track median, p95, and p99)
Resolution rate: What percentage of conversations reach a conclusion?
Agent load: Who's handling more? Who needs help?
AI deflection: How many conversations did the AI resolve without human help?
Peak hours: When is the team overloaded?

We built these as first-class metrics inside Zetta CRM, not as an afterthought reporting tab. The analytics feed directly into routing decisions — if Agent A's queue is full and Agent B is idle, new conversations route to B.

What We Got Wrong (And Fixed)

Mistake 1: Over-engineering assignment rules early.
We built a complex rule engine before we had users. Turns out, 80% of teams just want round-robin or manual pick-from-queue. We simplified the default and moved complex rules to an "advanced" tier.

Mistake 2: Treating groups like DMs.
Our first version applied the same inbox logic to group messages. It created chaos — hundreds of messages flooding the inbox from a single active group. We had to build group-specific behavior: aggregate by group, show only actionable messages, and let teams mute groups from the inbox without leaving them on WhatsApp.

Mistake 3: Not exposing the API early enough.
Developer teams wanted to integrate Zetta into their own systems from day one. We were too focused on the UI and delayed the API. Lesson learned: the API is the product for technical teams. We now ship API-first and the UI consumes the same endpoints.

The Developer Layer

For teams that want programmatic access, Zetta CRM exposes:

REST API — full CRUD on contacts, conversations, labels, messages
Webhooks — real-time events (new message, label applied, assignment changed)
MCP (Model Context Protocol) — for AI agents and LLM-powered workflows to interact with the CRM programmatically

The MCP integration is particularly interesting for developer teams building custom AI agents. Instead of hardcoding WhatsApp logic, your agent connects to Zetta's MCP endpoint and gets structured access to conversations, contacts, and actions.

Lessons for Builders

If you're building anything on top of WhatsApp for teams:

Start with the message model, not the UI. How you normalize, store, and route messages determines everything downstream.
Groups are a different product. Don't treat them as "DMs with more people."
Real-time is table stakes. Anything over 2 seconds feels broken to WhatsApp users.
Labels beat folders. Flat, flexible, automatable.
Ship the API on day one. Your power users will thank you.

Try Zetta CRM

If your team handles customer conversations on WhatsApp and you're still managing them on personal phones or a clunky tool that treats WhatsApp as a second-class channel, check out Zetta CRM.

Connect a number, invite your team, and see what a WhatsApp-native inbox feels like.

Built by Cipta Dusa — software development for teams that move fast.

Why We Built a CRM Around WhatsApp Instead of Email

Indra Gunanda — Mon, 27 Jul 2026 08:55:37 +0000

Why We Built a CRM Around WhatsApp Instead of Email

In Southeast Asia, email open rates hover around 15%. WhatsApp message read rates? North of 90%.

That single stat explains why we built Zetta CRM and Hallo Zetta as WhatsApp-native tools instead of bolting messaging onto yet another email-first CRM.

This article walks through the architectural and product decisions behind building AI-powered customer communication on WhatsApp — and what we learned shipping it to real teams.

The Problem With "WhatsApp Integration"

Every CRM claims WhatsApp support. Here's what that usually means:

A third-party plugin that syncs messages with a 5-minute delay
A sidebar panel showing chat history you can't reply from
Template-only outbound that feels robotic to customers

None of these solve the actual workflow: a team of 3-10 people sharing one WhatsApp number, handling hundreds of conversations daily, across DMs and groups, with photos, voice notes, and documents flying around.

That's what Zetta CRM was designed to handle from day one.

Architecture: WhatsApp as Primary, Not Peripheral

Our stack treats WhatsApp as the primary communication channel:

WhatsApp (multi-device) → Zetta Gateway → Message Router
                                              ↓
                              ┌────────────────┼────────────────┐
                              ↓                ↓                ↓
                        AI Agent         Team Inbox        Integrations
                     (Hallo Zetta)     (shared view)    (Calendar, Sheets,
                                                         Notion, Webhooks)

Key design decisions:

Native multi-device support: Connect via QR scan, no WhatsApp Business API dependency
Full message types: Text, images, documents, voice notes, contacts, locations
Group awareness: The system understands group dynamics — who said what, reply threading, @mentions
Real-time sync: Sub-second message delivery to the shared inbox

AI Layer: Hallo Zetta

Hallo Zetta is the AI agent layer on top of the CRM. It's not a chatbot — it's an AI teammate:

What makes it different from chatbots:

Chatbot	Hallo Zetta
Script-based, breaks on unexpected input	LLM-powered, handles natural conversation
Replies to everything in groups	Silent until @mentioned or quoted
Generic answers	Grounded in YOUR knowledge base
No handoff	Seamless human takeover per-conversation
Text only	Photos, files, voice notes

The knowledge base workflow:

Upload your docs (product info, pricing, FAQ, policies)
Test in the playground — see how AI answers before going live
Publish to the agent
Monitor and improve based on real conversations

Every answer traces back to source material. No hallucination. No made-up pricing. No "I think the delivery time is..." guesses.

Group Intelligence

This is where most WhatsApp automation tools fail catastrophically.

Groups are noisy. A reseller group might have 200 messages/day, of which maybe 5 are actual questions for the brand. A naive bot replying to everything gets muted or kicked within hours.

Hallo Zetta's group behavior:

Default: silent — never interrupts human conversation
Activates on: @mention or direct quote of the bot's message
Replies in-thread: Responds to the specific message, not the whole group
Context-aware: Reads the conversation thread before answering

This is a product decision, not a technical limitation. Trust in groups is earned by knowing when NOT to speak.

Integrations That Move Work Forward

A conversation often triggers work elsewhere. Instead of copy-pasting between apps:

Google Calendar: Schedule meetings directly from chat
Google Sheets: Push qualified leads to a sheet the sales team already watches
Notion: Sync knowledge base from Notion pages
Zapier & Webhooks: Connect to 6,000+ apps or your own backend

The webhook layer means any system with an API can react to conversation events: new lead captured, label applied, handoff triggered.

Results in Production

Teams using Hallo Zetta report:

85% of routine questions handled by AI without human intervention
Response time dropped from 4+ hours to under 30 seconds
Zero noise complaints in group deployments (the silent-by-default pattern works)
Team efficiency up 3x — same team handles 3x the conversation volume

The Zetta CRM Ecosystem

Hallo Zetta is part of the broader Zetta CRM platform:

Contacts & Labels: Unified contact database with custom labels and segments
Team Inbox: Shared workspace with role-based access
Analytics: Conversation metrics, response times, resolution rates
Multi-number: Connect multiple WhatsApp numbers to one workspace
API & MCP: Programmatic access for developers building on top

Built by Cipta Dusa in partnership with Incredible Zetta.

Try It

If your team handles customer communication on WhatsApp and you're tired of:

Personal phones as the primary tool
Same questions answered 50 times a day
No visibility into what your team is saying
Conversations lost when someone leaves

Check out Hallo Zetta. Connect a number in 2 minutes, upload your docs, and see the AI handle the first conversation.

Part of the Zetta CRM family. Built by Cipta Dusa — software development for teams that move fast.

How We Ship Websites in 48 Hours Without Cutting Corners

Indra Gunanda — Mon, 27 Jul 2026 08:54:52 +0000

How We Ship Websites in 48 Hours Without Cutting Corners

Everyone says "fast delivery" until you ask them what fast actually means. For us at Cipta Dusa, it means a company profile website — designed, built, and live — in two working days.

Not a template slap. Not a drag-and-drop page builder with your logo swapped in. A real, hand-coded site with proper SEO structure, responsive design, and performance that scores 90+ on Lighthouse.

Here's how we do it without burning out or shipping garbage.

The System Behind the Speed

Speed without a system is just chaos. We built ours over dozens of projects:

Day 1: Discovery + Design

30-minute intake call: business type, target audience, must-have pages, brand assets
Component selection from our battle-tested design system (not templates — reusable, customizable blocks)
Client gets a preview link by end of day

Day 2: Build + Deploy

Full responsive implementation
SEO meta tags, Open Graph, structured data (Organization schema, breadcrumbs)
Performance optimization: lazy loading, WebP images, minimal JS
Deploy to edge CDN, SSL, custom domain
Client walkthrough + handoff

Why This Works for Indonesian SMEs

Most small businesses in Indonesia don't need a 3-month web project. They need:

A professional online presence that loads fast on mobile
Something they can show investors, partners, or customers
Google-indexable pages with proper local SEO

That's exactly what we deliver. No scope creep, no endless revision loops, no "we'll get back to you next week."

Beyond Websites: Full-Stack Development

Websites are our entry point, but Cipta Dusa builds the full stack:

Custom web applications — dashboards, internal tools, SaaS products
Android apps — native and cross-platform
AI chatbots — WhatsApp, Telegram, and website integrations powered by LLMs
DevOps setup — CI/CD pipelines, cloud deployment, monitoring

Every project follows the same principle: ship fast, ship quality, keep the client in control.

Our Tech Stack

We're opinionated about tools because opinions save time:

Frontend: Next.js, Astro, Tailwind CSS
Backend: Go, Node.js, Python
Infrastructure: Cloudflare Workers, Vercel, Docker, GitHub Actions
AI: OpenAI, Anthropic, local models via llama.cpp
CRM & Automation: Zetta CRM (our own)

Results

In the last 6 months:

40+ websites delivered
Average delivery time: 2.1 days
Client satisfaction: 4.8/5
Zero missed deadlines

If you need a website that's live before the weekend, or a custom app that doesn't take 6 months, check out our portfolio at ciptadusa.com.

Built by the team at PT Cipta Dua Saudara — software development partner for startups and SMEs in Indonesia.

Building an AI Support Inbox for How WhatsApp Teams Actually Work

Indra Gunanda — Mon, 27 Jul 2026 07:23:34 +0000

Building an AI Support Inbox for How WhatsApp Teams Actually Work

Most customer-support software starts from an email-shaped assumption: messages arrive one at a time, belong to one person, and wait patiently in a queue.

WhatsApp does not work like that.

A customer may send a photo, then a voice note, then three short follow-ups. A team may need to jump between direct messages and busy groups. Someone has to take over a conversation without asking the customer to repeat everything. And when automation answers at the wrong moment, it does not feel helpful — it feels intrusive.

That was the problem behind Hallo Zetta: build a shared WhatsApp customer-care inbox where AI can handle routine work without pretending humans are no longer needed.

Start with WhatsApp behavior, not chatbot behavior

It is easy to describe the first version of an AI support product:

receive a message,
send it to a model,
return an answer.

That loop is not enough for a real support team. It ignores context, ownership, files, group dynamics, and the moment a conversation should move to a human.

So we treated WhatsApp as the primary working environment, not as one more integration tab inside a generic CRM. The product needs one shared inbox for the team, persistent contact context, and a conversation model that can carry AI and human work in the same thread.

The design target was not “make the bot reply more.” It was “help the team move the conversation forward.”

Groups change everything

Groups are where a naïve support agent becomes noise.

A useful AI agent cannot reply to every message in a reseller group, customer group, or internal coordination thread. It needs to recognize that a group has its own social rules. Most messages are not requests for the agent. Many are conversations between people who do not need an interruption.

Hallo Zetta is built to support group-aware workflows. The agent should participate only when invited into the interaction, while the rest of the group stays human. That decision is product behavior, not a cosmetic setting: it protects trust in a channel where one bad automation pattern can make a team stop using the tool.

This also changes how we think about context. A reply is not only an answer. It needs to be tied to the right message, the right group, and the right moment.

Ground AI answers in team knowledge

Another failure mode is confident automation with no source of truth.

A support agent should not invent pricing, policy, delivery, or product answers. The useful version of AI is constrained by material the team has reviewed.

Hallo Zetta uses a knowledge-base workflow and a playground so teams can test answers before the agent is live. That creates a practical loop:

publish team knowledge,
test likely customer questions,
inspect weak or incomplete answers,
improve source material,
deploy with more confidence.

The goal is not to remove judgment from support. The goal is to make good judgment reusable.

Handoff is a core feature

“Human handoff” often sounds like an edge case. In a real inbox, it is central.

Some questions need empathy. Some need approval. Some need access to systems or decisions that should never be automated. A good system makes those transitions boring: a teammate takes over in the same conversation, sees the context, and continues without forcing the customer through a second introduction.

That is why the AI-first model matters. AI handles routine first replies and repetitive questions. Humans retain control of exceptions, escalation, and relationship-building.

AI-first is not AI-only.

An inbox must handle more than text

Support work includes photos, documents, voice notes, and links. A shared inbox that only handles clean text messages forces teams back to personal phones for everything else.

Hallo Zetta is designed around the full shape of WhatsApp conversations: media, files, voice, contact context, and team ownership. Each capability seems small in isolation. Together, they decide whether a tool can replace a patchwork of personal devices and workarounds.

Integrations should move work, not create more tabs

Support conversations often trigger work outside the inbox: schedule a follow-up, record a lead, update a workspace, or send an event to another system.

That is why Hallo Zetta connects with tools teams already use, including Google Calendar, Google Sheets, Notion, Zapier, and webhooks. The point is not a long integration checklist. The point is to keep a customer conversation from becoming copy-paste work across five products.

What we are building toward

The hardest part of customer support is not generating a sentence. It is knowing what to say, when to say it, when not to say anything, and when to involve a person.

That is the product direction behind Hallo Zetta: one WhatsApp-native workspace where a team and an AI agent can work together without losing context or control.

If your support team lives in WhatsApp, try it at hallo.zettacrm.com.

We Built Hallo Zetta Because We Were Tired of Watching Teams Answer WhatsApp on Personal Phones at Midnight

Indra Gunanda — Mon, 06 Jul 2026 12:45:34 +0000

The story behind why we built a WhatsApp CRM that actually understands how WhatsApp works.

There's one scene I can't get out of my head.

A friend's desk. She runs an online store. On it sat three phones. Not for show. One for customer service, one for the admin, one for the number that was "just for resellers." All three buzzing, nonstop. And there she was, eleven at night, still replying to messages one by one, sighing: "It's the same questions over and over. But if I don't reply, they'll go to the competitor."

That's not a rare case. That's the normal state of things for thousands of businesses.

We all know one thing CRM software rarely admits: customers here don't live in email. They live on WhatsApp. They ask about prices on WhatsApp, complain on WhatsApp, close deals on WhatsApp, even ask for warranty support on WhatsApp. But the teams handling all of it? They use personal phones. No records, no context, no way to help each other when one person is drowning.

Hallo Zetta was born out of that.

What Frustrated Us About the Existing Tools

Before building our own, of course we looked. Surely someone had solved a problem this simple?

Turns out what existed fell into two camps, and both were maddening.

Camp one: dumb auto-reply bots. Type "hi," get a template. But the moment a customer asks something slightly off-script, the bot freezes. It actually makes customers angrier, because it feels like talking to a wall.

Camp two: bloated CRMs. Loaded with features, dashboards full of charts, but WhatsApp is bolted on as one small tab. As if WhatsApp were an afterthought, not the main battlefield. For most of our customers, WhatsApp is the battlefield.

Nothing fit. So we decided to build it ourselves.

The Hard Part Isn't "AI Can Reply to Messages"

Let me be honest about this. Bolting AI onto WhatsApp is easy. Anyone can wire GPT to a webhook and ship it overnight. If that were the whole goal, this article wouldn't need to exist.

The hard part, the thing that made us rethink everything again and again, is groups.

Think about it. How much real business actually happens in WhatsApp groups? Reseller groups, VIP customer groups, team coordination groups. A huge amount. But an AI that chimes in on every group message isn't helpful, it's spam. Picture a group in the middle of a lively conversation, and suddenly there's a bot butting in over and over. You'd get kicked out in seconds.

So we made a rule the bot genuinely respects:

Inside a group, the bot stays silent. Completely silent. Until it's mentioned (@) or someone quotes its message. Only then does it answer, right in the correct thread, quoting the message it's responding to.

No unnecessary noise. It behaves like a teammate who knows their place, not a chatbot that can't stop talking. Sounds trivial, but this is what makes the bot genuinely usable in groups, not just in private chats.

AI First, But Not AI Only

The second principle we refused to compromise on: control stays with the team.

The AI in Hallo Zetta does answer first. Routine questions, opening hours, shipping rates, payment methods, answered instantly, 24/7. But it only answers from the knowledge base you publish yourself. It doesn't make things up. If you didn't write about it, it won't invent an answer.

And your team is always one tap away. A conversation that needs a human touch? Just switch the AI off on that chat, take over in the same thread, context and media all intact. No app-switching, no asking "what did we talk about again."

That's our philosophy: AI-first, not AI-only. Let AI handle the routine. Give the human-needed conversations a human. You decide where the line is.

The Boring Work We Did Behind the Scenes

To make the inbox "just work," there was a lot of tedious work we had to sort out first.

Real WhatsApp is messy. There are DMs, groups, mentions, quoted replies, photos, files, even voice notes. There's the headache of phone-number vs LID identity. There's media that has to be stored securely. We handled them one by one, because these are exactly the details that usually make other tools "look like they work" until you actually use them for real.

There's also a playground. Before your agent talks to real customers, you can test its answers there first. Match them against the knowledge base, fix the odd ones, then publish. No embarrassing surprises in front of a customer.

It's Live Today

Hallo Zetta is live today. It's part of the Zetta CRM family, built together by Incredible Zetta and Ciptadusa.

Getting started is simple:

Connect your WhatsApp number (scan a QR or use a code).
Teach the AI by publishing your docs to the knowledge base.
Run the inbox and let AI handle the routine while your team steps in when needed.

You can try it right now, connect a number, publish your docs, and see for yourself how it handles a real conversation.

👉 hallo.zettacrm.com

Closing

We didn't build this to jump on the AI trend. We built it because we were tired of watching people we know scramble through WhatsApp with manual workarounds that wear them out.

If your team is still juggling three phones on a desk, or still answering the same questions until midnight, this might be for you.

Try it, and tell us what's missing. We're listening.

Written by the Hallo Zetta team. If this story landed, give it a clap 👏 and share it with a friend still fighting their WhatsApp inbox