QlintSupport intelligence for Solis

Qlint system overview · Solis Technical Support

How Qlint Works

Qlint is an AI support intelligence system built for Solis Technical Support. It analyzes incoming Freshdesk tickets, retrieves relevant technical knowledge, creates a grounded technical response, and places the result directly inside the ticket for the support engineer.

  1. Freshdesk ticket
  2. Qlint
  3. Knowledge retrieval
  4. Technical analysis
  5. Response generation
  6. Freshdesk internal note
  7. Support engineer

Qlint does not send customer emails. It creates an internal note in Freshdesk with its proposed answer and technical analysis. The support engineer reviews it and communicates with the customer.

Status labels on this page:ImplementedIn developmentPlanned

01

Overview

What is Qlint?

Qlint is an internal AI support intelligence layer built around the existing Solis support workflow. Engineers do not open a separate AI tool or copy information between systems — Qlint works inside Freshdesk, the system the team already uses.

The purpose is not to replace the support engineer. It is to reduce repetitive investigation and give the engineer a strong technical starting point immediately.

What Qlint does on every ticket

  • Reads the incoming ticket and full thread
  • Understands the technical issue
  • Identifies products, alarms, settings and symptoms
  • Searches approved technical knowledge
  • Compares information from different sources
  • Reasons about the problem
  • Produces a concise technical recommendation
  • Creates an internal note in Freshdesk
  • Helps the engineer respond faster and more consistently

02

Workflow

From ticket to technical recommendation

What happens, step by step, from the moment a Freshdesk ticket arrives.

  1. 1

    Ticket arrives

    Implemented

    A customer or installer creates or updates a ticket in Freshdesk. A Freshdesk automation rule notifies Qlint, which fetches the ticket from Freshdesk. Only tickets in the After Sales – Nordics group are processed.

    • Subject and customer message
    • Full previous conversation
    • Ticket metadata (group, status, requester)
    • Pictures in the ticket: screenshots, display photos, app views
    • PDF attachments: reports, datasheets, invoices, logs (text and pictures)
  2. 2

    Qlint structures the problem

    Implemented

    Before writing anything, Qlint extracts the technical signals from the thread. Quoted earlier emails, signatures and legal footers are removed so the actual conversation fits. Facts are kept separate from assumptions.

    • Product family, inverter and battery model
    • Alarm codes, firmware, meter / CT
    • Serial numbers, market, symptoms
    • What was already asked, answered and done
  3. 3

    Knowledge retrieval

    Implemented

    Qlint searches all connected knowledge together — solved cases, Freshdesk Solutions articles, SharePoint and Google Drive files, uploaded documents — using the extracted signals, not only the wording of the last email. Material about a different model is demoted.

  4. 4

    Technical reasoning

    Implemented

    The language model receives the cleaned thread, what the pictures show, the ranked knowledge, Qlint's support rules and the source hierarchy. It works out the most likely next step from that evidence.

  5. 5

    Confidence and missing information

    Implemented

    If important information is missing, Qlint asks for that specific item instead of inventing an answer — for example CT direction, AC measurements, battery model or firmware version. Conflicts between sources are flagged for the engineer.

  6. 6

    Freshdesk note

    Implemented

    Qlint writes a private note on the same ticket with two parts: the proposed customer reply, and internal review material (sources used, missing information, uncertainties). It never sends email to the customer and never changes ticket status.

  7. 7

    Human review

    Implemented

    The engineer sees the note inside the ticket and can use it, edit it, ignore it, troubleshoot further or escalate. The engineer remains responsible for what reaches the customer.

03

Knowledge

Qlint does not rely on the LLM's memory

The language model is the reasoning engine. The knowledge base is the technical source of truth. Qlint retrieves company-specific knowledge before generating a technical answer, so the AI reasons with Solis information rather than generic training.

Connected sources

  • Freshdesk Solutions articles (text and pictures)Implemented
  • Solved Freshdesk tickets, summarised as case recordsImplemented
  • SharePoint and Google Drive foldersImplemented
  • Uploaded documents: PDF, Word, Excel, PowerPoint, imagesImplemented
  • Manual notes and proceduresImplemented
  • Engineer edits and sent Freshdesk replies (learning)Implemented
