Can we add our own models or benchmarks?

Here's three main ways our users and customers use us:

1. Revenue Operations teams

Integrate Sumble's data programmatically to help with account scoring, territory planning, account qualification/disqualification, and CRM data cleanup. We provide feature matrices that feed ML models for large sales teams.

2. Individual AE's/SDR's

Many sales people have a small universe of named accounts that they go deep on. They use Sumble to understand the buying groups that exist within their target accounts, and which relevant technologies these groups use, and any relevant projects going on (e.g. data infrastructure migrations, cloud migrations, and GenAI projects can be critical signals for many of our customers)

For ongoing awareness of key changes within accounts, we work with our enterprise customers to define all the signals that are relevant to their sales plays, and send email/slack notifications when any of these signals happens in their accounts as well.

For sales reps with a larger universe of accounts (e.g. the SMB/commercial tier), they use us to filter out a lot of the noise in their territory and understand which accounts are real active businesses that are potential users of their product that they should spend time on.

3. Marketing

Marketers use us to figure out which accounts to focus on, and to spin up very targeted LinkedIn/Facebook/etc. campaigns to reach their most likely potential users and buyers

Thanks, this is helpful.

Thanks for the feedback!

The job functions we currently classify have been mostly focused by our early users/customers (companies building products/tools/infrastructure for data and software engineering teams), and handling the multilingual aspects of those across countries well.

We're aiming to extend this in two ways:

1. Adding job title and job description full-text search, to handle the long tail of usecases (in-flight project)

2. Extend the job function classification to the full universe of jobs that people can have

Job title and job description full text search would really be perfect. At least in my mind, good GTMs are narrow (software engineers in flight test) vs. broad, like selling to all software engineers using python in the manufacturing industry.

Thanks! Job descriptions are included in job post CSV exports, which is the current only path for that workflow.

We're planning to make that workflow much better in four ways this year:

1. Adding an API to make it easier to consume the data programmatically (next 2 months)

2. Enabling running LLM's on tabular results on Sumble directly that would enable pulling in job description context into the LLM call

3. Experimenting with an MCP endpoint, to see if that's helpful for these workflows as well

4. Experimenting with adding Sumble scoring models

Thanks! We're planning to add an API in the next two months, and exploring MCP alongside that

Thanks! We describe this as a knowledge graph because that's how we think about the structure in the data & is where we want to go.

Right now, we've focused on normalizing several key entities (e.g. organizations including parent/subsidiary relations, technologies, people, and job functions), and capturing the relations between these as well as additional useful metadata like location and industry.

From a backend implementation standpoint, this is currently implemented as structured relational tables for query performance and simplicity (e.g. count up all teams mentioning pytorch in job posts including rolling up across parent subsidiaries and sort by the biggest organizations descending).

Future direction here is TBD as we expand the sources that we cover and types of queries that can be computed across these sources.

There's been a lot of attempts at building high-quality public knowledge graphs that haven't hit escape velocity.

We're focusing on a structured, commercially relevant subset of the problem as a starting point to generate a critical mass of usage and funding that will enable us to build the bigger vision: a highly structured, up-to-date, and trusted repository of all the facts about the world that is easy to browse, query, and integrate programatically into all the relevant workflows (including for grounding LLM's)

Appreciate you sharing the vision. Having worked in this space for a while, IMO the biggest challenges for a public facing graph are in 1. Entity Linking from NL Query -> Graph queries or in your case relational queries (Multiple similarly named teams in Microsoft). And 2. Relevance of results for more complex queries. I like your approach of having a drop down of filter tags, which eliminates 1, but will be harder to scale like in a Graph of everything.

| Maybe specific but I want to filter by head count in job function (ie: find organizations that have 50-200 software engineers regardless of their total head count).

You're not alone! We've heard this from others as well, planning to add it soon

| 2. I don't know if this is happening because you are getting lots of traffic now, but each query takes 20-30 seconds which is unusable.

Thanks! What queries are you finding painful? Most should be under a second, there's some that are expensive though

Simple queries. As in typing the name of a person in a company list of 200. Keeps spinning forever.

Thanks for taking it for a spin! I'm working on why this is slow now.

Thanks! We'll take a look at that one

Thanks! Our current coverage is focused on companies with a significant online presence (e.g. they've made job posts, people say they at the company, and/or they have a functional website).

Our goal is to have complete coverage for active companies and organizations in the world, and an understanding for companies that previously existed but are no longer active as well (these appear extensively in CRM's and add noise).

We prioritize expanding data coverage in areas that we hear are most useful from our current users and customers.

Awesome, go crush it!

Thanks! Haven't prioritized something public facing on this front yet - what would you find most helpful?

I'd set up a ticketing system so you can receive bug reports and feature requests. It's more structured than chat rooms, which are information black holes.