Qonto × Forest Admin: Back-Office Usage Analysis

Date: 2026-04-30 Purpose: Data-driven view of how Qonto uses Forest Admin as their back-office app, derived from Rulebase’s synced Zendesk + KB data, in service of designing the three Forest×Rulebase integration use cases (QA ground-truthing, proactive workflows, dispute timeline verification).

Source data: EU Metabase, organization_id = 33 (Qonto, FR).

1. Top-line scale

Read: Forest activity is invisible in customer-facing fields (subjects, summaries) because agents do the work inside Forest. But it surfaces strongly in two places we already sync: (1) Qonto’s Zendesk Help Center SOPs, synced to Rulebase KB, and (2) internal notes / macros agents leave on tickets as they work — explicitly referencing Forest fields, Forest “smart actions”, Forest screenshots, and Forest org IDs. Section 3 below uses the notes as the load-bearing evidence.

2. How Qonto uses Forest — workflow taxonomy

The 67 “Forest”-titled KB articles cluster into six clear workflow families. Multilingual coverage (FR / EN / DE / IT / ES / PT / NL) confirms Forest is the pan-European single back-office for Qonto CS — every front-line agent across markets uses it.

2a. Status lookups (read-only) — the bread and butter

These are the highest-volume, lowest-complexity Forest interactions. An agent reads a ticket, hops into Forest to read a status, copies it back. This family is the primary target for QA ground-truthing (use case 1): the right answer to the customer depends on what Forest says, and today Rulebase QA can’t see it.

Significance: every one of these has dedicated FR/DE/IT/ES/PT/NL versions, meaning each is consulted often enough across each market to justify localization. Conservative take: top-3 status SOPs (card, transfer, direct-debit) are each viewed thousands of times per month per language.

2b. Account / customer 360 lookups

2c. Action / write workflows — the proactive-workflow target

These are the highest-leverage use case 2 opportunities (Rulebase triggers a pre-filled Forest action when CS surfaces fraud / disputes / refund-eligible cases).

2d. KYC / Compliance — high-stakes, regulator-facing

These workflows are slow, error-prone, and audit-relevant. They are the most defensible Rulebase wedge — getting them wrong is expensive (regulatory fines, customer churn, BL escalations).

2e. Forest workspace operations / training

2f. FL / BL split

The recurring [FL] (front line) / [BL] (back line) prefix on KB titles is itself a finding: Qonto operates a tiered support model where front-line agents resolve in Forest where they can and escalate to back line for harder Forest workflows. Many KYC/UBO articles have FL+BL versions. This affects integration design — the Forest MCP needs to surface what an FL agent can do vs. what triggers a BL handoff.

3. Internal-notes evidence — what agents actually do in Forest

Internal notes are where Forest activity surfaces in our synced data. Agents either (a) consult Forest and leave a note summarizing what they found, or (b) request a Forest write action via Slack/BL and document the inputs in a structured macro. We see eight recurring macro patterns. All examples below are real, latest-week (2026-04-30) Qonto notes; Org IDs are Qonto’s Forest customer external IDs (UUID v7 format).

3a. reKYC routing macro — the highest-volume Forest signal

The single most common Forest-tagged note is this macro (seen ~14× in the most recent 25 Forest-mentioning notes alone):

“ATTENTION ! Ce ticket a été redirigé à l’équipe KYC/B Update car le client doit procéder à sa revue périodique reKYC. Ces clients ont le champ Forest ‘currently undergoing reKYC = ✅’”

Workflow: an FL agent opens a ticket, checks the customer’s Forest record, sees currently_undergoing_reKYC = true, and routes the ticket to the KYC/B Update team. This is a perfect Rulebase trigger for use case 2 — if Forest MCP exposes this boolean, Rulebase can auto-route at ingestion (without an agent ever touching the ticket).

3b. Voucher / refund request macro (commercial gesture)

Real example, ticket org 018ebf1a-bd4b-74ba-b68b-74526f529745:

“VOUCHER REQUEST: ⚠️ CONSULTEZ LA PROCÉDURE ZD AVANT DE FAIRE LA DEMANDE SLACK ET SAISIE FOREST … ID ORG: 018ebf1a-…f529745 / Reason /context: compte en sommeil / Period of inactivity: du 22/01/2026 au 30/04/2026 / WF: 00 / Contract signed at: 08/04/2024 / KYB accepted: 25/04/2024 / DÉTAILLEZ VOTRE PROPOSITION DE GESTE OU DE REMBOURSEMENT … 13.20+24+13.20+13.20+24+24 = 111.6 euros 50%= 55.8 euros”