Sources
Knowledge processing
Knowledge base
Relevant context retrieval
LLM
Technical answer

How knowledge is stored and searched

Documents are divided into smaller searchable pieces. Each piece gets an embedding — a numeric representation of its meaning. That allows semantic search: Qlint finds information with the same technical meaning even when different words are used. Text inside pictures, scanned pages and diagrams is read and included.

  1. Document
  2. Text + picture reading
  3. Chunks
  4. Embeddings
  5. Vector search
  6. Relevant knowledge
Technical details
  • Backend: Supabase (PostgreSQL, Storage, Auth).
  • Structures: knowledge_bases, knowledge_documents, knowledge_chunks; files in the private knowledge-base-files bucket.
  • Embeddings: OpenAI text-embedding-3-small. Retrieval runs vector search with strict and fallback similarity, de-duplication and per-document limits so one long document cannot crowd out others.
  • Ranking order: same product + same problem + solved case, official documentation, internal procedures, related historical cases, broader knowledge.
  • Processing runs through a job queue with retries; failed items can be retried.

04

AI

The AI model reasons. It is not the database.

The language model (OpenAI) interprets the case, connects symptoms with technical knowledge, compares sources, identifies missing information, reasons through troubleshooting steps and writes a clear reply. The knowledge supplied to it is what grounds the response.

Ticket context
Retrieved Solis knowledge
Qlint rules
Support procedures
LLM reasoning
Technical recommendation

Source hierarchy

  1. 1. Official Solis documentation
  2. 2. Internal instructions and procedures
  3. 3. Previous tickets — treated as a lead, not as proof
  4. 4. General technical knowledge — flagged as uncertain

When the answer is not in Qlint's knowledge, the model may use general solar, inverter and battery expertise. Model-specific details are then written as something to verify, and the note marks the information as uncertain for the engineer.

What happens when Qlint does not know?

Uncertainty is an intentional part of the design. Qlint should never create technical facts because an answer sounds plausible.

  • Never invent product specifications or settings
  • Never invent firmware or compatibility information
  • Never invent troubleshooting results or measurements
  • Never claim something was checked without evidence in the ticket
  • Never promise HQ contact, warranty decisions or timelines
  • Use retrieved knowledge when available
  • Separate confirmed facts from assumptions
  • Flag conflicting sources instead of choosing silently
Enough reliable information?

Yes

Create recommendation

No

Can missing information be requested?

Yes

Ask for the specific item

No

Recommend escalation

05

Speed

Qlint works when the ticket arrives

The value of Qlint drops if the engineer has already investigated the ticket manually. Qlint therefore starts as soon as Freshdesk notifies it — no queue in front of the new ticket. Routine background work runs afterwards. Accuracy is not traded for speed.

Current flow

Implemented
  1. Ticket arrives
  2. Qlint starts
  3. Knowledge retrieved
  4. Analysis
  5. Note appears

Current limits

  • Automatic analysis runs Monday–Friday 07:00–18:00 Stockholm time. Tickets outside these hours are handled the next working morning.
  • Analysis usually takes under a minute.
  • If Freshdesk temporarily limits requests, Qlint pauses and resumes where it stopped.

06

Freshdesk

Freshdesk stays the working environment

Qlint is built around Freshdesk instead of moving engineers into another application. Ticket data enters Qlint, Qlint processes the case, and the result is written back as a private note on the same ticket.

Freshdesk handles

  • Ticket ownership
  • Customer communication
  • Ticket status
  • Customer history
  • Agent workflow
ticket → Qlintnote ← Qlint

Qlint handles

  • Ticket understanding
  • Reading pictures in the ticket
  • Knowledge retrieval
  • Technical reasoning
  • Response assistance as a private note

Human and AI responsibility

Qlint

  • Reads the case
  • Searches knowledge
  • Finds relevant technical information
  • Identifies missing information
  • Performs AI-assisted reasoning
  • Drafts technical recommendations
  • Creates Freshdesk notes

