Use Cases

These examples show how the pieces work together in the web app. Each one is a sequence: data and people first, then an assistant or workflow, then a channel or trigger, then operate with approvals and notifications.

They are not copy-paste recipes. Follow the linked pages for field-level settings. Use Studio if you want help creating the resources by chat.

Start from Introduction if you need the product map first.

WhatsApp customer support

A visitor messages WhatsApp. An agent answers from your docs, opens a ticket, and escalates to a human when needed. Agents never send a refund without a supervisor.

What you need

How to build it

1. Connect services — Under Integrations → Third Party Services, connect an LLM and WhatsApp (Twilio or Exotel).
2. Bring the team in — Invite people at company Users, add them on Workspace users, create a Support role, and put those members on a chat profile.
3. Index answers — Create a knowledge base, add FAQ or policy files as datasources, and wait until they are indexed.
4. Create Tickets — A table with at least status, phone or name, and a summary. Limit Access to the Support role if only they should see the grid.
5. Create the agent — Build → Agents, channel Chat. Write the Task: greet, search the knowledge base, create or update a ticket, hand over when the customer asks for a person or the answer is missing. Attach the knowledge base, table tools (or a query), chat handover, and Send Notification.
6. Gate risky tools — On Tools, require role approval for anything that writes money-sensitive data or sends outbound templates. Support members approve on Approvals.
7. Open WhatsApp — Build → Channels, type WhatsApp Chat. Set this agent as Default agent, pick the sender number, and turn the channel active.
8. Operate — Preview in the builder first. Then send a test WhatsApp. Confirm a ticket row appears, the bell notification reaches Support, and handover lands on the chat profile.

Optional: a query plus a widget on the home dashboard so supervisors see open tickets without opening the grid. Optional: a chat widget so the agent can show ticket status as an in-chat card instead of a long text reply.

Website lead intake and sales follow-up

Someone fills a public form. Vettero stores the lead, notifies sales, and a workflow starts outreach. A quote email or WhatsApp template only goes out after a human approves.

What you need

How to build it

1. Model the lead — Create a Leads table: name, email or phone, source, status, notes. Add a form that shows only the fields a visitor should fill. Create a private link (optional email OTP) and put that URL on your site.
2. Roles and inbox — Add sales people as workspace users with a Sales role. They will get notifications and approve sends.
3. Write the follow-up copy — An email template (MJML) and/or a WhatsApp template synced from Twilio.
4. Automate on insert — Build → Event handlers, trigger Row inserted on Leads. Use Free-form workflow.
5. Draw the workflow — Typical path:
   • Read the new row from event args.
   • Send Notification to the Sales role, linking the table.
   • Optional: Request Approval or a gated send tool so a person confirms the first outreach.
   • On approve: Send Email (after Google) or Send WhatsApp Template.
   • Update the lead status on the table.
6. Defer a second touch — From the same workflow, create a schedule (or a schedule block) to run a reminder agent or workflow the next day if status is still new.
7. Optional site chat — A separate chat agent with a Web integration. The Task tells it to collect the same fields and insert into Leads (or open a share-agent link). Form and chat can feed the same table.

Test by submitting the form yourself. You should see a new row, a bell notification, an approval (if you gated the send), then the email or WhatsApp, then the status change.

Internal policy assistant and requests

Employees ask policy questions in the Vettero sidebar. When they need something (access, a purchase, time off), the agent files a request row, a manager approves, and the requester is notified.

What you need

How to build it

1. People — Add employees as workspace users. Create Employee and Manager roles. Restrict the Requests table so employees can insert (or only the agent writes) and managers can edit status.
2. Ground the assistant — Knowledge base with policy files. Attach it to a chat agent. Task: answer only from retrieved docs; if the user wants a request, insert a row instead of inventing an approval.
3. File requests in the table — Attach table insert/update tools (or a query). Set Require role approval on the insert or status-change tool so Manager must approve on Approvals (or in-chat if they are the current user).
4. Notify both sides — After a row is created or approved, Send Notification to the manager (new request) or the requester (decision). Optionally an event handler on row updated when status becomes approved.
5. Publish in-app — On the agent, Integrations → In App. Grant View to Employee (and Manager). Members see the chat in the workspace sidebar — not on a public website.
6. Optional dashboard — A query of open requests bound to a widget for managers. Employees keep using the sidebar agent.

Walk the path as an employee (ask a policy question, then ask to file a request), then as a manager (approve, confirm the notification and the row).

How to reuse this pattern

Most Vettero solutions follow the same four moves:

1. Store — Tables, files, knowledge bases.
2. Decide — Agent (the model chooses tools) or workflow (you draw the path), plus approvals when a human must confirm.
3. Reach people — Channels, chat integrations, forms, schedule, or event handlers.
4. Operate — Workspace users, roles, notifications, preview, then production traffic.

For field-level settings, open the linked page for each building block.