Workflow: agent computes refund based on contract date + inactivity period, fires a Slack request to BL, BL types it into Forest. This is the most automatable workflow on the page — every input above is structured. Maps to KB article 25235187797649.

3c. Org closure macro with Forest CS-note check

Real example, ticket org 019db3d4-24c0-7502-8d77-c080a951f4ec (and many more):

“Id orga: 019db3d4-…a951f4ec / Raison de la clôture (disponible sur Forest): clôture car doublon rejeté par PEP/SL et orga banned depuis hier/Mail auto / Fraude ❌ Non / OVP HRC ❌ Non / PEP refused (vérifier la CS note a-t-elle été laissée sur le membership par FS) ✅ Oui / Capture d’écran de la Closing account request sur Forest:”

Workflow: Forest holds the closure reason, fraud flag, OVP HRC flag, PEP-refused state, and a “CS note on membership”. The agent reads several Forest fields and pastes a screenshot. Rulebase QA today cannot verify any of this — perfect ground-truthing target.

3d. Pre-authorization release (card hold release)

Real example, ticket org f5cdb143-4b5a-411f-8771-cd14e79ed5e9:

“Le pre_authorized est égale ou supérieure à 1000 € ? oui / Le pre_authorized est en ‘Pending’ sur Forest Transaction ? oui / La smart action ‘reverse no clearing’ a t’elle été effectuée sur Forest ? oui / Payment id from API / card movement from CBS: 019dbec3-650e-7e47-83b9-038b8850f0ad / Card Token: PAN_AGNVWLJ7YBZPHCGHTETM4QSJUA / Numéro dossier sur le ticket de clôture: 260424001004 / Date de la Pre-authorization: 24/04/2026”

Workflow: confirms a sequence of Forest fields and a Forest smart action (“reverse no clearing”). Note the explicit term “smart action” — Forest has named, parameterized actions Qonto already exposes, which strengthens the case for an action-pre-fill MCP for use case 2.

3e. Capital deposit / KYB onboarding states

Real examples:

• Org 019d69b2-efdc-7aa3-b43e-a723699cf6ae: “Deposit capital status Forest: deposit_certificate-sent”
• Org 019d5e90-b280-7454-818a-8bbb1c4bcc5b: “Deposit capital status Forest: Notary name: kbis_submitted”

These are explicit Forest state-machine values for the capital deposit flow (deposit_certificate-sent, kbis_submitted). For QA grounding, Rulebase needs to read the live state to evaluate whether the agent’s reply matched reality.

3f. Referral fraud check + voucher (parrainage)

Real example referencing Zendesk ticket 5402295 (external_id) with referrer org 019c94fd-5a11-7935-b7a4-85080720da3e and referee org 019d389e-edaa-7a04-bef3-8ef7538a928a:

“REFERRAL / PARRAINAGE 👋 / Bonus amount: 100 / SCREENSHOT FOREST: [image links] / Marché FR 🇫🇷 SUSPICION ABUS PARRAINAGE: NON / FL: IL EST OBLIGATOIRE DE S’ASSURER QU’IL NE S’AGIT PAS D’UN ABUS AVANT DE FAIRE UNE DEMANDE DE VOUCHER À BL”

Workflow: FL agent screenshots Forest to prove the referral relationship is legitimate, then requests BL to issue the voucher. Rulebase could read the referral relationship from Forest directly + flag suspected abuse based on Forest data.

3g. Onboarding KYC document review

Real example: “OB: Dépôt de capital / En attente de documents/réponse du client / KYC ❌: verso du TDS manquant pour HAMAM Ghiles et Doc invalide pour BENYAHIA Samir / BYLAWS ✅ / ⚠ Pensez bien à vérifier les documents sur Forest avant de reprendre le ticket”

The “vérifier les documents sur Forest” instruction is the literal QA grounding need — current agents are reminded to do it manually; Rulebase + Forest MCP automates the check.

3h. Enhanced Due Diligence (EDD) action trigger

“Yes, we can accept the document, please upload it to forest as well. WZ code for the activity is 6630 please trigger the action Org - Enhanced due diligence flag before the validation.”

Workflow: explicit Forest action by name (“Org - Enhanced due diligence flag”). Another concrete write-action target for the Forest MCP catalog.

3i. Other patterns observed in the same sample

