From a lead list to a workspace CRM

A useful table in a chat answer often becomes another copy-and-paste job. You move it into a spreadsheet, add an owner column, and return a week later to discover that the conversation and the spreadsheet disagree.

Vocion Lists give that work a home. Ask for a List, keep the records, and return to the same editable table after the conversation ends.

Try the interactive example · Read the Lists guide

Start with one job

Imagine coming back from a conference with notes about three people. In your personal assistant, ask:

Build a follow-up List from these notes. Include the person, company, next action, owner, due date and source. Leave anything we do not know empty.

The assistant can define the fields and save records. The result is a link to a List you can open and edit. It stays there when the chat closes.

Here is a fictional example:

Mark a follow-up done in the table, or tell the assistant what changed. Both paths write through the same service. A List created for a short project does not expire: finish the work, then archive it when you are ready.

A follow-up row records the commitment. It does not send the email or schedule a reminder by itself. Those are separate actions, with their own setup and authorization.

Personal work does not need an administrator

Every member can create and maintain personal Lists: event follow-ups, a research shortlist, or a plan broken into steps. Other people cannot read those personal rows through Vocion, including admins.

The audience is also a chat boundary. The personal assistant can work on personal Lists. Shared workspace chat works on shared Lists, keeping private records out of shared transcripts and activity logs.

Admins manage shared structures: creating workspace Lists, adding shared fields, configuring shared views, and installing a CRM starter. Members can keep the shared records up to date. Maintaining a contact's next step should not require permission to redesign the team's CRM.

Give ongoing work a stable structure

When the team needs a CRM, an admin can ask:

Set up our workspace CRM with companies, contacts, deals and follow-ups.

The starter creates four linked Lists. Contacts point to companies. Deals can point to both. Follow-ups can point to a contact or deal and carry an owner, due date and status.

These links are validated. A field declared as a number accepts a number, and a reference must name a record in the right List. The schema can grow by adding fields without deploying new code. Existing field types are protected from casual reinterpretation.

The starter is intentionally specific about what it supplies: records, relationships, editable tables, saved views and aggregation. External CRM synchronization, automatic reminders and outreach need separate setup. Board layouts and a full activity timeline are not part of this initial release.

Grow without losing the original work

An owned personal List can be published to a shared workspace you administer. Its record IDs and history stay with it. Publication exposes all its records and history, so it is an explicit action.

References must remain valid. A shared List cannot point to private records, and moving a List that another List references is refused. You resolve those relationships before moving it.

Publishing a List does not automatically transform its fields into the CRM starter's model. It gives the existing work a shared home; an admin can then add the structure the team needs.

Totals should mean every matching record

The table loads records in pages. Aggregation runs in the database across all matching rows, so “how many open follow-ups?” is not a count of whatever happens to be on screen.

For deal amounts, group or filter by currency before summing. The system stores the currency; it does not pretend that dollars and euros can be added together.

Every mutation records the actor and before/after values. If another person or agent edited the List while you were working, a version check rejects the stale save so you can reconcile it. Archiving retains the data and its history.

Built on the database already there

Lists use PostgreSQL with JSONB for flexible definitions and record values. Workspace and owner boundaries are checked in the service for every operation. Personal rows are isolated from the existing workspace-wide business-object search.

That lets a small personal List and a maintained team CRM use the same durable foundation. The difference is how the work is owned, structured and maintained.

Explore Lists or follow the setup guide.