Vora
An AI CRM platform for service businesses: missed-call text-back, lead follow-up, campaigns, and scheduling in one system. Approval requirements depend on the action and the configured policy.
- Contribution
- I design and build the product, its agent tools, and the business workflows around them.
- Maturity
- Implemented
Interactive simulation · sample data
Primary demonstration
Portfolio simulation screenshot: a fictional Cedar Repair follow-up awaits a decision. Approval depends on configuration; this proposed action remains conceptual and has not been verified as a supported delivery path. No real message is sent.
Interactive simulation · sample data
Approval depends on the configured action. This follow-up is conceptual; its exact supported action has not been verified.
Public example checked 2026-09-12. Portfolio simulation screenshot: a fictional Cedar Repair follow-up awaits a decision. Approval depends on configuration; this proposed action remains conceptual and has not been verified as a supported delivery path. No real message is sent.
Initial example · Request received
Cedar Repair · Customer A
My kitchen tap is dripping. Could someone come by this week?
Proposed follow-up: Propose a message asking which day works for a repair visit.
A fictional repair request arrives. A follow-up is proposed for review.
This reference frame stays at the beginning. Current decisions appear in the interactive example below.
Interactive controls load when this example comes into view.
If the interactive example stops responding, Reload this example.
Problem and workflow
The problem
A service business can receive a request before anyone is ready to act on it. A customer needs an answer, but a useful answer may depend on availability, the history of the job, or a decision from the owner. Putting an AI employee in that gap raises a practical question: what may it do on its own? A proposed message and a sent message are different things. The interface needs to make that distinction visible, including when a person rejects the proposal or an approved action fails. This example concentrates on that decision boundary inside a CRM workflow.
The workflow
Cedar Repair and Customer A are invented for this page. The request, proposed message, error and CRM activity are purpose-written samples. Choose an execution outcome, inspect the proposal, and record a decision. Approval permits the next step in the illustration; it does not guarantee that the selected sample execution succeeds. Changing the outcome restarts the request so a previous decision cannot carry into a different branch.
01Reject the proposed action
- 01Start at Request received with the fictional repair request. Select Review proposed action.
- 02At Awaiting approval, inspect the recipient, proposed follow-up and reason for review. Select Reject example.
- 03Rejected: No action taken in this example. There is no completed CRM activity. Reset returns to Request received with Succeeds selected.
02Approve a successful sample result
- 01Select Succeeds, then Review proposed action.
- 02Select Approve example. The decision is Approved; there is no delivery confirmation yet.
- 03Select Show sample result. Completed shows an invented completion record and corresponding sample CRM activity. No real message is sent.
- 04Reset clears the decision and result and restores Request received with Succeeds selected.
03Approve a failed sample result
- 01Select Fails. The example restarts at Request received. Select Review proposed action, then Approve example.
- 02Select Show sample result. Execution failed: Action approved; sample execution failed. A fictional provider error appears without delivery confirmation or completed CRM activity.
- 03Reset clears the failure and restores Request received with Succeeds selected.
Engineering and evidence
Decision 01
A decision is not an execution result.
- Choice
- Represent request, pending approval, approval and execution as separate states. Rejection ends its branch; only approval can reach the sample result.
- Consequence
- The visitor can inspect where permission is given and where execution may still fail. A failed outcome cannot inherit a successful CRM record.
Decision 02
Approval depends on the configured action.
- Choice
- Keep this example conceptual until the exact supported action and its autonomy configuration have been checked. State the limitation beside the controls.
- Consequence
- The illustration explains a workflow without promising that every Vora tool asks permission. It also avoids presenting a simulated follow-up as proof of a verified live delivery path.
Decision 03
A product explanation should survive a failed enhancement.
- Choice
- Render the initial request and all three terminal walkthroughs on the server, then load the local interaction separately.
- Consequence
- Readers can follow the decision even without JavaScript or a working interactive module. The native reload link stays available outside that module.
Contribution and credits
I design and build the product, its agent tools, and the business workflows around them.
- I design and build Vora, including the agent tools and their surrounding business workflows. The sample business, customer and conversation on this page are invented.
Current limits
- Approval is configuration-dependent, not universal. Some destructive tools can auto-execute under the autonomy policy. This proposed follow-up remains a conceptual example until its exact supported action is verified.
- Implemented describes the reviewed capability in source. It does not establish that every feature is enabled or that production availability was checked.
- This page does not call a model, contact a provider or write a CRM record. Voice and booking demonstrations require separate configuration checks and evidence.
About this example
This interactive simulation uses purpose-written sample data to explain a proposed human approval boundary. The overview image shows the local portfolio simulation, checked September 12, 2026, rather than a captured Vora product session. All delivery and CRM records are fictional. Approval is configuration-dependent, and the exact supported action remains unverified. No live delivery claim is made for this example.
Checked September 12, 2026
Evidence details
Portfolio simulation screenshot: a fictional Cedar Repair follow-up awaits a decision. Approval depends on configuration; this proposed action remains conceptual and has not been verified as a supported delivery path. No real message is sent.
illustrative