• Tap-to-Pay activation lookup (org 019d48e7-70c5-70ac-8fa5-2d381904e39d) — agent looks up Legal Sector code in Forest, cross-references KB article 29853621466257. Often escalates to BL when sector isn’t on the allowed list.
• Account-info changes — short notes like “is it possible to change the informations on forest please?” — common BL request pattern.
• Suspension review tied to fraud reports — agent reads suspension reason set in Forest, checks against the customer’s actual conversation language and intent.

3j. What this tells us about agent time-in-Forest

The notes give us a much firmer footing than the KB-only estimate in §4 below: 2.4M internal notes for 1M tickets means agents are leaving documentation an average of ~2.4× per ticket. 19.6K of those (in body only — the redacted side adds ~9K more, and many notes touch Forest without literally typing the word) explicitly call out a Forest field, Forest action, or “Forest screenshot”. That floors the lower-bound estimate of Forest interactions at ~20K/year and the realistic count is many multiples higher (many notes describe Forest work using field names like “WF”, “smart action”, “OB”, “deposit_certificate-sent” without writing “Forest”).

4. Time-spent estimates

We don’t have direct telemetry of agent time-in-Forest, but we can triangulate.

Inputs:

• 1.018M Qonto tickets in 10 months → ~3,400 tickets/day, mostly chat/web/api/email.
• Forest is the system of record for: card / transfer / direct-debit / check status, account state, KYC docs, refunds, vouchers, debit blocks, user invites.
• Subject-line review of the most recent ~30 tickets shows recurring patterns that strongly imply Forest lookups: account-statement requests, UBO/KYC updates (e.g. external_id 5199216 “Associazione Culturale Anonima Riforestazioni — IT - KYC-B updates”), legal-document requests (“DROIT DE COMMUNICATION” tickets 5008884, 4984104, 5077260), “Récupération mot de passe” / account access (ticket 5365141), transfer status questions (ticket 5067160 German “wo sich die Zahlung aktuell”).
• KB article cluster sizes: status SOPs are localized to 4–6 languages each → individually high-volume.

Plausible bands (to be validated with Qonto telemetry):

Even with conservative midpoints, tens of agent-FTEs/year are spent inside Forest. A 20% reduction on status lookups alone (use case 1: Rulebase pre-fetches Forest state for QA + agent assist) is a 6–8 FTE swing.

Caveat: these are bottoms-up estimates from KB structure and ticket subject sampling, not measured. The right next step is a 1-week instrumentation ask of Qonto: “How many Forest sessions per agent per shift, and median time-in-Forest per ticket?” Their CS Ops team almost certainly has this from Forest’s own logs.

5. Mapping to the three agreed use cases

Use case 1 — QA ground-truthing via Forest lookups (start here, Qonto as design partner)

Why this is right: today Rulebase QA is blind to Forest state. An agent answers “your card is blocked because of failed 3DS” — Rulebase has no way to verify that against the actual card status in Forest. The 8 status-lookup KB articles above (each one localized 4–6×) are the surface area. We already know the SOPs, the field names (“Forest statuses of a card transaction”), and the escalation paths.

Concrete first slice:

1. Read-only Forest MCP calls for: card status, transfer status, direct-debit status, account scan.
2. Rulebase QA evaluator pulls Forest state at evaluation time and grounds the rubric (“did the agent’s stated status match Forest?”).
3. KB articles 25338839089553, 25696498133265, 25360035556881, 25360153749649, 40175232691089 define the field shapes — those become the MCP schema.

Example tickets that would have benefited (subject-derived; the underlying customer issues map to status lookups):

• Ticket 5067160 — DE customer asking for transfer status (would call card-transaction or transfer-status MCP).
• Ticket 5365141 — “FORESTA / RECUPERATION MOT DE PASSE” (account access — Forest customer 360 + user-invite SOP).
• Ticket 5055898 — “Demande relevés de compte professionnel AGRIFOREST” (statements — account-scan workflow).
• Ticket 5199216 — “IT - KYC-B updates // Association” (KYC workflow — Forest UBO check).

Use case 2 — Proactive workflows: Rulebase triggers pre-filled Forest tickets/actions

The clearest slot: when Rulebase risk indicators fire (dispute_risk_level, complaint_risk_level, compliance_risk_level, qa_risk_level are all populated columns on the conversations table — Rulebase already classifies these for Qonto), trigger a pre-filled Forest action.

Best three actions to spec first, ranked by KB centrality and clear input/output:

