Check which deal an email actually supports

Setup requirements

1. The CRM owner provides a permitted deal-ID dictionary and account/site boundaries. The reviewer has no authority to broaden email or deal visibility.

2. Distinguish message-level relevance from contact affiliation. A shared contact, current owner or recent date is insufficient to prove a message belongs to a deal.

3. Before any pilot, confirm an actual unresolved need and approve minimized copies, processing environment, retention and recipients. This design does not authorize execution.

Inputs and access

1. Name

   deal_scope.csv

   Source or owner

   Revenue operations owner

   Scope

   Opaque deal IDs, approved project/site references, allowed stakeholder tokens, active intervals and explicit scope descriptions.

   Sensitivity

   Synthetic fixture only. Real commercial, personal, location or financial records need approved minimization and handling. No credentials are required.

   Permission needed

   Specific owner approval before any real-data pilot; no live access, uploads or external transmission authorized.

2. Name

   message_excerpts.json

   Source or owner

   Authorized mailbox or CRM custodian

   Scope

   Synthetic message IDs, timestamps, subject/body excerpts and current association IDs; exclude attachments and unrelated threads.

   Sensitivity

   Synthetic fixture only. Real commercial, personal, location or financial records need approved minimization and handling. No credentials are required.

   Permission needed

   Specific owner approval before any real-data pilot; no live access, uploads or external transmission authorized.

3. Name

   association_rules.json

   Source or owner

   CRM owner

   Scope

   Permitted identifier matching, multi-deal handling, restricted-field rules and a reviewer-provided scope dictionary.

   Sensitivity

   Synthetic fixture only. Real commercial, personal, location or financial records need approved minimization and handling. No credentials are required.

   Permission needed

   Specific owner approval before any real-data pilot; no live access, uploads or external transmission authorized.

Human approval boundaries

1. Before a pilot, the accountable owner approves exact synthetic/minimized copies, processing environment, retention and allowed recipients.

2. Owner validates identity mappings, authority, status definitions and all unresolved evidence.

3. Any source mutation, account access, upload, external communication, commercial commitment, payment or changed permission requires separate appropriate authorization.

The problem

Emails attached to several open deals can make unrelated deal histories appear complete and expose irrelevant commercial context.

Suggested task

Evaluate permitted email excerpts against explicit deal identifiers and scope evidence, then produce a proposed association map with ambiguity and access boundaries.

What you could produce

A message-to-deal evidence matrix and restricted exception queue; no CRM associations are changed.

Why an agent / simpler alternative

Mixed narrative and structured evidence can benefit from assisted extraction and explanation. Identity joins, interval calculations and totals require deterministic checks. A supported native report, query or spreadsheet is preferable when it answers the owner’s question reliably.

When this work comes up

Role

Revenue operations coordinator

Trigger

A handoff or deal review includes a contact with several simultaneous opportunities.

Human approval

Owner approves scope, rules and evidence interpretation. Any operational action requires separate appropriate authorization.

Finished output

A message-to-deal evidence matrix and restricted exception queue; no CRM associations are changed.

Proposed evaluation scope — no pilot authorized

Scope

One account, no more than five concurrent deals and 40 synthetic message excerpts; no attachments or live mailbox access.

Limit origin

Editorial evaluation bound, not a verified platform limit.

Overflow action

Stop and ask for approved partitioning; no silent truncation.

Pilot authorized

No

Evidence boundary

Firsthand reports establish stated friction or concerns only. O*NET provides duty context. Official documents establish limited native features or general primitives. This workflow, safeguards, fixtures and outputs are original proposals, not source-documented executions.

Proposed steps

1. 1

   Freeze the selected deal catalogue, permitted message excerpts and association snapshot; reject any source outside the authorized account boundary.

   Output: association_input_manifest.json

   Expected output: association_input_manifest.json

   Checkpoint: Every message ID and source span is accounted for; omitted restricted content is recorded without reproducing it.

   Approval gate: Owner approves exact scope, copies and rule definitions before any pilot.

