DenchClaw for Distributed Teams: CRM Across Time Zones

A distributed team with members in New York, London, and Singapore doesn't have overlap hours — at least not many. A team member in Singapore is finishing their workday as the New York team is starting theirs. The London member bridges them for a few hours, then goes offline.

Managing a shared CRM in this environment is genuinely hard. When should you run the pipeline review? How do you share context across 12-hour time differences? Who's responsible for updating the record when three different people touch the same account across three continents?

DenchClaw's architecture makes distributed teams work better than any SaaS CRM: the agent operates asynchronously, push notifications are timezone-aware, and Telegram creates a single conversational layer that doesn't care what hour it is.

The Shared Instance Architecture#

For a distributed team, DenchClaw runs on a shared server — a VPS, home server, or (coming soon) DenchClaw Cloud — rather than an individual laptop. Every team member connects to the shared instance via their preferred messaging app.

Setting Up a Shared VPS Instance#

# On your VPS (Ubuntu/Debian):
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo bash -
sudo apt-get install -y nodejs
npx denchclaw --host 0.0.0.0 --port 19001

Configure a reverse proxy (nginx) with HTTPS:

server {
    listen 443 ssl;
    server_name crm.yourcompany.com;
    
    location / {
        proxy_pass http://localhost:19001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
    }
}

Now crm.yourcompany.com is your team's shared CRM. Each team member:

1. Connects their Telegram to the shared DenchClaw bot
2. Bookmarks the web UI at crm.yourcompany.com
3. Starts updating records via Telegram or the web UI

Database Concurrency#

DuckDB handles concurrent reads well. For concurrent writes (multiple team members updating simultaneously), the agent serializes write operations to prevent conflicts. In practice, conflicts are rare — different team members are usually updating different records.

Time Zone-Aware Operations#

The key to distributed team CRM: every alert, briefing, and reminder fires at the right local time for each team member.

Configuring Per-Member Timezones#

Tell the agent to track timezones:

"Remember: Sarah is in New York (ET), Marcus is in London (GMT+1 currently), and David is in Singapore (SGT, UTC+8). When sending scheduled messages or reminders, convert times to each person's local timezone."

The agent stores this in its memory and applies timezone conversion automatically.

Personalized Morning Briefings#

Each team member gets their briefing at 8am their local time:

"Send each team member their morning pipeline briefing at 8am their local time. Include their follow-ups for today, any deals that changed stage in the past 24 hours, and any team-wide highlights from the day before."

This means:

• Sarah gets her briefing at 8am New York time
• Marcus gets his at 8am London time (4 hours later)
• David gets his at 8am Singapore time (12 hours after Sarah)

Each person starts their workday with the same current picture, regardless of timezone.

The Follow-the-Sun Coverage Model#

For customer-facing teams with global customer bases, DenchClaw can route customer inquiries and escalations to the team member whose timezone is active:

"If a support ticket or inbound message arrives between 10pm ET and 8am ET, route the notification to David in Singapore. Between 8am ET and 6pm ET, route to Sarah or Marcus. Outside both windows, send to the general team group."

This is a simplified follow-the-sun model that ensures no customer inquiry waits 8+ hours for a response.

Async Deal Handoffs#

When a deal crosses timezones — started by Singapore David, continued by New York Sarah — the CRM entry carries the context.

The handoff protocol:

David (Singapore, end of day):

"Handing off the TechCorp deal to Sarah. Status: had a great second call with their CTO, she wants to include the VP Finance. Need to schedule a 3-way demo. Sarah's timezone preferred for the demo call. Next step: coordinate with TechCorp's EA for scheduling."

The agent logs this as a handoff note in TechCorp's entry document, tags Sarah, and sends Sarah a Telegram message: "Handoff from David: TechCorp deal, [full context]."

Sarah (New York, 8am): Sees the briefing, sees the TechCorp handoff note, picks up exactly where David left off. No Zoom call required.

Cross-Timezone Deal Reviews#

The weekly pipeline review for a distributed team can't be a single meeting — the timezones don't overlap cleanly. Instead:

Friday 5pm New York (Saturday 9am Singapore, 10pm London): The agent generates the weekly pipeline review and posts it to the team Telegram group.

Weekend (async): Each team member reviews their portion of the pipeline, adds notes via Telegram, flags questions or concerns.

Monday morning (local time): Each member gets an updated briefing incorporating the weekend's async review. If a synchronous discussion is needed, it happens in the 2-hour overlap window (9-11am New York = 2-4pm London = exactly the daily overlap).

The synchronous meeting, when it happens, covers only the issues that couldn't be resolved asynchronously.

Customer Timezone Management#

For companies selling to global customers, add timezone tracking to your customer records:

fields:
  - name: Customer Timezone
    type: enum
    options: [US/Eastern, US/Pacific, US/Central, Europe/London, Europe/Berlin, Asia/Singapore, Asia/Tokyo, Other]
  - name: Best Contact Time
    type: text  # e.g., "9am-12pm local"
  - name: Primary Language
    type: enum
    options: [English, Spanish, French, German, Japanese, Mandarin, Other]

When scheduling follow-ups, the agent accounts for customer timezone:

"Schedule a follow-up with TechCorp Tokyo in 3 business days. Find a time that's 9am-5pm Tokyo time and doesn't conflict with Marcus's London schedule."

The agent checks both timezones, identifies the overlap, and proposes meeting times.

The Async-First Communication Protocol#

For distributed teams, establish clear norms around CRM communication:

Norm 1: Telegram first, email second. Anything CRM-related goes through DenchClaw's Telegram channel. Email is for external communication. This creates a single source of truth.

Norm 2: Log before you close your laptop. Before ending your workday, send any unlogged updates to DenchClaw. The Singapore member's last 5 minutes of work creates context for the London member's morning.

Norm 3: Tag for handoffs. When something needs another team member's attention, include @sarah or @marcus in the Telegram message. The agent routes the notification to the right person.

Norm 4: Assume async. Don't wait for a meeting to share a CRM update. Log it immediately. The next person to work on the account will have the context when they start, not when you're both online simultaneously.

Frequently Asked Questions#

Is a VPS required for a distributed team, or can it run on one person's laptop?#

A VPS (or DenchClaw Cloud when available) is strongly recommended for distributed teams. Relying on one person's laptop means the CRM is unavailable when their computer is off or they're asleep. A 24/7 shared server gives the whole team always-on access.

How do we handle access control — we don't want all team members seeing all deals?#

Currently, DenchClaw doesn't have granular field-level permissions between users on a shared instance. The workaround: separate objects for sensitive deals, with naming conventions that indicate confidentiality. Full role-based access control is on the roadmap for Team Workspaces in Q3 2026.

What's a realistic VPS cost for running a team DenchClaw instance?#

A $6-12/month VPS from DigitalOcean, Hetzner, or Linode is sufficient for teams of up to 10 people. DenchClaw is not resource-intensive — the DuckDB file and agent workload fit comfortably on a 1-2 vCPU, 2GB RAM instance.

Can team members in different countries use different AI models?#

Yes. Each DenchClaw instance can be configured with a preferred AI model. If your team is in regions where certain AI providers have restrictions (some regions have limitations on certain OpenAI or Anthropic products), you can configure DenchClaw to use an alternative provider that's available in that region.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →