TaifaSupport Docs
Live visitor intelligence

Support that knows who is on the site right now.

TaifaSupport is a customer support platform for Kenyan government ministries, counties, state departments and agencies, and for commercial tenants. The difference from a normal helpdesk is one sentence long: Visitor, Session, Customer, Conversation and Ticket are all the same record.

Get startedRun it on your own hardware

The row that is the product

An agent sees the journey, not the sentence.

This is one row of GET /v1/visitors/live. Every value on it is a real column, joined at query time because the rows are already linked. An agent opening the chat does not see only what the person finally typed.

James MwangiKE
Acme LtdPricing → Enterprise
online 8m 42s, 6 pages2 open tickets

Referrer and referring host

VisitorSession.referrer_host

Traffic source and campaign

utm_source, utm_medium, utm_campaign

Time on site

VisitorSession.duration_seconds

Pages seen, with timestamps

PageView

Open tickets already filed

tickets.visitor_id

Coarse country, never the IP

VisitorSession.country_code

The chain

Five tables, one thread.

Nothing here is stitched together at read time by a feature. The chain is a schema fact, which is why it holds for a visitor who first arrived three months ago and only identified themselves this morning.

Visitor
visitors.id
One browser, recognised across visits by an opaque token. Anonymous until something identifies it.
Session
visitor_sessions.visitor_id
One continuous visit. Carries referrer, UTM, device, country, duration and page count.
Customer
visitors.customer_id
A known person, created by identify(). Linking one back-fills every earlier session.
Conversation
conversations.visitor_id
A chat thread, carrying the visitor, the customer and the session it started in.
Ticket
tickets.conversation_id
A tracked obligation with a status, a priority and an SLA clock, still pointing at the row above.

Read how the chain is built

Editions

One codebase, two products.

Selected by EDITION in a single root .env. Nothing about the feature set differs: RBAC, teams, the knowledge base and the full API ship on both, because gating permissions behind a price tier is a non-starter for a government tenant.

Self-hosted EDITION=self_hosted

  • An institution runs it on its own hardware, under its own domain.
  • First run walks a configuration wizard at /setup. No public signup.
  • No billing, and no conversation metering anywhere in the schema.
  • With the AI profile enabled, no part of the install has to reach the internet at all.

Cloud EDITION=cloud

  • Our multi-tenant deployment. Public registration, 14-day trial.
  • Per-seat pricing in Kenyan shillings, through Paystack once checkout ships.
  • No wizard: the tenant is created at signup.
  • The same API, the same roles, the same widget.

Where to go next

The documentation.

Quick start

Clone, `make dev`, `make migrate`, `make seed`. A working install with a realistic demo Institution in about five minutes.

Self-hosting

The full install on an institution’s own hardware, swapping in an existing PostgreSQL, Redis or S3, and running Gemma locally.

API reference

Every endpoint group under /v1, both websocket channels, and the message envelope both directions.

The widget

One script tag on a portal. The tracker that feeds the live list and the chat surface the citizen talks through, in about 9 KB gzipped.