DEV Community: Indra Gunanda

Being "On the Internet" Isn't Enough — Why AI Still Gets Your Business Wrong

Indra Gunanda — Sun, 06 Sep 2026 08:00:34 +0000

We've all been told to "get a website" or "build an online presence." But here's the uncomfortable truth many businesses are only now discovering: having content on the internet does not mean AI models will describe your business correctly. In fact, the more scattered and inconsistent your information is, the more likely an AI assistant gets you wrong — wrong category, wrong hours, wrong location, or even wrong industry.

What AI Assistants Actually Do

When a user asks ChatGPT, Perplexity, or Gemini "which local accounting firm handles small businesses?" or "where can I find a ceramics studio in this city?", the model doesn't just scroll through your website. It pulls fragmented signals from across the web — directories, review sites, social profiles, news mentions, partner pages — and reconstructs a synthesis of who you are.

That synthesis is your AI identity. And it can disagree with what you think your business is.

Three things break down frequently:

Outdated citations. Your old address is on a third-party directory, so AI reports the wrong location.
Contradictory data. One platform says you're a "studio," another says "gallery." AI blends them awkwardly.
Missing verification. If no credible third party confirms a claim about your business, AI simply omits it or hedges.

The result is a brand that is technically "findable" but described inaccurately.

The Honest Part: You Can't Buy a Ranking

Today there's a lot of noise in the "generative engine optimization" (GEO) space promising guaranteed positions/first recommendations inside ChatGPT. Be skeptical of that. No one can promise ranking or recommendation inside a model you don't control — and anyone who claims they can is overselling.

What you can influence is the input: the set of accurate, consistent, verifiable facts about your business that AI has to work with. That is real, and it compounds.

This is exactly the line we hold at The Resets Company. We help brands — especially those without their own website, or those underrepresented online — become accurately found by AI by improving their distributed presence and verifying what AI actually detects. We run an AI Detection Audit, build consistent information across credible third-party platforms, and monitor how detection and accuracy change over time. Our mission is to give under-represented businesses a fair chance at being understood by an AI-driven internet. We're transparent about the gap between what's published and what AI genuinely verifies — no inflated promises.

Practical Steps You Can Start Today

You don't need our help to begin. Start with these:

Audit the "AI view" of your brand. Ask an assistant where you're located, what you do, your hours. Note the errors.
Pick the 3–5 most relevant credible platforms for your industry and get your listing consistent — exact name, exact address, exact category, consistent description.
Add verifiable anchors. A real postal address, a phone number tied to a published page, a confirmed operating license. Citations AI can actually check.
Patch contradictions first. One consistent truth beats ten scattered half-truths.

The goal isn't to be everywhere. It's to be consistently and credibly somewhere AI trusts.

The Resets Company helps brands be accurately found by AI — even without their own website. Read more at theresetscompany.com.

Your Digital Footprint Is Your New Brand Image: What ChatGPT, Perplexity & Gemini Actually Read

Indra Gunanda — Sat, 05 Sep 2026 08:01:11 +0000

Your Digital Footprint Is Your New Brand Image: What ChatGPT, Perplexity & Gemini Actually Read

Ten years ago, your "brand image" meant your website design, your logo, and maybe your Instagram feed. Today, a growing share of the people who hear about your business will never open your site — they'll ask an AI assistant first.

"Who makes the best artisanal soap in Yogyakarta?" "Which local accounting firm has non-outsourced support?" "Is this brand we're considering legitimate?"

When someone asks a question like that, ChatGPT, Perplexity, Gemini, and similar tools don't browse your homepage like a human would. They synthesize an answer from citations — a scattered set of mentions scattered across the web. And here's the uncomfortable truth: that synthesized answer is becoming your brand image, whether you curate it or not.

AI doesn't "know" your brand — it reconstructs it

Generative AI models, including retrieval-augmented assistants, are not omniscient. When they answer a question about your business, they aren't recalling a neat database entry. They're pulling fragments from sources they can retrieve and verify: business directories, review platforms, news articles, social profiles, published lists, and your own site if one exists.

This has a practical consequence: your digital footprint — the sum of consistent, verifiable mentions of your business across third-party platforms — is the raw material the AI reads to draw its picture of you. Inconsistency, absence, or contradiction across those sources is what it "sees" as your brand.

Why consistency beats volume

You might think the goal is to have more mentions. But AI assistants weigh accuracy and verifiability just as much as frequency. Three sources that agree on your name, location, services, and how to contact you will beat fifty scattered, contradictory posts.

