Get started.

Start with one recurring process that still requires too much manual work. Connect only what it needs, agree on the rules and exceptions, then build, verify, and approve a better way to run it.

Modules

What Ronja does for this workspace – and how each module is doing right now.

Running for you · 5

App you work in

Live

Warranty Exception Desk

Dealer warranty cases assembled with bicycle, policy, and service context.

41 fleet quotes prepared

this week

12 min ago

Runs on its own

Live

Warranty Intake

Zendesk cases classified and linked to the correct model and dealer.

1,884 dealer orders processed

this week

4 min ago

Runs on its own

Live

Warranty Credit Reconciliation

Approved dealer credits matched to returned parts and finance records.

214 accounts reconciled

last night

Last night, 02:14

Runs on its own

Needs attention

Service Parts Availability

Replacement batteries and components checked across service hubs.

3 locations checked

daily

This morning, 06:03 – 1 issue

Runs on its own

Live

Weekly Service Brief

Warranty themes and SLA exceptions delivered to service leadership.

32 briefs delivered

since launch

Monday, 06:42

Available to add · 2

Runs on its own

Available

Dealer Service Capacity

Service-part and workshop gaps suggested before queues grow.

App you work in

Available

Warranty Trend Review

Recurring model issues grouped for product and factory review.

ModulesSystems built around your work

Warranty Exception DeskLive
Warranty IntakeLive
Warranty Credit ReconciliationLive
Service Parts AvailabilityNeeds attention

01Starting point
Start with manual work you want to eliminate.
Choose one recurring task with a clear owner and outcome–the manual work people still coordinate across systems, spreadsheets, files, and inboxes. Keep the first build bounded to that job.
Representative completed work landscape showing the systems, files, messages, recurring tasks, and people involved in a familiar manual process before Ronja replaces it.
A representative Norravik dealer-price question starts one path through Salesforce, SAP and the warehouse system before the answer returns to the same thread. A bicycle-range request, a recurring launch brief, a supplier invoice and an allocation exception then bring Anna, Arjun, Sofia and Mikael through the same persistent systems. Finally, a market readiness question crosses media, commerce and dealer data before the answer returns to the original thread.
dealer-operations
SofiaRetail operations09:02
@Anna which launch price applies for Velohaus on Sarek E2–and can Rotterdam deliver this week?
Anna09:07
€2,680 per bike. That is Velohaus’s 2026 launch price, and 64 Sarek E2 bikes are available from Rotterdam.
Email · Outlook09:04
Buying team · Atelier Roue SASReceived
Autumn bicycle range
Please quote 30 × Koster G1 and 20 × Vinga 24 for delivery to Paris by 28 August.
NVQ-3468.pdf
Excel fileProduct mapping.xlsxDealer codes · local rules
Calendar reminderPrepare global launch briefRepeats Monday · 07:45
Excel fileSarek E2 launch pack.xlsxCapacity · stock · dealer demand
Email · OutlookDraft
To Leadership teamDraft
Sarek E2 global launch brief
Factory capacity 87% · launch stock 1,284 bikes · dealer coverage 92%.
Sarek E2 launch brief.pdf
PDF attachedSend
Email · Outlook08:52
Velocast Drive SystemsReceived
Invoice VEL-8426 · €30,750
Battery certification and Sarek E2 test services. VAT 25% included.
VEL-8426.pdf
Excel fileInvoice reconciliation.xlsxCertification · VAT · bank match
Order exceptionRelease dealer allocation4 orders · blocked
Policy documentDealer allocation rules.pdfAllocation policy · v4
Order exceptions
ArjunGlobal supply planning11:14
@Dealer Operations Approve the revised Koster G1 allocation for the four blocked dealer orders?
Sarek E2 launch
AnnaGlobal dealer operations10:02
@Arjun Which markets are ready for the Sarek E2 launch–and where is dealer demand ahead of supply?
Arjun10:30
DACH and Benelux are ready. Singapore dealer demand is 18% above the current launch allocation.
Excel fileSarek E2 market readiness.xlsxLaunch spend · dealer demand · ecommerce
ArjunGlobal supply planningBuilds capacity and allocation answers
AnnaGlobal dealer operationsMatches dealers, prices and availability
SofiaRetail operationsCoordinates stores, ecommerce and launches
MikaelFinance systemsResolves supplier and control exceptions
CRMSalesforceDealers · fleet requests
ERPSAPBicycles · orders · pricing
WarehouseWMSBikes · allocation · receipts
MicrosoftFinance workspaceSupplier finance · reporting
ERPBusiness Central · legacyLegacy regional orders · acquired retail operations
MediaGoogle AdsSpend · campaigns
MediaMetaAd sets · spend
MediaLinkedInCampaigns · leads
MarketingHubSpotLifecycle · programs
AnalyticsGoogle AnalyticsTraffic · conversions
02Files & connections
Connect only what you need.
Drop in a file, or name the system you need. Ronja can turn common data files into tables and research a documented API to build the connection. Credentials stay governed and outside the conversation.
Product-derived Ronja conversation showing API research and a governed credential request after the user asks to connect Norravik’s Zendesk dealer warranty cases.
Connect Norravik dealer warranty cases from Zendesk
Researching the Zendesk API· 5 steps
Searching the webZendesk API OAuth authentication
Reading pagedeveloper.zendesk.com
Reading pageOAuth 2.0 client
Mapping the APItickets, organizations, users, and case comments
Preparing credentialsOAuth client ID and client secret
Credentials requiredZendesk
Add the credentials Ronja needs to finish setting up this connection.
Client IDEnter Client IDClient secretEnter Client SecretShow
Stored securely and kept out of the conversation.Save credentials

