You just finished a great discovery call. The buyer’s engaged, the use case is real, they asked for a pricing comparison by Friday and a technical deep-dive with their VP next week. You said “absolutely” to both.
Then you jump on your next call. And your next. By 5pm, you’re reconstructing what happened from memory — half the commitments scattered across notes, CRM fields, and your head.
Doris was built to solve this. Every call, every email, every commitment extracted and connected. Your reps get follow-ups drafted, decks built, CRM updated — before they context-switch.
But until now, all of that intelligence lived inside Doris. Your team could see it in the app, the agent could surface it in chat, but you couldn’t build on top of it.
Today that changes.
The Problem with Deal Data
Most sales tools give you data. CRM fields, call recordings, email threads, activity logs. But data isn’t intelligence. Intelligence is knowing that the commitment you made in call one connects to the objection raised in call three, which relates to the stakeholder who controls the budget, who hasn’t been in a meeting since March.
That kind of connected context is what reps carry in their heads — and lose the moment they context-switch.
Doris has been assembling this context automatically. Every meeting processed, every email classified, every commitment tracked and linked back to its source. Not just data points, but relationships. Not just records, but a graph.
We call it the Doris Ontology.
What is Doris Ontology?
Doris Ontology is a typed, relationship-rich graph of everything happening in your deals. Not raw CRM fields. Not unstructured transcripts. Structured, enriched intelligence that connects entities the way your deals actually work.
The entities in the graph:
- Deals — stage, health signals, strategy, linked commitments and evidence
- Accounts — company-level context, deal history, relationship timeline
- People — buyer contacts with influence mapping and interaction history
- Meetings — summaries, key moments, extracted commitments, attendees
- Commitments — promises made on calls, with status tracking, deadlines, and source evidence
- Objections — buyer concerns surfaced across conversations, tracked to resolution
- Competitors — competitive mentions detected in calls and emails
- Strategy — deal strategy recommendations assembled from conversation evidence
- Insights — extracted intelligence from every conversation and document
- Pipelines, Leads, Tactics, Artifacts, Documents — the full commercial model
14 entity types, 12 relationship types, all connected. A deal links to its meetings, which link to their commitments, which link to the stakeholders who made them. Query one entity, expand into its relationships. Traverse the graph the way deals actually unfold.
This isn’t a secondary API bolted onto the product. The entire Doris for Sales platform — the deal agent, meeting prep, commitment tracking, daily briefings, deal briefs, follow-up emails — runs on this same ontology. Every feature you use in Doris queries the same graph, through the same service layer, that you now have access to.
Why Open the Graph?
Because the most interesting things you can do with deal intelligence happen outside any single tool.
Your Slack channels should know when commitments go overdue. Not because someone remembered to check — because the system reacts the moment a deadline passes.
Your project management tool should automatically create tasks when a deal closes. Every commitment made during the sales process becomes a deliverable for the CS team — without a handoff meeting.
Your AI agents should be able to prep reps for calls. Not with a generic summary, but with the full context: what was promised, what’s overdue, who the champion is, what objections came up last time.
Your internal dashboards should show commitment follow-through rates. Not CRM stage progression — actual evidence of whether your team is keeping the promises that move deals forward.
None of this is possible when deal intelligence is locked inside one application.
Three Ways In
We’re shipping three complementary access patterns, each built for a different integration style:
REST API — For server-side integrations. Data pipelines, reporting tools, custom dashboards, internal apps. Paginated, searchable, batch-capable, with an auto-generated OpenAPI spec for client SDK generation.
Webhooks — For reactive automation. Subscribe to events like meeting.processed, deal.stage_changed, or commitment.overdue. Receive signed payloads at your endpoint within seconds. Retry with exponential backoff. Full delivery history in the console.
MCP (Model Context Protocol) — For AI-native access. Connect Claude, ChatGPT, Cursor, or any MCP-compatible tool directly to the ontology. Ask questions in natural language — “What commitments are overdue on the Acme deal?” — and get structured answers from the graph.
All three share the same authentication, the same rate limits, and the same tenant isolation. Choose the pattern that fits your workflow, or combine them.
What You Can Build
A few examples of what becomes possible:
- Slack alerts when commitments go overdue on specific deals
- Teams notifications with meeting summaries and action items when calls finish processing
- n8n workflows that trigger project kickoffs when deals close — with every commitment as a task
- AI agents that prep reps before calls with full deal context, open commitments, and stakeholder maps
- Custom dashboards tracking commitment follow-through rates per rep, per stage, across the pipeline
These aren’t hypotheticals. They’re the integrations the ontology was designed to power.
Getting Started
Everything starts from the Developer Console inside Doris. Generate an API key, create a webhook, or connect your AI tools with a single command.
For the full technical walkthrough — endpoints, event types, code examples, and cookbook recipes — read the Developer Guide.
Full documentation is also available at docs.meetdoris.com.
What’s Next
This is the foundation. We’re building toward a fully programmable deal intelligence layer:
- Write operations — update deal fields, create commitments, sync data back into Doris
- More event types — stakeholder changes, strategy updates, competitive signals detected
- Richer traversal — multi-hop graph queries, temporal filters, aggregate views
- Client SDKs — Python and TypeScript libraries for typed access
The ontology is the single layer between your systems and the intelligence Doris assembles from every conversation, every email, every interaction across your pipeline.
Everything your team builds on top of it compounds.