Skip to content
CogniYukti

AI · finding

Most questions in a business have already been answered. Somewhere else.

In a ticket somebody resolved in March. In a policy document nobody opens. In the head of the person who left in June. The work is not answering it again — it is finding the answer that already exists, phrased by somebody who did not know they were writing documentation.

So search here matches three ways at once, and ranks all three together.

  • Your own material, not the open internet
  • Exact references stay exact
  • Resolved work becomes searchable

What the customer typed

“the bill just sits there and wont go out, been like it since friday”

  • Resolved ticket · MarchDifferent words entirely — “bill won't finalise”
  • Knowledge articleMatched on the exact phrase “draft invoice”
  • Resolved ticket · JulyMatched through a typo the customer made
One ranking from three ways of matching. Meaning alone loses the exact phrase; words alone lose this customer · Illustrative.

The problem, specifically

Customers do not describe a fault the way your documentation does.

Look at the query above. It contains no product noun, one typo, and a detail — since Friday — that matters to the customer and to nobody else. The article that answers it is titled "Invoice remains in draft after approval" and shares exactly one word with it.

A search that only understands meaning will miss an invoice number typed exactly right. A search that only matches words will miss this customer entirely. Neither is sufficient, which is why the ranking is all three.

  • The words

    Full-text matching, so an exact phrase, a product name or a reference number lands exactly where you expect it to.

  • The spelling

    Near-matching for the word somebody typed in a hurry, which is most words typed into a support form.

  • The meaning

    Similarity, for the customer who described the same fault sharing none of your vocabulary — the case that costs an agent twenty minutes.

How search fails elsewhere

Three failures, all of them silent.

A search that returns nothing is honest. These three return something, which is why nobody notices them.

The right answer, ranked ninth

The article that answers the question exists and is returned — below eight that share more words with the query.

An agent scrolls twice, gives up, and writes the reply from scratch for the fourth time this month.

The exact reference, approximated

Meaning-only matching treats an invoice number as a string of digits with no special status, and helpfully finds similar ones.

A search for INV-4417 returns four invoices, none of them that one.

The corpus that silts up

Every resolved ticket is added, nothing is ever promoted, and the ranking degrades as the volume grows.

The best answer is a curated article from last year, outranked by forty near-duplicate tickets that quote it.

The guarantees

Search is easy to demo and hard to trust.

  • It does not invent a source

    An answer names the material it came from. If there is nothing in your corpus that answers the question, that is what you are told.

  • Permissions hold inside search

    Finding something is not a way around not being allowed to see it. What a person cannot open does not surface for them.

  • Curation beats volume

    An article a human promoted outranks the raw ticket it was distilled from, so the corpus improves as people use it rather than silting up.

What you receive

A ranked list, and the reason each thing is on it.

  • Why each result matched

    Whether it came back on the words, on a near-match to something mistyped, or on meaning alone — so a result that looks unrelated can be understood rather than dismissed.

  • The material it came from

    A resolved ticket, an article, a document — named, openable, and attributable. An answer with no source behind it is not produced.

  • Nothing, when there is nothing

    If your corpus does not answer the question, that is the result. The failure mode is an empty list, never a plausible paragraph.

  • Results you are allowed to open

    Permissions apply inside search. Finding something is not a route around not being allowed to see it.

Objections first

What a support lead asks before switching it on.

Do we have to write documentation first?

No, and that is the point. Resolved tickets are material from the day you arrive. Curating them into articles makes the results better, but nothing requires it before the search is useful.

Will it surface something a customer should not see?

Permissions apply inside search. A result a person is not allowed to open does not appear for them, and a customer-facing surface draws from the customer-facing corpus only.

What if our tickets are badly written?

Then meaning-matching is doing most of the work, which is the case it exists for. Badly written tickets are still a record of a real fault and a real fix.

Does it replace our agents?

No. It shortens the part of the job that is remembering whether this has happened before. The agent still decides what to do about it.

Is this the same search used in hiring?

The same idea, different material. Finding a person you met before and finding a fault you fixed before are the same problem wearing different clothes.

Book a demo

Search for it the way your customer would.

Bring a real question from your own inbox. The badly phrased one, with the typo in it.

  • Type a fault in words nobody here would use, and find it anyway
  • Raise a ticket and show me the resolved ones it matched
  • Search an exact reference number and show me it lands exactly
  • Show me a search that returns nothing rather than guessing