This is the core of what practitioners call generative engine optimization (GEO) or AI discoverability. It's less about gaming an algorithm and more about making sure the public record says the same, truthful thing everywhere it can be found. The same name spelled identically. The same service descriptions. The same contact details. No silence where an AI might otherwise invent a plausible-sounding answer.

The honest part: AI detection and verification

Let's be clear about what's achievable and what isn't.

We cannot guarantee that an AI will recommend your business. Ranking and recommendation depend on the model, the query, the user, and retrieval internals that change constantly. Anyone who promises you a top spot in ChatGPT's reply is overpromising — and you should be wary of them.

What is achievable and measurable is whether AI detects you at all, and whether what it detects is accurate. If an assistant describes your business with the wrong address or the wrong specialty, that's a factual problem you can find and fix. If you're invisible to AI because you have no consistent web presence, that's a gap you can close. Testing for and correcting these — rather than chasing rankings — is where real progress happens.

That distinction shapes how we think about this at The Resets Company. Our mission is to give brands without their own website — and underrepresented businesses in general — a fair chance to be found accurately in an AI-driven web. But our stance stays honest: we separate what's published in the world from what an AI actually detects and verifies, and we don't sell rankings or guaranteed recommendations. We help you build a truthful, consistent footprint, and then we measure the change in detection and accuracy over time. If things aren't moving, we want to know that too.

Practical starting points (no website required)

Audit what the AI currently says about you. Search your own business name and category in a couple of AI assistants. Note whether you're mentioned, and whether the details are correct. Screenshot the answers — you'll need a baseline.
Claim and fill the high-trust third-party surfaces. Business directories, review platforms, and professional registries that AI assistants commonly cite. Fill them completely and identically: name, address, category, hours, and a description that matches across every profile.
Choose one consistent "about" text and reuse it. If different profiles contradict each other on what you do or where you are, the AI has no reliable version to pick. Consistency is your strongest lever.
If you have any owned channel (a blog, a LinkedIn company page, a simple landing page hosted anywhere), keep it truthful and current. Even a one-page presence on a free host beats a void where the AI must guess.
Re-check regularly. Detection isn't a one-time fix. Revisit your baseline monthly and note whether the picture the AI paints improves, worsens, or stays wrong. That measurement is what tells you whether your footprint work is actually working.

The bottom line

You can't always control what an AI recommends — but you can control whether it finds you, and whether the version it finds is the truth. In an era where machines increasingly introduce us to each other, your digital footprint isn't a nice-to-have SEO extra. It's your brand image. Keep it consistent, keep it honest, and keep measuring what the machines actually see.

Can a Business With No Website Be Found by AI? Yes — Here's the Honest How

Indra Gunanda — Sat, 05 Sep 2026 00:11:26 +0000

Can a Business With No Website Be Found by AI? Yes — Here's the Honest How

The common story is that if you don't have a website, you don't exist on the internet. That was true for search engines. It is not automatically true for AI assistants — and that cuts both ways.

The uncomfortable truth: ChatGPT, Perplexity, and Gemini don't just read websites. They pull from reviews, directories, social profiles, press mentions, and third-party platforms. A business with no website can still be recommended accurately. A business with a website can still be described wrongly. The deciding factor isn't whether you own a domain — it's whether accurate, consistent information about your brand exists anywhere the AI can find it.

This article is an honest look at how AI assistants discover and recommend businesses, why "no website" doesn't mean "invisible," and what you can realistically do about it — without anyone promising you a ranking.

How AI Assistants Actually "Find" a Business

When you ask an assistant "where's a good bakery near me," it doesn't browse the live web the way a search engine does. It synthesizes from a few sources:

Structured business data — directories, map listings, and platforms that publish consistent NAP (name, address, phone) details.
Reviews and ratings — what people actually wrote, on Google, Yelp, niche platforms, or local apps.
Social and news signals — profiles, posts, articles that mention the brand by name.
Its own training and knowledge — which is only as current and accurate as what was published and verified in the past.

Notice what's missing: the brand's website is just one source among many. If your website is poorly marked up or says nothing verifiable, the AI leans on everything else. And if "everything else" is empty, the assistant either stays silent or — worse — invents a plausible-sounding answer.

The Silent-Success Problem

