Powering account scores in a sales platform with licensed signals

A score beside an account is only as useful as the reason you can give for it and as stable as the method behind it. This guide is for the product and data team of a sales platform that wants to embed company-level account scores with their evidence. It covers what a weekly row carries, how to map it to your accounts, how to show it, how to keep the numbers stable through a change of method, and what the licence has to settle before you build.

What a weekly score carries

The intent dataset delivers Intent Scores: a row for every company, topic and closed week (company_intent_weekly), as long as the topic scores 5 or more. Weeks run from Monday to Sunday, UTC. Once a week has closed its rows are written, and they are not revised afterwards. The score draws on every signal from the 90 days up to the end of the week, with each signal's weight halving every 30 days, and it is mapped onto a scale of 0 to 100 that climbs steeply on the first strong signals and levels off as more accumulate.

Behind the score sit Company Signals (company_signals): every dated signal with its observed_at, source, kind, topics, weight and detail. The five entries in evidence are enough for a first explanation. Query company_signals for the same company, topic and 90 days when a user asks for more.

The inputs are things the company itself does in public: it adds a tool to its site, opens a role, makes a filing or publishes an announcement. Every score is therefore open to review through its evidence. The data is company-level, and routing to a person comes from the contacts you already hold.

Mapping scores to your accounts

Give every account in your platform a company_id. The domain of the account's website is the first key: match it to the domain column of the Technology Stack (company_technologies) or Web Traffic (traffic_ranks), both of which carry company_id. For a listed company, match on isin, figi or ticker with mic. Keep the basis of each match on the link, because a wrong match shows a user someone else's score. The guide to enriching company records in a data product covers matching in more detail.

A match run tells you what share of your accounts resolve to a company ID, and that share differs by account list. Your interface needs three states, not two.

A left join from your accounts, through your map to company_id, to the weekly table gives the three states in one pass.

select
  a.account_id,
  case
    when m.company_id is null then 'unmatched'
    when w.score is null then 'no_signal'
    else 'scored'
  end as state,
  w.score, w.surge, w.signals, w.evidence
from accounts a
left join account_company_map m on m.account_id = a.account_id
left join company_intent_weekly w
  on  w.company_id = m.company_id
  and w.topic      = :topic
  and w.week_start = :week_start;

A new weekly row arrives once a week. The signals behind it arrive daily, so an activity feed in your product can show evidence that is newer than the score.

Showing the score and the reason

An illustrative example for Acme Robotics shows the pattern: CRM, 68, week of 21 September. A CRM tag was first seen on its website on 22 September. Two open postings name CRM tools. It announced a partnership on 24 September. Each sentence after the first comes from one entry of evidence: its kind, source and date, with the link from detail where there is one.

Four rules keep the display honest.

• Show a band, not a decimal. The scale flattens as evidence accumulates, so 72 and 78 differ less in evidence than 22 and 28 do. Choose bands, and show the surge flag separately.
• Show the number of signals. A high score resting on one signal is a thinner basis than the same score resting on eight.
• Show the week. A score is as of the Sunday that closed its week, not as of today.
• Carry the evidence. Every score is built from dated public signals. Put the signal count, the week and the top evidence line in the tooltip.

Fit and timing are separate questions. Keep this score as a timing input beside your own fit model and show both, so that a user can see whether an account ranks high because it fits, because the timing signals are strong, or both. The guide to prioritising accounts with intent scores shows how a revenue operations team combines them.

Frozen versions and the change notice

Every label and score is made under a named label version that stays frozen once released: intent-v2 for the weekly score, with jobs-v2, sites-v2, signal-v2 and news-v1 beneath it. Changing the labels, their questions or floors, the topics, the weights or the scoring formula means a new version, and a breaking change is announced at least 90 days ahead. For a platform whose customers learn to read a number, this is the property that matters most: the meaning of a 60 does not move under them.

Work to this routine from the first day.

1. Store intent_version with every score you keep and show.
2. On notice of a new version, read what changed in the methodology and list the tables and columns your product uses.
3. Ask for an overlap in which both versions are delivered. Whether that happens, and for how long, is a matter for the agreement, not something the notice period guarantees.
4. During the overlap, compare the same weeks. Take the rank correlation of old and new scores over your accounts for each topic, the share of your top 100 accounts that stay in, and the number of accounts that cross the surge flag in one version only. Read the accounts with the largest rank change together with their evidence.
5. Set your own cut-over inside the 90 days and tell your customers. Do not promise them more notice than you receive: with 90 days from Fokals and 30 days to test and release, 60 days is the most you can promise.
6. Keep old scores in your history under their version. Past weeks are never rewritten, so there is nothing to restate.

What to settle in the licence before you build

Fokals licenses data by written agreement for internal use, embedding in a product or redistribution. A sales platform that shows scores to its customers is embedding the data in a product, and is redistributing it if customers can export the rows. The data licence guide treats the three uses side by side. For this use, settle these points in the agreement.

• The datasets: Intent Scores and Company Signals only, or the datasets behind the evidence as well.
• Whether your customers may see the evidence and its detail, and whether they may export them.
• Whether any attribution must travel with a value.
• The overlap period for new versions, and the notice for changes that need no new version, such as additions to the technology catalogue, which the changelog lists.
• What you may keep after the agreement ends, including past scores shown in your customers' reports.
• The number of end customers or accounts covered.
• Who answers a customer who disputes a score, and which public documents you may cite when you do.

How to read the scores

• A score describes a company, from what the company does in public. It is evidence-backed: every score carries the dated signals behind it.
• A row is as of the Sunday that closed its week, written once and never revised, so a score can be reproduced for any past week.
• A score of 50 or more with a surge flag marks a change against the company's own twelve-week average, and the evidence says what changed.
• Labels behind the signals are produced under named, frozen versions, so a label means the same thing from one week to the next.

How Fokals delivers it

The weekly rows and the signals reach you by REST API or as bulk exports in JSON, JSON Lines or CSV, with scores refreshed weekly and signals daily. Every export comes with a manifest that lists its sources, period, label versions and licence. The data platforms page describes licensing for embedding and redistribution.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.