Product

ConvoTide, surface by surface.

ConvoTide is one workspace with five connected surfaces: WhatsApp campaigns, a shared inbox, CRM and lead management, visual journeys, and a documented API. This page explains what each surface does today, at pilot stage — including what it will not do yet.

WhatsApp campaigns

A campaign is an approved message template sent to a chosen audience, with guardrails before anything leaves. You build it in four guided steps — audience, template, schedule, cost preview — and the platform keeps an honest record of every decision.

• State machine, not free-for-all. A campaign moves draft → scheduled → sending, and you can pause, resume or cancel while it runs. The platform refuses illegal moves (a draft cannot start sending; finished campaigns stay finished) instead of quietly allowing them.
• Consent-gated recipients. Adding a contact to a campaign is refused when the contact has not opted in on that channel. Adding the same person twice is absorbed by idempotency — you get the same result, never a duplicate.
• Preflight before send. Consent, template state, quiet hours and frequency caps are checked before a send; the cost preview states plainly when no estimate exists rather than showing an invented number.

Pilot surface Run the campaign preflight →

Shared inbox

Every inbound conversation for your number lands in one queue your whole team works from — with context, ownership and honest state, so two people never silently work the same customer.

• Claim and release. A conversation you claim shows who holds it; if a colleague already holds it, the claim is refused and names the holder. No private side-channels.
• Canned replies and drafts. Approved answers are inserted verbatim into your draft, and usage is counted — so the team learns which answers carry the load.
• Live updates. The queue and thread views follow new activity in near real time, with unread state you can trust.

Pilot surface Preview the inbox in the workspace tour →

CRM and lead management

Pipelines and deals sit beside the conversation, so a reply becomes a next step without copy-paste between tools.

• Pipelines and a deals board. Deals move through your pipeline’s stage columns; won and lost are terminal by design, so history cannot be rewritten.
• Follow-up tasks. A promise made in chat becomes a task with an owner and a due date — cancelled automatically when the customer replies first.
• Contacts come from real conversations. Contact records are created by inbound messages and capture (QR codes, links, widgets, ad referrals) — the CRM never manufactures contacts that no conversation produced.

Pilot surface See the lead-to-outcome tutorial →

Visual journeys

Journeys are ordered automation steps a contact walks through — with consent checked at the gate, not as an afterthought.

• Steps in a fixed order. You compose named steps (a template send, a wait, a consent check, an end); the engine validates the sequence and refuses broken drafts.
• Consent is a first-class step. Outbound journey sends are opted-in-only by contract, and a contact that withdraws consent leaves the journey with a visible exited_consent state.
• A picture of what is running. A read-first canvas draws the journey exactly as the engine runs it. In this release the canvas is read-only — journey editing is form-driven — and we say so in the product rather than faking a designer.

Pilot surface How consent gating works →

APIs and reporting

A versioned send API with idempotency keys, signed webhooks and uniform errors — documented exactly as built. Reporting reads the same events: per-message delivery timelines, saved reports with bounded windows, and journey funnels.

Documented as built Read the API documentation → Interpret campaign results →

What is available at pilot