Here's what surprises most business owners. Many AI-first customers don't search at all in the classic sense. They ask an assistant to "recommend a florist that delivers in Jakarta" or "find a plumber open on Sunday near me." The assistant answers from its aggregated knowledge, not by browsing your homepage.

If your business has a consistent presence across a few credible third-party platforms, you can be recommended without a website. That's the entire premise behind distributed brand presence — building accurate information where AI actually looks.

But there's a catch. Just because the information exists doesn't mean it's correct. Names get misspelled, addresses drift, phone numbers change on one platform and not another. And when AI detects conflicting signals, it often hedges — or picks the loudest, most consistent story, which may not be yours.

The Honest Framework: Separating Published From Verified

The fair way to think about AI visibility has three layers:

Published — what exists about your brand anywhere (your listing, your ads, your posts).
Detected — what an AI actually picks up and uses in an answer.
Verified — what is confirmably true (open hours, pricing, real customer sentiment).

Too many companies only track the first layer and assume the third follows. They don't. The gap between "we published this" and "the AI got it right" is exactly where accuracy problems live — and where poorly-run "GEO" services overpromise.

The honest position is to test what the AI actually says about your brand, then methodically fix the gaps between published truth and detected accuracy.

What You Can Actually Do (No Website Required)

If you don't have a website — or have one that's thin — start here:

1. Be consistent everywhere. Pick a small number of credible platforms you matter on and keep name, address, phone, hours, and category identical across all of them. Consistency is the single strongest accuracy signal. One authoritative profile beats ten mismatched ones.

2. Get real reviews. Reviews are grounded, third-party verification. A handful of authentic, specific reviews on the platform your customers use does more for accurate AI recommendation than any self-published claim.

3. Generate citable mentions. A feature in a local publication, a podcast, a directory that actually verifies businesses — these become sources an AI treats as more credible than your own claims. They're "proof" that doesn't come from you.

4. If you do have a site, mark it up. Structured data (schema.org) is how you translate a website into machine-readable truth. This is where a website genuinely helps — not as a marketing page, but as a source of clearly-labeled facts.

5. Monitor, don't assume. Every few months, ask a few assistants the questions your customers ask, and write down exactly what they say about you. Track whether it's accurate, absent, or wrong. That's your real dashboard.

The Part Nobody Should Promise You

No honest professional will guarantee you a top recommendation from ChatGPT or a place in Gemini's answer. AI ranking is probabilistic, changes with model updates, and depends on factors you can't fully control. Anyone who sells you "guaranteed visibility in AI" is selling a fantasy.

What can be done is measurable and real: increase the accuracy and consistency of what AI can find about you, and verify whether detection improves over time. That's the difference between gambling on a promise and systematically removing the reasons an AI would get you wrong.

The Fair-Market Reason This Matters

The businesses most likely to lack a strong web presence — local shops, independent tradespeople, small producers — are also the most likely to be left out of AI recommendations entirely, or described inaccurately. AI assistants are becoming the front door to consumer decisions, and if that door only swings open for brands with big websites and big SEO budgets, under-resourced businesses get a smaller and smaller share.

That's the gap we care about. The Resets Company (theresetscompany.com) helps brands — including those without their own website — be found accurately by AI. We run AI detection audits to see whether assistants actually get your brand right, help build consistent distributed presence across credible third-party platforms, and monitor how detection and accuracy change over time.

We're deliberately honest about the limits: we don't promise rankings, and we separate what you've published from what AI actually verifies. The mission is simple — giving businesses a fair chance to be accurately found in an AI-based internet, even when they can't out-spend the big players.

If you'd rather not leave your discoverability to chance, start with a simple audit question: when an AI describes your brand today, is it true? Reach us at hello@theresetscompany.com.

Published by the editorial team at The Resets Company — helping brands be accurately found by AI.

How an AI Agent Decides When to Speak in a WhatsApp Group

Indra Gunanda — Thu, 03 Sep 2026 07:01:31 +0000

How an AI Agent Decides When to Speak in a WhatsApp Group

The easiest AI chatbot demo is a private chat: a customer asks a question, the bot answers. Boring, reliable, done.

The moment you put an AI agent inside a WhatsApp group, everything breaks. Groups are noisy, their messages interleave between humans and machines, and a bot that answers too eagerly gets muted or kicked within the hour. Yet groups are exactly where real business happens — reseller networks, VIP customer groups, team coordination threads.