2. 2

   Extract explicit project references, order identifiers and site names from each allowed message, keeping quoted history separate from newly written text.

   Output: message_reference_evidence.csv

   Expected output: message_reference_evidence.csv

   Checkpoint: A reference copied in a forwarded thread is not automatically evidence of the current message’s purpose.

   Approval gate: Owner resolves ambiguous source language and evidence authority.

3. 3

   Create candidate edges only from owner-approved exact identifiers or explicit contextual matches; retain multiple candidates when the text addresses several projects.

   Output: candidate_deal_edges.csv

   Expected output: candidate_deal_edges.csv

   Checkpoint: Shared people and recency are weak context, never sufficient association keys.

   Approval gate: Owner approves identity mappings and unresolved joins.

4. 4

   Compare candidate edges with the existing association snapshot and classify supported, unsupported, multiple or unresolved relationships.

   Output: association_difference_matrix.csv

   Expected output: association_difference_matrix.csv

   Checkpoint: A missing identifier produces abstention; the model must not invent a most-likely deal to fill the row.

   Approval gate: Owner validates the rule and calculations; no live decision is implied.

5. 5

   Prepare reviewer questions for contradictory references, reused order numbers and permission-limited evidence; separate evidence uncertainty from access restrictions.

   Output: association_exception_queue.csv

   Expected output: association_exception_queue.csv

   Checkpoint: An inaccessible message is not labelled irrelevant, and confidential text is not copied into a wider review packet.

   Approval gate: Owner reviews exceptions and accepts unresolved status where evidence is insufficient.

6. 6

   Deliver the reviewed-scope matrix, source citations and a proposed manual correction list, retaining all original associations in the snapshot.

   Output: deal_email_review.json

   Expected output: deal_email_review.json

   Checkpoint: The artifact is advisory; any relinking, deletion, access change or communication requires separate authorization.

   Approval gate: Owner accepts the separate draft artifact; all live actions require separate authorization.

Original starter prompt — proposed

Origin

editorial_proposal

Execution authorized

No

Text

Using only {approved_synthetic_inputs} and {owner_rules}, Evaluate permitted email excerpts against explicit deal identifiers and scope evidence, then produce a proposed association map with ambiguity and access boundaries. Follow the six-step design. Preserve exact identities, evidence spans, explicit policy boundaries and uncertainty. Use inspectable deterministic comparisons. Write only separate draft review artifacts described by the output schema. Stop for missing authority, ambiguous evidence or out-of-scope data. Do not change source records, contact anyone, access live accounts, upload files, post transactions or execute any recovery action.

Expected output schema — proposed

Primary key

1. message_id

2. candidate_deal_id

Columns

1. message_id

2. candidate_deal_id

3. current_association

4. evidence_type

5. new_text_span

6. quoted_history_span

7. relationship_status

8. access_boundary

9. reviewer_action

Record status

draft_review_only

Common provenance columns

1. input_snapshot_id

2. rule_version

3. source_document_id

4. source_row_or_span

5. reviewer_decision

Unknown value policy

Unknown values remain null, not zero. Keep raw identities and evidence. Unresolved rows do not silently enter approved totals.

Synthetic output illustration — not an executed result

Label

Synthetic authored example, not observed output

Synthetic

Yes

Executed

No

Input

Deals

1. Id

   D-A

   Project

   ALPHA

   Po

   450

2. Id

   D-B

   Project

   BETA

   Po

   451

Messages

1. Id

   M1

   Text

   For ALPHA, PO450, confirm delivery.

   Existing

   1. D-A

   2. D-B

2. Id

   M2

   Text

   Thanks for today.

   Existing

   1. D-A

3. Id

   M3

   Text

   Please compare PO450 and PO451.

   Existing

   1. D-A

4. Id

   M4

   Restricted

   Yes

   Text not supplied

   Yes

   Existing

   1. D-B

Expected

M1

Supported

1. D-A

Unsupported existing

1. D-B

M2

Status

unresolved

Supported

Not specified.

M3

Supported

1. D-A

2. D-B

Status

multiple_explicit

M4

Status

restricted_not_evaluated

Limits

