Evaluation
Proof of Concept & Pilot Program
How a time-boxed Kavanah evaluation runs — the 30-day structure, how success criteria are set, what each side provides, and what happens to your data if you decide not to proceed.
Last updated: July 28, 2026
Most software evaluations fail for the same reason: nobody wrote down what would count as success before the trial started, so at the end there is nothing to measure against and the decision gets made on atmosphere. This document describes how a Kavanah pilot avoids that — what it covers, how long it takes, who does what, and how it ends in either direction.
1. What a POC is — and is not
What it is
- A time-boxed evaluation — typically 30 days — run on real work, by a real team, in a real workspace.
- An exercise measured against criteria you define before it starts and both sides agree at kick-off.
- A hands-on implementation, following the same phases as a full rollout — see the Implementation, Onboarding & Support Guide.
- Reversible. If you do not proceed, your data exports cleanly and is deleted on request.
What it is not
- Not a sandbox demo. A pilot run on invented data proves nothing about whether the tool fits how your team actually works.
- Not a free tier. Kavanah has a free Starter edition, and it is a perfectly reasonable way to look around; it is not the same thing as a supported pilot. See the pricing sheet.
- Not a custom build. Bespoke development, unsupported integrations, and large migrations are out of scope by default and scoped separately in writing if you need them.
- Not a substitute for security review. The security and procurement review should run in parallel, not after — see section 7.
2. A typical 30-day structure
This is the same four-week shape as a standard onboarding, with the evaluation criteria attached at the front and a decision at the back.
| When | Focus | What happens |
|---|---|---|
| Kick-off (Day 0) | Scope and success criteria agreed | Executive sponsor and pilot lead named, participants identified, one or two real projects chosen, and the success criteria written down. The workspace is provisioned and branded the same day, with an existing project imported as the starting backlog. |
| Week 1 | Team on, integrations wired | Members invited with roles, the access model applied, SSO and SCIM configured where used, and the connectors the team depends on authorized — mail, calendar, repositories, and any project tool being migrated from. First client portal stood up if external stakeholders are in scope. |
| Week 2 | AI Employees configured | Personas created and scoped to your roles, capability scopes and autonomy posture set, approvals and the action ledger walked through with the admins, and the first recurring report drafted by the agent for a human to review. |
| Week 3 | Daily use | Steady state. The pilot team runs its real work in Kavanah — no parallel system, no shadow spreadsheet — and we tune what the first two weeks surfaced. |
| Week 4 | Review against the agreed criteria | Joint review with the sponsor, measured against the criteria set at kick-off. Decide to expand, extend the pilot, or stop. Your data exports cleanly either way. |
3. Defining success criteria
Criteria are set by you, written down at kick-off, and reviewed at the end. We will help you make them measurable, and we will tell you if we think one is unrealistic, but we do not set them and we do not grade our own homework.
The examples below are illustrations of the kinds of criteria teams choose. They are prompts for your own list, not outcomes we are claiming.
| Kind of criterion | Example of how a team might phrase it |
|---|---|
| Adoption | An agreed proportion of the pilot team is working in Kavanah daily by a date the team picks, with no parallel tracker still in use. |
| Consolidation | One named workflow — request intake, sprint planning, client status — has moved off its existing tool entirely and stayed there. |
| Time on a recurring report | A status report that is currently assembled by hand is produced by the agent and accepted by its audience without rework, and the team records how long the manual version used to take so it has its own baseline. |
| AI governance | Every action an AI Employee took during the pilot is visible in the action ledger, and every action classified as risky was approved by a named human before it ran. |
| Client experience | External stakeholders on a chosen project are using a client portal instead of email threads, and say they prefer it. |
| Integration fit | The connectors the team depends on stayed connected and in sync for the full window, with no manual re-entry. |
4. Scope boundaries
- One or two real projects. Enough to be representative, few enough to stay observable. Not the whole portfolio.
- A defined team.A named participant list — usually one delivery team plus the administrators — rather than an open invitation to the organization.
- Real data. Live work, live clients, live deadlines. We would rather you pilot on something that matters than on a copy of something that does not.
- A fixed window. Thirty days is typical. It is long enough to reach steady state and short enough that the decision does not drift.
- Your production workspace. The pilot runs in the workspace you would keep. If you proceed, nothing is re-implemented — the configuration, the imported work, and the history carry straight over.
- Out of scope by default: custom development, integrations to systems we do not support, migrations beyond what the connectors and the REST API cover, and on-premise or single-tenant deployment — which we do not offer at all. Anything in the first three can be scoped separately in writing.
5. What Kavanah provides
- A workspace, provisioned and branded on day zero. Nothing to install or host; no infrastructure or firewall changes.
- Hands-on configuration through every implementation phase — identity, roles and access control, data import, integrations, AI Employees, automations and intake — as set out in the Implementation Guide.
- Full product capability for the pilot team, including AI Employees, with an AI-credit allowance set out in the pilot terms. Anything that runs automatically or spends credits stays opt-in and off until you turn it on.
- The enablement material — in-app documentation, the admin guide, the built-in project-management course, and the knowledge base — plus live sessions for administrators and end users on request.
- Support by email at support@kavanah.ai and in-app, at the severity targets published in the SLA, and a direct line to the team building the product for the duration of the pilot.
- The security and compliance documentation your reviewers need, so that review can run in parallel rather than after.
6. What the customer provides
| Role or input | Why it matters |
|---|---|
| Executive sponsor | Owns the decision at the end of the window and can unblock internal dependencies during it. Pilots without a sponsor tend to end without a decision. |
| Pilot lead | Day-to-day owner and single point of contact. Runs the kick-off, chases the participants, and co-runs the Week 4 review. |
| Participants | A named team who will genuinely use the workspace for their real work, not a rotating set of observers. |
| Success criteria | Written down before Week 1 and agreed by both sides. This is the single input that most determines whether the pilot produces a decision. |
| Access decisions and IdP configuration | Who should see what; the SAML 2.0 / OIDC application and SCIM connection on your side, if you are using them. |
| Connector authorization | An account with the right scope to authorize each integration you want live during the pilot. |
| Time | The kick-off, the Week 4 review, and enough of the team's week to reach steady state rather than dabbling. |
7. Security review in parallel
Run the security and procurement review alongside the pilot, not after it. Serializing them is the most common way a successful evaluation still takes six months to close. Everything a reviewer normally asks for first is already published:
- Trust & Compliance — the index, and the request path for artifacts shared under NDA.
- Security Overview — encryption, authentication, tenant isolation, audit logging, and the secure-development program.
- RFI response — pre-answered vendor-questionnaire content, so your reviewers are not waiting on us for the first eighty questions.
- Architecture Overview and Business Continuity — how it is built and how it recovers.
- Data Processing Addendum and SLA — the paper your legal team will want during, not after, the pilot.
8. Commercial terms and conversion
During the pilot
A pilot is a 30-day paid pilot: one workspace, the full pilot team, a single flat fee, and no per-seat metering during the window. It is month-to-month with no annual lock-in — annual terms only apply if you later choose them.
If you proceed
The pilot converts to a standard subscription on the published editions. The workspace carries over as it stands; there is no second implementation.
| Edition | Price | Notes |
|---|---|---|
| Starter | Free | 5 members, 10 projects, 2 GB storage, 250 AI credits at signup |
| Basic | $3 per seat / month ($2 billed yearly) | Unlimited seats |
| Pro | $6 per seat / month ($4 billed yearly) | Unlimited seats |
| Enterprise | Custom | Negotiated terms, including any SLA and support commitments |
AI credits beyond the allowance included with your edition are purchased separately. Full detail, including what is included at each tier, is on the pricing sheet. As always, the binding commercial terms are those in the executed order form or master agreement.
9. Exit — if you do not proceed
A pilot you cannot walk away from is not a pilot. If the criteria are not met, or the team simply decides against it, the engagement ends at the end of the window with no obligation to continue.
- Export via the REST API. The full OpenAPI 3.1 API — 500+ endpoints, spec at /openapi.yaml — covers tasks, projects, clients, time entries, threads, and the rest of your workspace content in JSON. It is available for the whole pilot, not just at the end, so you are never dependent on us to get your data back.
- Data-subject export. Workspace owners can also run GDPR/CCPA-style export of an individual's data from Settings → Data Governance.
- Deletion on request. Once you have what you need, the workspace and its data are deleted on written request. Retention, deletion, and sub-processor terms are set out in the Data Processing Addendum.
- Integrations revoked. Every connector is a customer-authorized OAuth grant or scoped API key and can be revoked from workspace settings at any time, independently of anything we do.
Start a pilot
Tell us what you would need to see in 30 days to justify moving your team, and we will tell you honestly whether a pilot can demonstrate it — and what it would take to run one.
For the delivery detail behind the timeline above, see the Implementation, Onboarding & Support Guide. For the security review that should run alongside it, start at Trust & Compliance.
Questions from a security, privacy, or procurement team? Email security@kavanah.ai. For SOC 2, penetration-test, or questionnaire artifacts shared under NDA, use the request forms on the Trust & Compliance page.