This is the story of how we built the group-aware reply engine inside Hallo Zetta, the AI layer we run on top of the Zetta CRM platform. It's a walkthrough of one specific problem: given a stream of group messages, how does the agent decide whether to say anything at all?

Why Groups Break Naive Bots

A private-chat bot has it easy. The signal-to-noise ratio is 100%. Every inbound message is addressed to the agent.

A group flips that. Consider a reseller group:

09:14  Aisyah: “Harga paket enterprise berapa ya?”
09:16  Budi:   “Bentar, cek dulu. @Rina bisa tolong konfirm?”
09:18  Aisyah: “Oke makasih 🙏”
09:19  Rina:   “Harga enterprise Rp 750k/bln, min 5 users.”
09:21  Aisyah: “Sip. Kita tanda tangan besok?”

A naive bot processing every message would have replied to Aisyah's first message and to Budi's and to Rina's — interrupting a perfectly healthy human resolution, and probably confusing everyone. The gross failure mode isn't a wrong answer; it's answering a question nobody asked the robot.

So the core design principle became: in a group, the agent is silent by default. Speaking is an exception that must be earned. Everything downstream — the pipeline we built, the guards we enforce — exists to make that principle reliable.

The Trigger Model: Three Signals

Rather than run an LLM over every message (slow and expensive), the reply engine starts with a cheap, deterministic trigger layer. A message only becomes a candidate for an AI reply if it matches one of three signals:

Direct mention — the agent handle (@hallo zetta) appears in the text.
Quote reply — the message is a reply to one of the agent's own messages.
Explicit command — a prefix like /help or !price regardless of mention.

Everything else is dropped. No intent classifier, no LLM call, just a fast string/entity scan that runs in microseconds per message. This is a deliberate wall: we'd rather miss an unmentioned question than risk the bot volunteering into a conversation it wasn't part of. Trust in a group is destroyed once, and never fully rebuilt.

Scoping the Conversation

Once a message passes the trigger layer, the next job is scope.

In a private chat, context is whatever came before in that one thread. In a group, we need a much narrower window. We cannot feed the agent the last 50 messages — they're a tangle of unrelated threads between other people.

So we reconstruct a relevant mini-thread:

Quote chains. If the trigger is a quote reply, we walk the reply-parent chain to rebuild the sub-conversation the user is actually continuing.
Mention adjacency. If it's a mention, we take a short window around it, biased to the most recent messages touching the same topic before the mention — not after it.
Author identity. For the quoted segment we keep who said what, because in a business group who speaks (owner vs. member) changes whether the answer should be a firm policy or a gentle nudge.

The result is a compact, scoped context package that costs a fraction of the tokens a full-group context would, and produces far better answers because it isn't polluted by unrelated chatter.

The Decision Layer: Should We Even Reply?

Passing the trigger layer doesn't mean the agent speaks. There's a second gate — a decision layer that asks three questions in order:

Is the message a question or request? A mere echo, agreement, or social message gets no reply even if mentioned by coincidence.
Can the knowledge base answer it? We only reply with material grounded in the team's published knowledge base. If the retrieval confidence is below threshold, we stay silent and let a human handle it — we'd rather be absent than hallucinate pricing in front of a customer-visible group.
Is this already resolved? If a human has already answered the same question in the thread, we hold. Nothing annoys a group more than the bot repeating what a teammate just said.

This is where the engineering mirrors the product philosophy: Hallo Zetta is AI-first but never AI-only. Knowing when not to speak is a feature, not a deficiency.

Guardrails Overshadow Capabilities

Capabilities are what you show on a marketing page. Guardrails are what survive contact with a real group. We enforce several hard, non-negotiable blocks in the reply path:

One-turn minimum silence — never reply to our own preceding message in a loop.
Cooldown per group — a min gap between agent messages so it can't spam a rapid thread.
Quiet hours — configurable, no agent messages overnight unless the workspace explicitly opts in.
Handoff lock — the moment a human takes over a conversation, the agent is frozen on that thread until released. No accidental AI interjections while a person is handling it.

These are implemented in the tool/message layer, not as soft instructions in a system prompt. An agent cannot violate a hard block — it isn't a matter of following instructions well.

What We Learned in Production

Running this in real WhatsApp groups taught us three things we'd want every builder to know:

Trigger precision beats recall. We initially considered an ML intent model to catch questions without mentions. It caught a few extra, but the false-positive rate — the bot butting in uninvited — was unacceptable. Deterministic triggers with high precision are objectively better for group trust than a clever model with occasional rude failures.