03Plan

Agree on the details.

Review the users, data, logic, business rules, exceptions, permissions, and acceptance criteria together. Ronja keeps the plan beside the working conversation so everyone can agree before the build starts.

Rewrite the plan around one bounded first system: connect warranty cases, add product and batch context, then pause before replacement approval.

On it – here is a Norravik plan built around the architecture, with the flowchart as the centerpiece and the human decision boundary stated explicitly.

I've rewritten the PRD around the architecture – it's open in the side panel now. The structure, top to bottom:

The flowchart (the centerpiece) – a horizontal, layer-colored diagram showing all five layers and, crucially, the closed loop: governed sources → automation/workflows → data model → app → decision receipt. Each node is a clickable pill linking to the real resource, and there's a “open full screen” button for filming.
What each layer does – a table mapping each layer to its job in the loop and the Ronja primitive that implements it (managed Postgres, scheduled automation, workflows, derived tables, data app).
The loop in one breath – the sense → decide → act narrative, the line that makes the demo land.
Why two read paths – the live-Postgres vs. cached-data-lake distinction, framed as the “detail that sells it.”

Two notes for the demo framing:

The diagram includes an Automation trigger driving Classify warranty case. The run can be scheduled or started on demand, but the approval boundary remains the same in both paths.
The PRD lives in the session panel only. Want me to save it as a note alongside the README so it persists and is openable later?

EffortHigh

Let's analyse your data..

Planupdated 6/28/2026

Warranty Exception Desk – Plan

A bounded operational system for Norravik: route every warranty case with model, component, batch, dealer, and policy context while keeping consequential replacement decisions with the service team. Governed data flows from the systems of record, through deterministic workflows, into an interactive app that records every proposal and decision. The point is the loop – every layer has a distinct job, and together they form a closed sense → decide → act cycle.

How the layers connect

Flow

thentriggerswrites

New Zendesk warranty case / on-demand review

Warranty Exception Desk

App

Classify warranty case

Workflow

Case and decision history

Zendesk · SAP · Windchill

Governed warranty case model

Model

What each layer does

