Building your product graph and keeping knowledge current

Two tools help agents talk about your product precisely: the product graph, which maps what you sell, and releases, which tie knowledge to the version it describes. This guide sets up both and shows how to keep them current as your product changes.

Step 1: sketch the graph on paper

Before you open the product graph, list:

• your products and their modules;
• the features prospects ask about by name;
• the integrations prospects ask about;
• the three to five personas who buy and use your product;
• one or two key workflows per module.

Use the names buyers use. Appricity recognises an entity when a question uses its name, so "Billing" beats "Revenue Operations Suite" if that's what customers say.

Step 2: add entities and relationships

In Knowledge → Product graph:

1. + Entity for each item: choose the type, enter the name and a one- or two-sentence description.
2. + Relationship to connect them, for example:
   • Platform contains Billing;
   • Billing integrates with Stripe;
   • Usage reports used by Finance director;
   • Month-end close requires Billing.
3. Switch to Graph view and look for entities with no connections.

Fifteen to thirty entities is a good first graph.

Step 3: tag your knowledge

Tags tell Appricity which passages are about which entity.

• When importing in bulk, leave Suggest entity tags on, then approve or reject the suggestions on the batch page. Approve all is there for when the suggestions are clearly right.
• For existing sources, open a source, select passages and click an entity to tag them.

Then ask a question that names an entity in Conversations and check the cited passages are the ones you'd expect.

Step 4: decide whether you need releases

If every customer is on the same version, you don't: leave every source agnostic.

If customers run different versions:

1. Create a release for each version that matters in Knowledge → Releases, with its predecessor and changelog.
2. Set as current the version most customers run.
3. Give each source a version binding: agnostic for company material, current for documentation that always describes the latest version, or a specific release or range for version-specific material.

Step 5: keep it current at each release

When you ship a new version:

1. Create the new release, with the previous one as its predecessor, and paste in the changelog.
2. Add or re-ingest the documentation that changed, and bind it to the new release.
3. Add entities for new modules, features and integrations, and tag the new passages.
4. Mark released, then Set as current. The previous release becomes superseded, and sources still bound to it show as stale.
5. Check the release's coverage and coverage gaps against its predecessor.
6. Ask a few questions about what changed, and check the answers cite the new material.

How often should I review the graph?

Whenever you ship something buyers will ask about by name, and once a quarter otherwise. Deactivate entities you no longer sell rather than deleting them; their history is kept.