Scope is a cost problem, not just a quality problem. Rebuilding the mini-thread is what keeps token spend sane when a group is busy. Watching the bill was the forcing function that made us stop feeding whole-group context.

Instrument the silence. The most useful log we added records why the agent did NOT reply for every candidate message: dropped-at-trigger, below-confidence, already-resolved, quiet-hours, etc. That off-path telemetry is how we tune thresholds and prove to skeptical teams that the bot isn't secretly being chatty elsewhere.

The Takeaway

An AI agent in a group is a house guest, not a co-host. It should be excellent at helping when invited, and effectively invisible when not. If you're building agents that live inside shared, human-dominated channels, engineer the silence first and the cleverness second.

The group-aware engine we run is one piece of the wider Zetta CRM platform — shared team inbox, contacts and labels, analytics, and the AI layer with full human handoff. If your team handles real, messy WhatsApp conversations, this is the kind of infrastructure we build every day at Cipta Dusa. Try the agent yourself at hallo.zettacrm.com.

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

Our DevOps Playbook: How a Small Team Ships and Operates 40+ Client Products

Indra Gunanda — Thu, 27 Aug 2026 07:02:30 +0000

Our DevOps Playbook: How a Small Team Ships and Operates 40+ Client Products

Agencies have a reputation problem. The stereotype is a team of developers who build something for six months, hand over a tarball, and disappear. We run the opposite model at Cipta Dusa: small team, dozens of concurrent client products, delivery measured in days — not quarters.

The only way that works is a serious DevOps playbook. Not because enterprise tooling is aspirational, but because automation is the only thing standing between us and chaos. This is the playbook we actually run, the decisions behind it, and the failures that shaped it.

The Constraint: Small Team, Many Products

We typically run 10–15 active client engagements at once: company profile sites, internal dashboards, SaaS backends, AI chatbots, WhatsApp CRM implementations. The team is intentionally small. That means every minute spent on manual deploys, environment drift, or "works on my machine" is a minute stolen from building.

So we made one system-level decision early: every project gets the same skeleton. Opinionated defaults, not bespoke setups. A new client project starts from an internal template repository, not from a blank git init. Customization happens after the pipeline is working, never before.

That single choice removes an entire class of problems. When every project shares the same CI workflows, the same deployment targets, and the same logging contract, the knowledge from one project transfers directly to the next. Onboarding a new developer takes days, not months.

The CI/CD Pipeline: Trunk-Based and Boring

We use GitHub Actions for everything. Not because it's exciting — because it's boring, reliable, and free for our scale.

The pipeline for every project looks like this:

name: ci
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint
      - run: npm test

  deploy-staging:
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to staging
        run: ./scripts/deploy.sh staging
        env:
          DOCKER_REGISTRY: ${{ secrets.REGISTRY_TOKEN }}

  deploy-production:
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    needs: [test, deploy-staging]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to production
        run: ./scripts/deploy.sh production
        env:
          DOCKER_REGISTRY: ${{ secrets.REGISTRY_TOKEN }}

Key decisions embedded in that file:

Trunk-based development. Short-lived branches, merge to main, deploy automatically. We don't do git-flow ceremony. For our team size, release branches are overhead, not safety.
Small scripts over platform magic. deploy.sh is a plain shell script that builds, pushes the image, and runs the rollout. Anyone on the team can read it in one sitting. No opaque "deploy via wizard" workflow.
Staging deploy is mandatory. Production deploy depends on staging having succeeded. If staging is red, nothing ships.

Containers: Local Parity Is Non-Negotiable

Every backend project ships with a Dockerfile and a docker-compose.yml that runs the full stack locally: app, database, redis, and any queue worker. The goal is that docker compose up on a fresh machine produces the same environment as staging and production.

This kills the most expensive failure mode in small teams: "it worked on my machine." If a developer's local environment matches production bit-for-bit at the dependency level, then most environment bugs surface during development, not after a deploy at 11 PM.

We also push version pinning seriously. Base images are pinned to a digest, not a tag. Dependencies are locked (package-lock.json, go.sum, uv.lock). Package upgrades are deliberate events with their own review, never incidental side effects of a feature branch.

Hosting: Match the Platform to the Job

We're unapologetically pragmatic about hosting:

