VoraMake the client service and its owners clear.
Vora is for agencies delivering AI services to clients. Start by defining the service the agency will run, what the client must approve and who takes over when the workflow cannot finish.
A platform evaluation and a client delivery agreement answer different questions. Use the platform guide to review the selected setup, and this page to assign the work around it.
Give each responsibility a named owner
| Responsibility | Agency contribution | Client contribution |
|---|---|---|
| Service scope | Describe supported requests, outputs and limits | Approve the business result and exclusions |
| Business knowledge | Prepare and test the source set | Approve the applicable policy and maintain its owner |
| Connections | Document requirements and test the intended action | Authorize the correct account and destination |
| Acceptance | Run agreed cases and record observed results | Check that staff can use the saved output |
| Exceptions | Investigate within the agreed support scope | Provide a receiving person and business decision owner |
| Changes | Estimate implementation, testing and recurring effort | Approve the change in scope, price or timing |
One person may hold several roles in a small business. Write their responsibilities separately so an unanswered policy question does not disappear into a technical support queue.
Separate agency, client and provider duties
| Duty | Agency | Client | External provider |
|---|---|---|---|
| Source of truth for answers | Prepares and tests the source set | Approves the policy and owns updates | Not applicable |
| Accounts and credentials | Documents what is required and where references are kept | Owns or authorizes the account | Operates its own service and terms |
| Saved result | Verifies the record in the agreed destination | Confirms staff can open and use it | Hosts the destination system |
| Charges | Quotes its own setup and service fees | Approves scope and recurring terms | Bills its own usage |
| Exit | Lists transferable assets and revokes its access | Decides what is retained | Controls its own account closure |
Use the requirements matrix to record each duty and the evidence reference beside it. The platform guide reviews the selected setup; this page assigns who does the surrounding work.
Decide who may see and change each client's work
List the agency and client roles, the records each may inspect and the actions each may take. Include users who must be denied access.
Check the intended client scope in controlled tests before inviting ordinary users. A successful sign-in does not by itself establish that the person has the right client permissions.
Record who owns provider accounts and recovery contacts. Keep credentials in the chosen application's supported secure storage, with references in the handover rather than secret values.
Confirm the actual client-access and branding options for the configuration under review. This guide does not promise a plan entitlement or a particular white-label arrangement.
Start with a service small enough to support
A hypothetical agency might begin with after-hours callback requests for one location. The service ends when the final details reach reception and an incomplete request has a responsible owner.
Decide support hours, how staff report a problem and what fallback operates while the agency is unavailable. Define acceptance using the record staff need, including corrections and failed writes.
Use the first-client evaluation guide to choose a bounded deliverable. When the buying decision needs more evidence, define a paid pilot with a review date and proposed recurring terms.
Check fit before you take on a client
A good fit: a client with one workflow, an approver who can answer policy questions and staff who will receive the result.
Not a fit yet: a client who wants unlimited scope under a fixed fee, cannot name a source owner or expects the agency to carry duties that belong to the client or a provider. Whether Vora supports multiple clients, client-scoped access or white-label arrangements is not stated here; confirm it in the evaluation for your configuration.
Make recurring work visible in the agreement
Separate routine information updates, defects and new behavior. A correction needed to meet the accepted scope is different from a request to add rescheduling.
Track support and review time alongside usage. Keep the agency's setup and service fees distinct from platform, usage and provider costs. The service-cost guide includes labelled arithmetic; its figures are not Vora tariffs or recommended rates.
Use a change record before a new request becomes a permanent obligation inside the original fee.
Plan the handover and eventual exit
Give staff an operating note: what arrives, where they inspect it, who handles unresolved work and when to escalate. Ask the receiving person to use a controlled example.
Agree which assets, accounts, records and pending jobs transfer if the service ends. The offboarding guide distinguishes provider revocation, local credential removal, retained data and continuing charges.
Prepare the first client discussion
Bring the workflow, source owner, receiving staff role, required connections and proposed support boundary. Identify the buyer who can approve scope and acceptance.
Join the waitlist to register interest in Vora. An invitation and product access are separate from joining.