~/crm/service

Service

The helpdesk. Tickets, queues and replies — in the same workspace as the customer they came from.

Written honestly: the ticket app exists in the workspace today; the email loop and external API are being built now; the reporting widget is a design exploration. Chips below say which is which.

The queue is the app

Support is a queue worked by people. Tickets arrive, get an owner, a priority and a state — open, waiting, solved — and every reply is on the record. Views cut the queue the way teams actually work it: unassigned, mine, breaching first.

One ticket, whole picture: the conversation, an agent's triage note with a drafted reply, and the requester's real record — deals, invoices, history — one glance to the right.

Four ways a ticket arrives

Emailsupport@yourcompany — replies become the conversation, both directionsin build
The widgetscreenshot, highlight, submit — embedded in your productdesign exploration
The APIyour systems file and read tickets machine-to-machinein build
The apptickets raised inside the workspace, by people or agentsexists today

Email is the channel that matters most and the one we hold ourselves to: a customer mails support@yourcompany, the thread becomes the ticket, and a staff reply lands back in their inbox. The widget and the API mean a company like Bidvise gives its customers support without building any support UI — their product files tickets, their team works the queue here.

Support that knows the customer

A helpdesk bolted onto your stack sees a stranger with an email address. Here the requester is the CRM contact: the company, the running deal, the invoices, every past conversation — the same records, read in place. Support answers with the relationship in view, and sales sees the support history before the renewal call.

And because agents are members, triage is a worker in the queue: it labels, routes, links the records a reply will need, and drafts — a person sends.

Where this is going

The proving ground is real: Bidvise's customers will file into Tedo Service while Bidvise builds no support UI at all — API first, then the email loop, then the widget. Nothing ships as done here before it survives that.

Later, deliberately: SLAs and breach findings, macros, a public help center written from solved tickets. Fewer features, each finished.