Five Teams Asked for an Export. They Did Not Ask for the Same Thing.

November 12, 2026

Anna with Oppy | November 12, 2026

An export button sounds wonderfully specific. Until you ask what happens after someone clicks it.

A mortgage team wants a borrower update. A title team wants reconciliation rows. A property manager wants a vendor's assigned jobs. A brokerage wants a client-ready PDF. Another brokerage cannot find the print option that already exists.

Those are fictional practice examples, not customer findings. Put them in one ticket called “Improve exports,” and you have organized the vocabulary. The work remains a small administrative swamp.

The useful AI job comes before backlog creation: group requests by the outcome people need, then explain which requests should stay apart.

Fresh housing data, familiar grouping trouble

In HousingWire's November 11 analysis, October new pending listings rose 20.2% year over year across Florida's Deltona-Daytona Beach-Ormond Beach metro. Inside that same metro, Ormond Beach rose from 72 to 156, while Deltona fell from 136 to 103.

These are single-family listings newly entering pending status, not completed sales. The October comparisons use five weekly reporting periods in each year, with data available through November 6. The article does not provide a raw dataset or complete MLS coverage details.

The metro result does not describe every city's direction. Software feedback presents an analogous grouping problem: the shared label can be accurate while hiding the distinctions needed for a decision. Before summarizing a request, ask whether something is missing, broken, hard to find, or unexplained. Preserve the possibilities rather than calling every complaint a training problem.

Build a Request Taxonomy Desk, not an export factory

This is a proposed three-oppy operating design, not a released Oppy template or verified automatic deduplication feature.

Oppy's April 21 creation walkthrough describes separate configured roles and uploaded knowledge. Its April 24 Meeting Intelligence walkthrough describes searchable transcripts saved in Conversations. Neither establishes automatic coordination among the roles below.

For this pilot, a person supplies approved excerpts and manually carries each output to the next role. No new meeting capture is required. Keep borrower details, title documents and tenant records out of the practice set. Use fictional material first, then only redacted excerpts authorized for this specific review.

1. Request Reader: preserve what was actually said

Give the Reader one excerpt per row, with a request ID, approved case ID, source location and date. Its output records exact wording, intended recipient, desired outcome, required fields, stated constraints and unanswered questions.

Mark an outcome unknown if the speaker never explains it. “Export” is a request, not an explanation.

Count distinct approved cases separately from mentions. One person repeating the request in three meetings is not automatically three customers.

2. Problem Grouper: cluster the work, not the noun

The Grouper receives the reviewed rows. It proposes clusters using the recipient's next action and the stated constraints.

For each cluster, return included IDs, excluded IDs, supporting source text, unknowns and a question that could change membership. Suggest a provisional route: feature investigation, defect investigation, usability help, or clarification. Do not assert that a feature exists without an approved capability note.

3. Merge Challenger: find the reason to keep requests separate

The Challenger receives the proposed clusters and original excerpts. Its job is to expose incompatible recipients, fields or permissions, plus requests the Grouper separated despite matching outcomes.

A different role is not independent verification. It is a second check against the same evidence. A human still accepts, splits or rejects the grouping.

Five fictional excerpts, several different jobs

Use these invented statements as a practice set, each attributed to its fictional requesting team:

M1, mortgage operations: “Export a PDF of approved milestones for the borrower, without internal notes.”
T1, title accounting: “Export transaction IDs, dates and amounts as CSV so we can reconcile our ledger.”
P1, property management: “Export only the open work orders assigned to this vendor, not the whole portfolio.”
B1, brokerage coordination: “Export approved milestones as a client PDF, without internal notes.”
B2, brokerage support: “I cannot find the existing print option.”

M1 and B1 are candidates for a shared problem cluster: a recipient-safe milestone document. That does not mean their systems, fields or approvals are interchangeable. Record those unknowns before anyone specifies a solution.

T1 needs structured reconciliation data. P1 needs an assignment-scoped work list. Neither belongs in the milestone-PDF cluster just because all three request exports.

B2 needs investigation against the approved capability note. The invented phrase “existing print option” is not proof of a real product feature.

A useful candidate issue reads: Investigate client milestone PDF: M1 and B1 included; T1, P1 and B2 excluded; confirm required fields, source systems and recipient permissions. No engineering commitment has been made. The noun survived, but it no longer runs the meeting.

Copy this blueprint

Job: Prepare request clusters for human review. Draft only.
Inputs: approved excerpts with request_id, case_id, source,
 date, exact wording; optional approved capability notes.
Reader output: wording, recipient, next action, required
 fields, constraints, unknowns. Cite source for every inference.
Human gate: accept or correct rows before grouping.
Grouper output: proposed problem, included/excluded IDs,
 evidence, provisional route, question that changes membership.
Challenger output: unsafe merges, missed matches, unsupported
 interpretations, each checked against original excerpts.
Final gate: named owner accepts, splits, rejects or requests
 clarification. Human creates any backlog item manually.
Never send messages, change records or promise delivery.
Missing evidence stays unknown. Repeated mentions are not
 additional cases. Similar wording is not sufficient to merge.

These instructions are not access controls. Do not connect outbound messaging, calendar-write or backlog-write tools for the pilot. If the setup cannot isolate the experiment, keep it on fictional inputs without production access.

Measure bad merges, not tidy tickets

In his November 11 AI Today in 5 public video, Thomas Fox says:

“Evaluating AI ROI is not straightforward.”

The line appears in the public caption cue at 00:39 to 00:44. Here, ticket count would make it positively misleading.

Have a human label a fixed practice set before reviewing the agent's proposals. Treat each merge as a pair of requests joined. Record incorrect merges over proposed pairwise merges reviewed, missed matches over human-labeled matching pairs, and unsupported interpretations over extracted interpretations reviewed. Report counts with denominators, including rejected work. A zero denominator means no rate.

Time the human review and correction. Compare with manual grouping of a comparable set under the same acceptance rules. Do not call fewer tickets time saved unless the review earns that claim.

Start with Oppy and one approved request set. Keep the backlog button human until the groups deserve to exist.