1. Original proposed and untested design; no source documents this complete agent workflow.

2. A reported problem is not proof of prevalence, willingness to pay, harm magnitude or current demand.

3. Historical product reports require current-installation checks; a current capability document only establishes general primitives.

4. Native reports or a deterministic script may be simpler. Exports, identity mappings, context size, privacy controls and actual tool compatibility remain untested.

5. Numerical fixtures are synthetic and have not been executed. Owner review is necessary; no time saving, cost saving or revenue outcome is asserted.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

   1. Read supplied text and files, compare evidence and calculate transparent checks in an owner-approved environment.

   Capability source urls

   1. https://learn.chatgpt.com/docs/get-started-with-work

   Workflow compatibility

   Untested. Requires an owner-approved file-processing environment; no CRM, ERP, payment or transport connector is assumed.

Failure modes

1. A subject contains an old deal code while the new body discusses a different project.

2. Two deals reuse the same external reference.

3. A message addresses both opportunities or contains restricted quoted content.

Recovery and troubleshooting

1. Signal

   A subject contains an old deal code while the new body discusses a different project.

   Recovery

   Mark the subject/body conflict and request reviewer interpretation; do not use keyword count to choose.

   Resume condition

   The accountable owner supplies authoritative evidence or an explicit rule; otherwise retain the affected row as unresolved.

2. Signal

   Two deals reuse the same external reference.

   Recovery

   Require an additional approved site or contract identifier and retain both candidates until resolved.

   Resume condition

   The accountable owner supplies authoritative evidence or an explicit rule; otherwise retain the affected row as unresolved.

3. Signal

   A message addresses both opportunities or contains restricted quoted content.

   Recovery

   Preserve a multi-deal classification for permitted text, or withhold content and route the access decision to its custodian.

   Resume condition

   The accountable owner supplies authoritative evidence or an explicit rule; otherwise retain the affected row as unresolved.

Unexecuted validation plan

Sample setup

Deals

1. Id

   D-A

   Project

   ALPHA

   Po

   450

2. Id

   D-B

   Project

   BETA

   Po

   451

Messages

1. Id

   M1

   Text

   For ALPHA, PO450, confirm delivery.

   Existing

   1. D-A

   2. D-B

2. Id

   M2

   Text

   Thanks for today.

   Existing

   1. D-A

3. Id

   M3

   Text

   Please compare PO450 and PO451.

   Existing

   1. D-A

4. Id

   M4

   Restricted

   Yes

   Text not supplied

   Yes

   Existing

   1. D-B

Acceptance checks

1. The output identifies the unsupported M1-to-D-B edge without deleting it.

2. M2 remains unresolved despite having an existing D-A association.

3. M3 preserves both supported projects.

4. M4 exposes no message text and makes no relevance judgment.

5. Every conclusion traces to a source row or explicitly labelled owner rule; identical frozen inputs preserve identities and deterministic totals.

6. All source copies remain unchanged; no business workflow or synthetic acceptance evaluation has been run.

Stop conditions

1. Required identity, source coverage, calculation policy or owner authority is missing.

2. Unexpected real sensitive data is supplied without approved handling.

3. Requested work would require live access, upload, external communication, accounting posting, payment, permission change or irreversible action.

Executed

No

Fixture status

Designed specification and separately authored answer key only. No model run, numerical acceptance execution or customer pilot performed.

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Plan access, model usage, tool runtime and storage costs unknown.

2. Export preparation, evidence cleanup, review and correction effort unmeasured.

3. No native integration, paid service, new account or software installation assumed.

4. Case-specific effort is unknown: source extraction, identity repair, owner-rule preparation, fixture design and review may dominate model cost.

5. The case requires owner preparation of 3 input groups and review of 6 intermediate/final artifacts. Costs and effort remain unmeasured; these are design counts, not runtime estimates.

Caveat

No measured time saving, current demand, ROI or price claim. Compare the simpler remedy first.

Canadian adaptation — proposed

Verify local privacy and organizational record-handling requirements before any real-data pilot; preserve original currency, business calendars and time zones. No Canadian deployment or compliance claim.