Support engineer

  • Reviews the recommendation
  • Uses professional judgement
  • Communicates with the customer
  • Makes final decisions
  • Performs physical verification when needed
  • Approves escalation and RMA actions
  • Handles exceptional situations

Qlint assists the engineer. It does not remove the engineer from the decision.

07

Learning

Qlint improves with the organisation

Two different things are often confused: training the AI model, and improving the knowledge Qlint gives it. Qlint does not retrain the foundation model. It continuously improves the information available to the model.

  1. Support activity
  2. Knowledge analysis
  3. Candidate knowledge
  4. Validation / processing
  5. Qlint knowledge base
Implemented

Solved and closed tickets become case records (problem, troubleshooting, fix). Checked about every 30 minutes during working hours; last 12 months imported.

Implemented

Qlint compares its draft with the reply the team actually sent in Freshdesk and extracts reusable lessons.

Implemented

Nightly learning run consolidates engineer edits and corrections.

Implemented

Learned knowledge is kept separate from approved company knowledge and ranks below it.

08

Architecture

How the components connect

The real Qlint architecture, from Freshdesk and back.

Freshdesk
Webhook trigger layer
Qlint backend
Ticket processing
Knowledge retrieval
AI reasoning
Response validation
Freshdesk note

Connected to the Qlint backend

Supabase
Database, authentication, private file storage and vector search. All company-owned rows are scoped to the company and protected by Row Level Security.
Companies and members
companies and company_members define who belongs to which workspace and with which role. Everything else hangs off the company.
Knowledge bases, documents and chunks
A knowledge base groups documents. Each document is processed into chunks with embeddings so it can be searched by meaning.
Processing jobs and job attempts
processing_jobs is the work queue for reading and embedding documents; job_attempts records every attempt so failures can be retried and traced.
Integration layer
A provider-neutral layer holds encrypted connection credentials, sync state, incoming events, and a log of every action written back (such as Freshdesk notes) to prevent duplicates.
OpenAI
Language model for analysis and drafting, vision for reading pictures, and text-embedding-3-small for embeddings.
External knowledge sources
SharePoint, Google Drive and Freshdesk Solutions, where configured by the workspace.

09

Security

Security and data separation

Company information is kept separated and protected. The AI receives only what is needed for the specific ticket. No compliance certifications are claimed here.

Authentication

Every user signs in; the app checks the session on the server.

Company-based access

Users only see data from workspaces they are members of.

Row Level Security

The database itself enforces company separation on every row.

Private storage

Knowledge files live in a private bucket, not public URLs.

Backend-controlled integrations

Freshdesk, Microsoft and Google credentials stay on the server, encrypted.

Human approval

Nothing is sent to customers automatically. Notes are private.

10

Example

Example: a support ticket enters Qlint

Incoming ticket

“The battery is not discharging even though the battery SOC is 80%.”

  1. 01

    Reads the ticket

    Full thread and any screenshots of the app or display.

  2. 02

    Identifies signals

    Battery · SOC = 80% · not discharging.

  3. 03

    Retrieves knowledge

    Reserved SOC, battery settings, operating mode, BMS status, allow charge/discharge.

  4. 04

    Evaluates the evidence

    Is the model known? Are settings visible? Anything already tried?

05 · Private note in Freshdesk

“Check the Reserved SOC / minimum SOC setting first. If Reserved SOC is configured around 80%, the inverter will intentionally prevent further battery discharge.”

06 · The engineer reviews it. 07 · The engineer replies to the customer.

This illustrates the workflow. Qlint's actual recommendation depends on the ticket context and the knowledge available at that time.

11

Principles

Product philosophy

  1. 01

    Knowledge before generation

    Technical answers are grounded in available knowledge.

  2. 02

    Human remains in control

    Qlint recommends. The engineer decides.

  3. 03

    Work inside existing systems

    No extra workflow for the support engineer.

  4. 04

    Fast enough to be useful

    Qlint processes the case as soon as support activity occurs.

  5. 05

    Admit uncertainty

    If Qlint cannot determine the answer, it says so.