Delivery
Implementation, Onboarding & Support Guide
How a Kavanah workspace is deployed, configured, and rolled out — the implementation phases, the onboarding timeline, data migration, training, the support model, and who is responsible for what.
Last updated: July 28, 2026
This document is written for the three questions a procurement or IT review asks about delivery: how does the product get deployed, how do our people get onboarded, and what happens when something breaks. It covers all three — implementation, onboarding, and the support model — in one place, so it can be attached to an RFP response without assembling a pack.
1. Deployment approach
Kavanah is delivered as multi-tenant SaaS. It runs on serverless infrastructure (Vercel) with a managed Neon Postgres database, and production data is processed in the United States. There is nothing to install or host: no servers to provision, no capacity planning, no database to operate, and no software to keep patched.
Because access is ordinary outbound HTTPS to the production domain, implementation requires no infrastructure or firewall changes, no VPN tunnel, and no agent or collector installed on employee machines. A workspace is provisioned immediately — implementation is configuration, not construction.
Clients
The web application is the primary client. Optional desktop apps (macOS, Windows, Linux) and mobile apps (iOS, Android) are installed per user from the standard app channels. All three shells are built from one codebase and load the deployed application, so there is no separate client version to manage, distribute, or keep in step with the server.
What we do not offer
There is no on-premise, self-hosted, or single-tenant deployment option today, and we would rather say so at the start of an evaluation than at the end of one. If your policy requires software to run inside your own estate, Kavanah is not currently a fit. If the underlying requirement is isolation, auditability, or data residency, the controls that address it are described in the Security Overview and the Architecture Overview.
2. Implementation phases
A standard implementation runs in seven phases. They overlap in practice — identity work usually proceeds in parallel with data import — but each has a clear owner on both sides.
| Phase | Activities | Customer does | Kavanah does | Typical duration |
|---|---|---|---|---|
| 1. Workspace & branding | Workspace provisioned; name and workspace URL; logo, brand colors, and support email; time zone, business hours, and working conventions | Supplies brand assets and workspace conventions | Provisions the workspace and applies branding | Day 0 |
| 2. Identity | SSO via SAML 2.0 or OIDC; SCIM directory sync for provisioning and deprovisioning; TOTP MFA policy; OAuth sign-in (Google, GitHub) if used; invite policy and the invite-approval queue | Configures the IdP application; decides the MFA policy and whether invites require approval | Supplies metadata and the SCIM endpoint and token; tests the flows with you end to end | Day 0 – Week 1 |
| 3. Roles, permissions & access control | Owner / admin / member / client-portal roles; granular permission scopes; per-project and per-task access control; client portals for external stakeholders | Defines who should be able to see and change what | Maps that model onto roles, scopes, and project/task access rules, and reviews the result with you | Week 1 |
| 4. Data import & integrations | Import existing work; connect Google Workspace, Microsoft 365 / Outlook, ProtonMail, iCloud, Notion, ClickUp, Jira, Monday, ClearBooks, and GitHub; Google Sheets sync for pipeline data | Authorizes each connector with an account that has the right scope; confirms the field mapping | Runs the import, validates the mapping, and confirms sync behavior before the team relies on it | Week 1 |
| 5. AI Employees | Create personas; write their instructions; choose the model; set capability scopes and member access; choose the autonomy posture — safe mode, which actions are parked for approval, and what may run automatically | Decides which roles to automate, who may use each persona, and how much autonomy to grant | Configures personas and scopes, and walks the team through the action ledger, the approval queue, and undo | Week 2 |
| 6. Automations, intake & notifications | Event- and time-based automations; request-intake forms; scheduled reports; notification channels, quiet hours, and escalation preferences | Supplies the rules, the intake routing, and the notification preferences | Builds the first automations and intake forms alongside the team so they can maintain them | Week 2 – Week 3 |
| 7. Go-live & review | The full pilot team working in Kavanah day to day; open issues closed out; joint review against the criteria agreed at kick-off | Runs real work in the workspace and attends the review | Monitors the rollout, resolves issues, and runs the review | Week 4 |
3. Onboarding timeline
The phases above land on a four-week rollout for a typical team. This is the same shape we present commercially, stated here as a planning aid rather than a promise.
| When | Milestone | What happens |
|---|---|---|
| Day 0 | Workspace stood up | Workspace provisioned and branded, owner and admin accounts created, and an existing project imported as the starting backlog. |
| Week 1 | Team on, integrations wired | Members invited with roles, SSO and SCIM in place where used, access model applied, mail / calendar / repository connectors authorized, and the first client portal stood up. |
| Week 2 | AI Employees configured | Personas scoped to your roles, capability scopes and autonomy posture set, and the first recurring report drafted by the agent for a human to review. |
| Week 4 | Review | Joint review against the criteria agreed at kick-off. Expand, hold, or stop — your data exports cleanly either way. |
Week 3 is deliberately unscheduled: it is steady-state use, where the team works normally and we tune what the first two weeks surfaced. If you are running this as a time-boxed evaluation, the Proof of Concept & Pilot Program describes the same window with the evaluation criteria attached.
4. Data migration
Most of what a team needs to bring across arrives through the supported integrations. Anything they do not cover is handled through the REST API, which is the general-purpose path in and out of Kavanah.
| Source | Path in |
|---|---|
| ClickUp, Jira, Monday, Notion | Native integrations. Connect with customer-authorized OAuth or a scoped API key and bring work items across; the connection is revocable at any time from workspace settings. |
| Google Sheets | Sheet sync for pipeline data (Deal Room and Accounts), so a spreadsheet a team already lives in stays in step with the workspace. |
| Google Workspace / Microsoft 365 | Mail, calendar, and document connectors — not a bulk migration, but the reason most teams stop copying context between tools. |
| CSV or spreadsheet exports from any other tool | Loaded through the REST API. |
| Anything else | The REST API. Bespoke migrations are scoped with you before they start. |
The API path
Kavanah publishes an OpenAPI 3.1 specification covering 500+ endpoints. The machine-readable spec is at /openapi.yaml and the human reference is in the documentation. Migration scripts authenticate with a workspace API key prefixed kvn_live_, which inherits the permissions of the user who minted it — a migration cannot reach anything its author could not reach in the UI.
Bespoke migrations
Where a customer needs more than the connectors and the API provide, we scope the work with you in advance: what is in scope, what it costs, and how long it takes are agreed in writing rather than assumed from this page. We do not publish a guaranteed migration timeline, because the honest answer depends entirely on the shape of the source data.
The same API is the export path. Data movement is symmetric by design — see exit and export and the Data Processing Addendum.
5. Training & enablement
Enablement material ships with the product rather than arriving as a slide deck that goes stale.
- In-app documentation. The full product documentation lives at /docs and is available to every user inside the app, including a complete API reference.
- Admin guide. A separate track for workspace owners and administrators covering roles and permissions, identity, integrations, automations, and the AI governance controls.
- Built-in project-management course. A structured course inside the product for teams whose delivery practice is being formalized alongside the tooling, not just teams learning the buttons.
- Knowledge base. Task-oriented articles for the questions that come up after week one.
- The agent's product-knowledge tool. The AI agent knows the application's own navigation and feature set. A user can ask, in plain language, where something is or how to do it, and be guided to the exact surface — which in practice absorbs most of the questions that would otherwise become a support ticket or a training session.
- Live sessions. Sessions for administrators and for end users are available on request. The number and format of sessions included with your subscription are set out in your order form.
6. Support model
Channels
Support is available by email at support@kavanah.ai and from inside the application. Suspected security issues should go to security@kavanah.ai instead, which is monitored as a disclosure channel.
Severity definitions and response targets
These are the targets published in our Service Level Agreement, reproduced here so this guide stands on its own. They are first-response targets, measured in business hours and business days, not resolution times.
| Severity | Definition | Target first response |
|---|---|---|
| S1 — Critical | Production down or a security incident affecting availability or data | 4 business hours |
| S2 — High | Major feature impaired, no reasonable workaround | 1 business day |
| S3 — Normal | Minor or partial impairment with a workaround | 2 business days |
| S4 — Low | Question, feature request, or documentation issue | 3 business days |
The SLA is the governing document for support commitments, alongside the uptime target and service-credit remedy. As with everything on this page, the version that binds is the one incorporated into your executed agreement.
7. Escalation path
If an issue is not moving, escalation is explicit rather than implicit:
- Raise it. Email support@kavanah.ai or use in-app support. The issue is triaged to a severity and acknowledged within the target for that severity.
- Ask for escalation. Reply on the thread asking for it, or send a new message with “Escalation” in the subject. It is routed to the engineering lead responsible for that area, and you are told who owns it.
- Sponsor-level review. If severity or impact still does not match the response, your executive sponsor and ours review it directly. Kavanah is a small, founder-led team; the distance between a customer and the people who write the code is short by construction.
- Availability incidents. S1 issues affecting the platform are handled as incidents, with status communicated until resolution and a follow-up afterwards. Our resilience and recovery posture is described under Business Continuity.
Escalation is a process commitment, not a contractual one. The binding commitments — response times, uptime, remedies, and any negotiated support terms — are those set out in your executed order form or master agreement.
8. Ongoing customer success
Reviews
After go-live we hold recurring reviews at a cadence agreed with you: what is working, what is not being used, what should be automated next, and what is coming. These are working sessions, not status calls.
Adoption reporting
Workspace administrators have adoption and usage reporting inside the product — who is active, where work is happening, and how the workspace is trending — so the question “is this actually being used?” is answered from your own data rather than from a vendor's assertion. We do not publish other customers' adoption figures, and we will not quote them at you.
Feature requests and the changelog
Feature requests go through the same support channels and are logged against your account. Shipped changes are published in the changelog. Prioritization of any individual request is not a commitment unless it is written into your agreement.
Upgrades
Kavanah is continuously deployed. There are no version negotiations, no upgrade projects, and no end-of-life migrations to plan for. Because the desktop and mobile shells load the deployed application rather than bundling their own copy of it, every platform updates at the same moment — web, macOS, Windows, Linux, iOS, and Android — with no client patching and no fleet-wide rollout for your IT team to coordinate. Scheduled maintenance, where it is needed at all, is announced in advance under the SLA.
9. Responsibilities matrix
A RACI-style summary of who owns what. Where an activity is shared, the decision sits with the customer and the execution sits with Kavanah.
| Activity | Customer | Kavanah |
|---|---|---|
| Hosting, scaling, patching, and monitoring the platform | — | Owns |
| Workspace provisioning and branding | Supplies brand assets and conventions | Executes |
| Identity provider configuration (SAML 2.0 / OIDC / SCIM) | Owns the IdP side | Supplies metadata and endpoints; tests jointly |
| MFA policy, invite policy, and the invite-approval queue | Owns the decision | Advises and configures |
| Role, permission, and project/task access design | Owns the access model | Implements and reviews it with you |
| User lifecycle (joiners, movers, leavers) | Owns — directly or via SCIM | Provides SCIM sync and deprovisioning |
| Accuracy and lawfulness of data placed in the workspace | Owns as data controller | Processes it under the DPA |
| Authorizing and revoking integration connections | Owns | Maintains the connectors and honors revocation |
| AI Employee instructions, capability scopes, and autonomy posture | Owns the decision | Configures them and explains the controls |
| Reviewing AI actions parked for approval | Owns | Provides the policy engine, the action ledger, and undo |
| Data import and migration | Supplies the source data and confirms the mapping | Runs the import; scopes bespoke work in writing |
| User training and internal communications | Owns the rollout | Supplies docs, the course, the knowledge base, and live sessions on request |
| Raising and triaging support issues | Reports issues with reproduction detail | Triages, responds to the SLA targets, and resolves |
| Incident response and platform security | — | Owns |
| Backups, restore drills, and continuity | — | Owns |
| Data export and deletion at exit | Initiates the request | Provides API export and deletes on request |
| Seat management and billing | Owns | Provides usage visibility and invoices |
Plan your implementation
We will walk through this guide against your environment — your identity provider, the tools you are moving off, the access model you need, and the AI governance posture your risk team expects — and give you a plan with named owners on both sides before anything is signed.
For a time-boxed evaluation, see the Proof of Concept & Pilot Program. For the security review that runs alongside it, start at Trust & Compliance or send us your questionnaire via the RFI response.
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.