1. Refund / commercial gesture → KB article 25235187797649. Trigger: complaint detected. Pre-fill: customer ID, amount, reason code, suggested gesture tier.
2. Debit block → KB article 29607236425745. Trigger: fraud / unauthorized-access risk indicator. Pre-fill: customer ID, account ID, reason.
3. KYC document escalation → KB articles 30437496103825 (KD-UBO doc missing), 30437720388753 (Kbis >7D), 29851758022545 (L1 certificate >10D). Trigger: compliance risk + ticket-tagged KYC. Pre-fill: customer + document type + deadline.

Refund and debit-block are simplest to ship first; KYC is highest economic value because of the BL escalation cost.

Use case 3 — Dispute timeline verification (US 90-day rule + EU two-brain)

Qonto does not use Jira (verified). Disputes appear to live natively in Forest for them — agents document dispute-related actions (“Capture d’écran de la Closing account request sur Forest”, “PEP refused”, reKYC routing) directly against Forest org IDs. We don’t currently sync any Forest dispute records into Rulebase, so we have no direct evidence of the dispute state machine yet.

What we can see in our data:

• Notes referencing fraud / suspension / closure flags read from Forest (§3c).
• No dispute_filed_at equivalent in Zendesk for these tickets (Qonto routes disputes through Forest, not as a Zendesk custom field).
• Rulebase already classifies dispute_risk_level, compliance_risk_level, complaint_risk_level on the conversation row, so we have the trigger side covered.

What we need from Qonto / Forest to ship this use case:

1. The Forest dispute object schema (state machine + canonical filed_at timestamp).
2. Whether disputes are tied to the org (membership) or to the transaction.
3. Read access via MCP to those records.

Once those are in, the EU two-brain rule is straightforward as a Rulebase QA rule: “after a dispute exists in Forest with state filed, no agent reply on the linked Zendesk ticket may discuss dispute substance.” That is a ~1-day rule once Forest dispute read-access lands, and is the single highest-leverage piece of work for the EU regulatory angle pitched at Neo Fintech Week.

6. Opportunities ranked by build leverage

A reasonable 6-week plan: week 1 ship #1 (reKYC auto-route — proves the loop end-to-end with the smallest possible MCP surface), weeks 2–3 ship #2 (status reads + QA grounding), week 4 demo the lift to Qonto + co-design #3 (voucher pre-fill), weeks 5–6 ship #4 (Forest disputes + EU two-brain rule) for Neo Fintech Week — assuming we can unblock the Forest dispute schema in week 1.

7. Open questions for Qonto (to inform the spec)

1. Forest access scope — read-only is enough for use case 1 and 3. For use case 2, which write endpoints does the OAuth scope cover? Specifically: refund, debit block, user invite, KYC doc upload.
2. FL vs BL gating — many SOPs are split. Should pre-filled actions auto-route to BL when KYC is involved, or stay in the FL queue with a “BL review” flag?
3. Telemetry — can Qonto share aggregate Forest session data (sessions/agent/day, median time-in-Forest per ticket) to validate our time-spent estimates?
4. Dispute schema — the canonical dispute.filed_at timestamp lives in Forest (per the Jira custom-field name on Qonto’s data source). Confirmed?
5. Workspace split — “Compliance production” and “Associations” workspaces show different Forest UIs. Does the MCP expose them as separate scopes or unified?
6. Forest field catalog — can we get a flat list of the Forest customer/org fields used in the macros above? At minimum: currently_undergoing_reKYC, deposit_capital_status, pre_authorized state, closure_reason, OVP_HRC, PEP_refused, EDD_flag, WZ_code, legal_sector. These are mentioned by name in agent notes; turning them into MCP fields is mostly mechanical.
7. Disputes — does Qonto store dispute records in Forest (object name, state machine, canonical filed_at)? Or in a separate system altogether?

8. Source data references

• Metabase EU instance, organizations.id = 33 (slug qonto, country FR).
• Tables queried: conversations (id 431, 1.018M rows for Qonto), conversation_part_notes (id 328, 2.46M rows for Qonto, 19,649 with “forest” in body), knowledge_base_documents (id 145, 9,289 rows / 67 with “Forest” in title), conversation_parts (id 288), organizations (id 134), organization_data_sources (id 317).
• Date window for ticket data: 2025-06-24 → 2026-04-30.
• Notes-sample window cited in §3: 2026-04-30 (latest day available).
• Related context: Qonto March feedback.
• Correction log: earlier draft inferred Qonto used Jira from default jira_dispute_* columns on organization_data_sources. Corrected — those columns are schema defaults populated for other customers; Qonto does not use Jira.