Skip to content

Sales

Solution

A CRM stores the current stage of a deal. It does not store what you actually promised a customer, in whose words, or whether that promise survived the next three email threads. Telha resolves account and opportunity state across the CRM record and the correspondence around it, so "what did we commit to" has an answer with a source, not a guess from whoever remembers the call.

The state questions sales needs to answer

  • What did we commit to this customer, and when did we commit to it?
  • What was the account's state (owner, stage, terms) at the time of the renewal decision?
  • Which opportunities had a discount or non-standard term approved, and who approved it?
  • What did the rep say in email or Slack that never made it into the CRM record?
  • What was the deal's stage on the date a competitor's mention first shows up in the correspondence?
  • Whose commitment was it, when two people on the account team said different things?

Why this needs three clocks

A renewal conversation asks about the account "as it stood" on a past date, not the account as CRM shows it today after three stage changes. Valid time answers what the terms were on that date; transaction time answers what we had recorded about it by then, which matters when a rep insists they "always knew" a discount was approved.

What to connect

Source Shipped connector What it feeds
Salesforce Salesforce connector Accounts, opportunities, contacts, stage history, as format=json records labeled by SObject
Email Exchange connector Commitments and terms discussed by email, ingested as format=email
Slack Slack connector Deal-desk and account-team threads, ingested as format=json (SLACK_THREAD)
Contracts and proposals (PDF/DOCX) Uploaded via /v1/ingest (docling) Signed terms and the language actually in the paper
Identity Entra ID connector Verified rep and approver identity, for clarification routing and RBAC

Order matters

Run the Entra connector first. It supplies the canonical identity that Salesforce, Exchange, and Slack principals resolve against, and it is the authority substrate clarifications use to find the right person to ask.

Example queries

All examples run against POST /v1/query. See the query language reference for the full grammar.

Open opportunities above a value threshold, above a given stage
{
  "find": "OPPORTUNITY",
  "where": {
    "status": { "$eq": "open" },
    "amount": { "$gte": 250000 },
    "stage": { "$in": ["negotiation", "proposal"] }
  },
  "limit": 50
}
Every open opportunity over $250k currently sitting in proposal or negotiation.

What the account looked like on the day the renewal was decided
{
  "find": "ACCOUNT",
  "where": { "name": { "$eq": "Northwind Traders" } },
  "atValidTime": "2026-03-14T00:00:00Z",
  "expand": [{ "type": "OWNED_BY", "direction": "out", "depth": 1 }]
}
Reconstructs the account's terms, owner, and stage exactly as they stood on March 14, the date the renewal decision was made, regardless of stage changes recorded since.

What we believed about the discount approval before the deal desk correction
{
  "find": "OPPORTUNITY",
  "where": { "name": { "$eq": "Northwind Traders - FY27 Renewal" } },
  "atValidTime": "2026-03-14T00:00:00Z",
  "atTxTime": "2026-02-20T00:00:00Z"
}
Pins both clocks: what the deal terms were on March 14, as Telha had recorded them by February 20, before a later correction landed. This is the value any report run on February 20 would have used.

Commitments mentioned near a keyword, fused with structured filters
{
  "find": "COMMITMENT",
  "where": { "account": { "$eq": "Northwind Traders" } },
  "vector": { "text": "extended payment terms", "model": "m1", "k": 10, "minScore": 0.55 },
  "expand": ["REFERENCED_IN"]
}
Finds commitment records semantically close to "extended payment terms" for this account, expanded to the emails or threads that reference them.

A verified answer in practice

Question posed to /v1/generate: "What did we commit to Northwind Traders on pricing for the FY27 renewal, and when?"

{
  "question": "What did we commit to Northwind Traders on pricing for the FY27 renewal, and when?",
  "query": {
    "find": "COMMITMENT",
    "where": { "account": { "$eq": "Northwind Traders" }, "topic": { "$eq": "pricing" } }
  },
  "expandDepth": 1
}

{
  "draft": "Telha committed to a 12% renewal discount for Northwind Traders, effective the FY27 term [S1]. The discount was confirmed by the account owner in an email to the customer's procurement lead on Feb 18, 2026 [S2].",
  "verification": {
    "status": "verified",
    "claims": [
      { "text": "a 12% renewal discount ... effective the FY27 term", "verdict": "supported", "span": "S1" },
      { "text": "confirmed ... in an email ... on Feb 18, 2026", "verdict": "supported", "span": "S2" }
    ]
  }
}

S1 traces to the OPPORTUNITY record's discount field in Salesforce, at the byte span holding the approved value. S2 traces to the exact paragraph of the Exchange email where the account owner confirmed the number to the customer. Both spans are clickable back into Salesforce and Outlook behind their own logins. Neither claim is a paraphrase of what the rep remembers, both are matched against the actual source bytes at generation time, per the verified-answers loop.

If the commitment had been ambiguous

If the email had said "we'll do something in that range" with no pinned figure, ingestion would apply a best-guess and open a clarification: a one-tap card to the account owner asking to confirm the number, and any answer generated in the meantime would carry an explicit caveat rather than stating the figure as fact.

Evidence and permissions

  • Provenance. Every commitment, term, and stage value carries provenance to the exact span in the CRM record, email, or document it came from, so a generated answer's citation is never "somewhere in Salesforce," it is the field or paragraph.
  • RBAC from Entra groups. Access to account and opportunity data is deny-by-default, mapped from your IdP groups. A rep who is not on the account team sees nothing for that account, not a redacted version of it.
  • Field-level encryption. Fields declared classified (contract pricing exceptions, named individual compensation terms) are encrypted in the app layer before core ever stores them, and are excluded from indexing and vector search as a result.
  • Corrections don't erase the record. When a deal term is corrected (a discount renegotiated, a stage rolled back), the prior version stays reconstructable at its original transaction time, so "what did we tell the customer before the correction" remains answerable.