Layer	Job in the loop	Ronja primitive
Postgres (system of record)	Holds the durable, writable truth – warranty cases, decisions, and status events, plus append-only `decisions` and `status_events` logs	{{mdb-d90nbfgddtds739a7ufg}} managed Postgres
Automation	Triggers the pipeline on a schedule (or on demand) – the “heartbeat”	scheduled automation over the workflows
Workflow	Deterministic work: read the governed inputs, apply the declared constraints, then prepare a reviewable proposal	Classify warranty case run ·Review Warranty Exception Desk review
Data lake	Analytical, auto-rebuilding tables – raw → unified → metrics → recommendations. Each rebuilds when its input changes	warranty_cases , affected_components , warranty_recommendations (+ governed sources)
Data app	The human surface – read live + batch data, and act: drag to change status, click to apply a budget call	Warranty Exception Desk

The loop, in one breath

Sense – Automation fires Classify warranty case; it reads Zendesk · SAP · Windchill and records fresh source state. The derived tables rebuild themselves down the chain.
Decide – The workflow applies deterministic policy and constraints, then attaches an inspectable rationale to each proposed action.
Act – A Norravik owner opens Warranty Exception Desk, reviews the proposal and approves or rejects the consequential change. The decision writes back with its source context and becomes input to the next run. The loop closes.

Why two read paths (the detail that sells it)