Static marketing sites → Cloudflare Pages or Workers. Global edge, free SSL, instant rollbacks. There is no reason a company profile site should ever need a server.
Web apps and APIs → Docker on cloud VMs (Hetzner or DigitalOcean). We pick them deliberately for Southeast Asian latency, and the VM gives us full control without committing a client to a specific cloud's lock-in.
Managed databases → We default to managed Postgres. Yes, it costs a little more than self-hosting. It also means backups, failover, and point-in-time recovery are someone else's 3 AM problem.

The rule: use managed services for state, and keep compute disposable. If a VM dies, the deploy script should be able to recreate it in minutes. If the database dies, that's a real incident — so it gets real guarantees.

Environments, Migrations, and Zero-Downtime Deploys

Every project has at least preview → staging → production.

Preview: spun up per pull request, so the client can click a link and comment on the actual feature before merge.
Staging: mirrors production config, seeded with anonymized data.
Production: the real thing, with blue-green rollouts for anything that serves traffic.

Database migrations run as a separate step before the new code is live, never during. We learned the hard way that running migrations after rollout races the migration against live traffic — and losing that race means 500s for real customers.

Zero-downtime is the default, not a feature request. If a client asks "will there be downtime during the upgrade?" the honest answer for us is "there shouldn't be."

Observability: Logs, Errors, and Alerts That Actually Page Someone

You can't operate 40+ products by logging into 40 dashboards. So we standardize:

Centralized logging — every service streams structured logs (JSON, not free-text) to one place.
Error tracking — unhandled exceptions report themselves with stack traces and the exact deploy version that introduced them.
Uptime checks — synthetic health checks hit every production URL on an interval.
Metrics — response percentiles, error rates, queue depth per service.

Then the important part: alerts go to a single Telegram channel. Not 40 separate notification systems. One channel that the whole team watches. A p95 crossing 1 second or an error rate spiking gets a message within a minute, and whoever is free picks it up.

The probe rules are deliberately coarse. Alert on customer-visible degradation (latency, errors, downtime), not on every minor anomaly. Alert fatigue is real, and it's the fastest way to make your team ignore the system.

Security Without a Security Team

We don't have a dedicated security engineer. So security has to be a property of the pipeline, not a person:

Secrets live in the CI secret store, never in repositories. No .env files committed, ever — and a pre-commit hook refuses to stage them.
Dependency scanning runs on every PR. Known-vulnerability alerts block merges.
Least privilege by default — deploy credentials can only do their one job, and tokens rotate on a schedule.
Basic runtime hygiene — non-root containers, read-only filesystems where possible, HTTPS everywhere, security headers as part of the template.

None of this is fancy. It's the boring version of security that actually gets done because it's built into the workflow instead of being a quarterly checklist.

