How it works

You can trust a number more when you know how it was reached. Here is the whole mechanism, with no black box.

Reading the request

When you open a request, Second Chance reads its summary, description, request type, and labels. It pulls out the meaningful keywords (dropping filler words like "the" and "please") and uses them to search your knowledge base.

Scoring each article

Every candidate article gets a score from a fixed set of signals:

• Request type match: does the article speak to this kind of request? (weighted highest)
• Summary keywords: how many of the request's headline terms appear in the article?
• Description keywords: the same, for the body of the request.
• Label overlap: do the request's labels match the article's?
• Title and freshness: a boost when the match is in the article title, and a small adjustment for how recently the article was updated.

A short, on-topic request is not penalised for being short. The maths divides by the terms the request actually had, so a three-word request that matches all three words scores full marks.

The result is a band: Strong, Medium, or Weak. That is what you see on the card, and an article is counted as "covered" only when it clears the Strong band.

No machine learning is involved. The same request and the same articles always produce the same result, and every part of the score can be explained back to you. If you want the exact points and band thresholds, How matches are scored sets out the full formula with a worked example.

Turning scores into coverage

The coverage report runs that exact scoring across your recent requests and counts how many had a Strong match. The percentage you see is honest by construction: it is the share of requests that reached your desk and already had a strong article behind them.

Because the report and the issue panel share one engine, "strong" means the same thing in both places. There is no second, looser definition hiding in the coverage number.

Showing the same matches to the customer

If you switch on the portal panel, the customer sees those same scored matches on their own request, ranked the same way. The app runs that search as itself rather than as the customer, because portal customers are unlicensed, but it only ever returns articles already published to the portal for that service desk. A restricted or internal article is never shown to a customer, not even to the person who raised the request. You choose how the confidence shows, from a simple "Best match" badge to a percentage, or none at all.

Why it reads the customer-facing knowledge base

Second Chance searches the knowledge base your customer portal exposes, through Jira Service Management's own knowledge base interface. That is what lets it stay a free, single-product app with nothing to install on the Confluence side.

It deliberately does not reach internal-only articles. Reaching those would require the app to be authorised against Confluence directly, which is only possible on a paid, two-product setup. We chose to keep the app free and honest about the knowledge it can actually see, rather than charge for it or pretend. The same choice is what makes showing matches to customers safe: the app can only see portal-published knowledge in the first place.

Where to next

You now know what the app is, where its edges are, and how it reaches its numbers. Head to Get started to install it.