Implementation, Onboarding & Support Guide

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.

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.

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.

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.

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.

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.

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.

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.

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.

If an issue is not moving, escalation is explicit rather than implicit:

1. 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.
2. 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.
3. 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.
4. 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.

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.

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.