The app reads Postgres live for anything a user just changed (the Board's status, the decision logs) so edits show instantly – and reads the data-lake tables for the heavy analytical views (metrics, trends, recommendations), which are cheap, cached, and only move when the batch workflows re-run. Same app, two sources, each chosen for freshness vs. cost.

Status: built and validated. The app is a reviewed draft in the side panel; say the word to publish it live.

04Build & Verify
Build & Verify
Ronja creates the capability and its tables, workflows, agents, and data apps in dependency order. Build status keeps what is being worked on, what is still a draft, and what is already live distinct.
Representative live Norravik Warranty Exception Desk control centre
Warranty Exception Desk – Control centre
Warranty Exception Desk moduleLive
Everything is running as expected
Most recent: 86 warranty cases reviewed this week. Runs when a complete Norravik dealer warranty case arrives in Zendesk.
Warranty cases reviewed
86
this week
People relying on it
7
across the team
Health · last 8 runs
7/8
Last activity
8 min ago
no issues open
Run history
8 min agoCompletedNVC-8264 · Koster G1 derailleur case · replacement approved1m 18s
42 min agoHeld for reviewNVC-8263 · Sarek E2 battery-safety signal · Product Quality notified46s
1h agoCompletedNVC-8262 · Lindholmen brake lever · dealer credit prepared1m 06s
3h agoNeeds evidenceNVC-8261 · Vinga 24 · purchase date missing31s
Schedule
Runs when a complete Norravik dealer warranty case arrives in Zendesk
Health · last 8 runs
05Access & approval
Set access and request approval.
Choose who can use and manage the finished capability, verify that widening access will not break its dependencies, and send the scope change to the right admin for approval.
Mirror-real Warranty Exception Desk scope handover request
Scope change request
Hand over Warranty Exception Desk
Now owned by
Private
Only anna.lindstrom@norravik.com can use it during the first build.
Will be owned by Norravik
The organization
Available to Norravik Dealer Service and Product Quality through current access rules.
1 · What changes for you
You can still use the feature – that doesn't change.
You no longer manage access – the org admin decides who else can see it.
You can propose edits; the org admin reviews them.
3 · Who must accept
An organization admin
Approves handovers into the organization
Self-approval allowed
No dependency conflicts – this scope change is safe to request.
Note for the approver (optional)
You can withdraw this request until the admin accepts it.

01Skills & knowledge

Teach Ronja how your company works.

Knowledge preserves company context, definitions, and relationships. Skills preserve the repeatable procedures Ronja should follow the next time.

Warranty Case & Service Rules

Use when Norravik receives a dealer warranty case, decides whether it can be resolved automatically, or routes a consequential exception to a person.

Created by AI Jun 3, 2026

warrantyservice-policyhuman-review

Norravik operating rules

Scope and ownership

Applies to Zendesk warranty cases for Norravik bicycles sold through owned stores and independent dealers.
Dealer Operations owns partner communication; Product Quality owns recurring model issues.
Finance approves dealer credits above EUR 2,500.

Automatic resolution boundary

Approve a standard replacement part when the bicycle, purchase date, serial number, and dealer are verified.
Never auto-approve a battery-safety, frame-integrity, or repeat-failure case.
Route any case with missing ownership evidence back to the dealer for completion.

Service-level rules

Acknowledge complete dealer cases within four business hours.
Measure resolution from the first complete case to the recorded remedy.
Pause the SLA only while required evidence is missing and keep that pause visible.

Required sources and receipt

Read Zendesk, Salesforce dealer records, SAP bicycle and serial data, Windchill model revisions, and service-parts stock.
Record model, serial, dealer, policy version, remedy, approver, and every external message.
Group repeat issues by model family and factory for Product Quality review.

Organization Knowledge

Context: Nine company memos
Rules: Business-specific and reviewable
Teaching: Conversation updates the knowledge

02Governed metrics

Define KPIs once. Reuse them across answers and apps.

Give each KPI a governed definition, calculation, source lineage, owner, and verification state–then use the same meaning in conversational analytics and interactive data apps.

Explore Business Intelligence

/Warranty Exception Desk/Warranty cases resolved within SLA

Warranty cases resolved within SLAVerified

Metric owner·anna.lindstrom@norravik.com– ask them if it breaks

Warranty cases resolved within SLA · Trend

The share of complete Norravik dealer warranty cases with a recorded remedy within three business days.

Updated 18 min ago

Grain

Break down by

How it’s really calculated

The full definition, resolved down to source data

3 source tables

Logic · Auto-generated

FilterKeep complete dealer warranty cases with a recorded remedy

TransformCount Norravik business time from evidence_complete_at to resolved_at

GroupShare resolved within three business days by bicycle family

Built from

Input table

Verified

The endorsed definition is unchanged since it was verified.

priya.nair@norravik.comVerified · Aug 6

Governance · admin only

Authors can request verification; only an admin certifies. You have admin rights here.

History

priya.nair@norravik.comverified metricAug 6

anna.lindstrom@norravik.comupdated complete-case start ruleAug 4

anna.lindstrom@norravik.com agentcreatedJul 28

Read-mostly by design

There’s no inline SQL editing here. Changing an official number is a governed act – Refine in exploration routes it through the build & review flow.

Warranty cases resolved within SLA

Metric: Verified definition, owner, and lineage
Ask: Conversational answers use the same meaning
Build: Interactive data apps reuse the KPI

03Bridges

Work with Ronja in Slack or Microsoft Teams.

Bring selected Ronja work into the channels your team already uses. Ask, review, and continue the work there while the Ronja app remains the system of record. Microsoft Teams is in Beta.

SService & Warranty

01 · Your existing foundation
Your CRM, ERP, files, and inboxes already hold the pieces of how your business runs. They are the stable foundation your teams rely on every day.
02 · The Ronja layer
Ronja connects the work across them. It turns their data, rules, and relationships into a shared model of your business–so you can build AI-native functionality that fits how your company actually operates.

Your next step

Choose how to build the first system.

Both paths use the same platform and produce the same customer-owned result. The choice is simply who drives the first build.

Talk to us Start building

Get started.

Modules

From manual work to approved system.

Start with manual work you want to eliminate.

Connect only what you need.

Agree on the details.

Build & Verify

Set access and request approval.

Features

Make Ronja part of how your company works.

Teach Ronja how your company works.

Warranty Case & Service Rules

Norravik operating rules

Scope and ownership

Automatic resolution boundary

Service-level rules

Required sources and receipt

Define KPIs once. Reuse them across answers and apps.

Work with Ronja in Slack or Microsoft Teams.

Building the system was never the hard part.

Choose how to build the first system.

Modules

Features

Get started.

From manual work to approved system.

Start with manual work you want to eliminate.

Connect only what you need.

Agree on the details.

Build & Verify

Set access and request approval.

Make Ronja part of how your company works.

Teach Ronja how your company works.

Define KPIs once. Reuse them across answers and apps.

Work with Ronja in Slack or Microsoft Teams.

Choose how to build the first system.

Modules

1 · What changes for you

3 · Who must accept