Brand

The single record every reply, draft, and agent call reads — what it holds and who consumes it.

This page describes an earlier design of ListeningKit, built on an in-browser demo, so parts of it do not match the app that runs today. For what works now, read the Guide.

Brand

One workspace, one brand record. Onboarding creates it from the website URL, the reveal enriches it, the dashboard's Brand tab edits it, and every reply draft and (soon) agent call reads it. Nothing in the app invents business facts — anything the brand hasn't provided falls back to generic phrasing.

This is the hackathon build: the brand store is a mock (in-memory + localStorage) with deterministic seed data. The live backend replaces the transport; the shapes below stay the same.

Sections

Every field has exactly one defined consumer. If a field has no consumer, it doesn't belong on the record.

SectionHoldsConsumed by
identityname, website, tagline, logo URLReply sign-off, resource URLs, dashboard header
voicetone, formality, dos / don'ts, gold-example repliesbuildBrandSystemPrompt() → agent instructions
channelsper-channel style, raw texting snippets, triage flowsimulateReply() preview, per-channel agent generation
memoryworking facts & boundaries (pricing, jobs taken/declined)Compiled into the system prompt; retrieved, never dumped raw
offerings{ name, detail }[] services / productsReply service-bit, agent tool/RAG context
locationlabel, lat / lng, radius kmListings default, group scoping, reply area
sourcesindexed website pages (url, title, headings, text, status)RAG namespace content, reply citations
intelligenceselected keyword, competitor domains, target communitiesKeywords / groups seeding

Two rules the model enforces:

  • Areas live in location, never in voice. Voice is purely about language — how replies read, not where they apply.
  • Offerings are objects, not strings. The agent quotes the one-line detail per service instead of dropping a bare name into a reply.