What Broke (So You Don't Have to)

Three failures shaped this playbook:

1. The un-rollbackable deploy. Early on, a deploy to production carried no rollback story. When it went wrong, we fixed forward — under pressure, at night. Now every deploy tags the image with a version, and rollback is a single command that swaps the tag. Fixed forward is the exception; rollback is the plan.

2. Config drift between environment and local. We worked on one project where staging and production had different environment variables for weeks. It worked in staging, broke in production, and took a whole afternoon to trace. The fix: a checklist in the template that diffs environment files across environments during deploy.

3. Alerting on everything. Our first monitoring setup alerted on every blip. Within a month the team had muted it entirely. We rebuilt it around the three signals that actually matter — latency, errors, uptime — and the channel became useful again.

Why This Matters for Clients

Our clients don't buy DevOps. They buy outcomes: the product is live, fast, and doesn't fall over.

With this playbook, a company profile site ships in two days (yes, really — it's our core offer at ciptadusa.com), a custom web app ships in weeks, and every one of them keeps getting deployments and monitoring after launch. When a client asks for a new feature six months later, we don't have to relearn the project — the pipeline, the environments, and the runbooks are all still warm.

It also means the team can be small. Automation substitutes for headcount, which keeps prices honest for startups and SMEs that can't afford a 10-person engineering org. That's the whole point of Cipta Dusa: production-grade engineering, delivered at the speed and budget a fast-moving company actually needs.

The Takeaway

If you're building or running client products, you don't need a platform team. You need:

One opinionated skeleton for every project — same CI, same scripts, same logging contract.
Boring CI/CD — trunk-based, small readable scripts, staging before production.
Managed state, disposable compute — never self-host the database; make the app servers replaceable.
Rollback as the default plan, not emergencies.
One alerting channel that only fires on customer-visible problems.

We've run this playbook across 40+ products and it holds up. The tooling changes, but the discipline stays. If you want to see what it produces, we're building new stuff every week at Cipta Dusa.

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

Building Real-Time Analytics for a WhatsApp Native CRM

Indra Gunanda — Thu, 20 Aug 2026 07:01:42 +0000

Building Real-Time Analytics for a WhatsApp Native CRM

Every CRM vendor ships a table of numbers. Very few ship analytics that a team actually acts on. When we were building the analytics layer inside Zetta CRM, the numbers were never the hard part — the hard part was deciding which numbers matter and getting them to the screen fast enough that a support lead can change their routing mid-shift, not report on last week's problems.

This is the story of that layer: the event pipeline, the metric definitions that survived contact with real teams, and the operational decisions we'd make differently next time.

Why WhatsApp Analytics Is Different

If you've ever built analytics for an email-based product, you're used to a comfortable rhythm: open a message, leave it in the inbox, process it hours later. Timestamps are forgiving. Peaks and valleys are predictable.

WhatsApp is real-time in a way email never is. A customer waits 40 seconds, not 40 hours, before deciding you're unresponsive. That changes the analytical contract:

Latency is a first-class metric. Email tools can report on "median time to first response" as a weekly average. WhatsApp teams optimize p95 now, in the middle of the day.
Conversations are bursty and multi-modal. A single interaction is a photo, a voice note, three short texts, and a document — not a clean thread of one message per event.
Groups warp every metric. One active reseller group can produce hundreds of messages that are not "leads" and should not pollute first-response stats.

So the first decision was: analytics is not a reporting tab bolted onto the CRUD layer. It's a separate pipeline with its own shape. Here is what we built.

The Event Pipeline: One Shape for Everything

Early on we made a choice that paid off repeatedly: every meaningful thing that happens in the product emits a strongly-typed event. A message arrived, a label was applied, a handoff triggered, an agent picked up a conversation, an AI auto-replied. No ad-hoc database polling, no "just query the messages table for this dashboard."

WhatsApp Gateway ──► Message Processor ──► normalized Event ──► event store
                                                                    │
                        Team Inbox actions ──► Event                 │
                                                                    ▼
                                                          stream consumers
                                          (rollups, anomaly checks, caches)

Each event carries a conversation_id, contact_id, number_id, agent_id (nullable — AI events carry their own actor type), a channel_context flag for is_group, and a precise timestamp.

{
  "event": "message.arrived",
  "ts": "2026-08-19T09:14:03Z",
  "conversation_id": "conv_9021",
  "contact_id": "c_441",
  "number_id": "n_2",
  "is_group": false,
  "is_ai": false,
  "media_types": ["image"],
  "direction": "inbound"
}

Why typed events instead of tables? Because the same event feeds three very different consumers — live dashboards, weekly rollups, and the AI agent's context — and giving each one a cleaned, normalized event beats making them all parse raw chat rows. It also means we can add a new metric later without touching the ingestion code that teams already depend on.

Defining the Metrics That Actually Matter

We shipped an initial dashboard crammed with vanity metrics and watched nobody open it. The reset came when we asked support leads one question: what would you change at noon if you saw this number?

That produced a short, opinionated list — and it's still what the dashboard shows today:

First response time (median, p95, p99). The single metric that decides whether customers feel ignored. Segmented by number and time-of-day.
AI deflection. What fraction of conversations reached a resolution without a human touching them. Too high for you? Your AI may be too eager. Too low? Your knowledge base is too thin.
Agent load. Live count of active conversations per agent, feeding routing so a free teammate picks up the next assignment.
Resolution rate. Tracking a conversation to an actual outcome, not just "someone replied."
Peak hours. When the queue overflows so a lead can staff the afternoon accordingly.

Every metric lives behind a group-aware flag. Messages inside group chats are excluded from first-response and deflection stats by default, because they follow a totally different rhythm. That one flag stopped us from publishing numbers that scare teams for the wrong reasons.

Going Real-Time Without Rebuilding the World

The naive approach to live dashboards is in-memory state on an app server — which dies on redeploy, and drifts on multi-instance. The corporate approach is a full streaming platform like Kafka, which is overkill when you need thousands of concurrent connections, not millions.

We landed on a deliberately boring stack:

A lightweight event store (append-only, partitioned by number) as the source of truth for rollups.
An in-memory rolling window per number for the live dashboard, recomputed from recent events, seeded from the store on server start.
A WebSocket push layer to the browser for sub-second updates.

The trade-off we accepted: the live window is eventually consistent — a small window of data can be ephemeral if a server dies. That's fine for "what's happening right now," where being 30 seconds stale is acceptable. The durable rollups, which power weekly reports and historical charts, are recomputed from the event store in a background job, so they never lose a message.

If we ever outgrow the in-memory window, the upgrade path is explicit: replay the event store into a real stream. Because ingestion was event-first from day one, that migration doesn't invalidate the dashboards — it just changes their backend.

What We Got Wrong

Three mistakes are worth writing down, because each cost us a redesign that a bit more thought could have avoided.

Mistake 1: vanilla analytics for everyone. We rolled out one dashboard for all roles. Admins wanted strategic views; agents wanted "is my queue drowning." Same screen served nobody. The fix was role-scoped dashboards — a small change that dramatically lifted usage.

Mistake 2: no timezone awareness. A business that serves customers across Indonesia on one number was bucketing "peak hours" by server timezone, so the busiest period looked like 03:00 AM. All analytics now respect the workspace's configured timezone, and peak-hour analysis is done per number, not globally.

Mistake 3: single-agent routing assumed for agent-load. Load tracking assumed one conversation = one person's queue. Teams with shared pools and hot-handoff workflows broke that assumption. The metric now reports active conversations per team, with an agent-level breakdown as the secondary view.

What the Analytics Feed Back Into

The best part of building analytics into a WhatsApp-native CRM is that the output doesn't just sit on a dashboard — it drives product behavior:

Routing. Live agent load feeds the assignment router, so new conversations go to the least-loaded teammate instead of pinging everyone.
AI tuning. Deflection and handoff rates tell us whether the Hallo Zetta agent's knowledge base is underpowered — without waiting for complaints.
Team accountability. p95 response times, split by agent and number, make slow periods visible instead of personal.

For developer teams, all of these metrics are reachable programmatically. Zetta CRM exposes contacts, labels, conversations, and analytics through a first-party API, with webhooks for real-time events like message.arrived and label.applied. Teams building custom dashboards, internal SLAs, or AI workflows consume the same event stream that powers our own UI — a lesson we learned the hard way (delay the API once, and your most technical users start screen-scraping).

Principles Worth Stealing

If you're building analytics for a chat-native product, these are the ideas we'd defend:

Emit typed events for everything, before you need them. The cost is small; the flexibility is enormous.
Define metrics by the decision they enable, not by what's easy to count. Ask "what would I change at noon?"
Segregate group traffic from DM metrics. One active group will otherwise corrupt your entire report.
Boring infrastructure wins. An append-only store plus a rolling window beats a platform team you don't have yet.
Feed metrics back into behavior — routing, tuning, staffing — or nobody will look twice.

This is the analytics layer we run behind Zetta CRM today, built the same way we build everything: event-first, observability as a product feature, and small enough to change when reality disagrees with the plan.

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

MauAI — the AI agent built for Indonesian businesses (whitelist = 1 month free)

Indra Gunanda — Wed, 19 Aug 2026 07:39:59 +0000

Most AI chatbot tools on the market are built for Western markets — English-first, priced in USD, and unaware of how Indonesian businesses actually talk to their customers.

That's the gap MauAI is built to close.

The problem

For a typical Indonesian SME (UMKM), customer service is a real cost:

A full-time CS hire to answer the same ordering/price questions all day
Slow replies at night, so you lose customers who message at 11 PM
English-only chatbots that miss the conversational style Indonesian buyers use

You don't need a flashy AI platform. You need something that talks the way your customers talk.

What MauAI is

MauAI is an AI chatbot / agent designed for Indonesian businesses. It handles the repetitive side of customer interaction automatically — answering product questions, taking order inquiries, being available 24/7 — while your team focuses on closing deals.

It's being built local-first: Bahasa Indonesia, local context, priced for the Indonesian market.

Launch promotion: whitelist = 1 month free

The waitlist is open now at https://mauai.id/. Early joiners who get into the whitelist receive the first month free once MauAI launches.

Right now the site is a coming-soon landing page — so the best move is to grab your spot early and secure the free month.

Why sign up early

Whitelist members get 1 month free at launch
You'll be the first to know when it goes live
No spam, no cost, unsubscribe anytime

If you run a business in Indonesia and are tired of chatbots that don't get you, this is one to watch.

👉 Join the waitlist at mauai.id

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.