Duplicate Request Detector & Merger

The problem this kills

Your intake form works a little too well. The same request comes in three times under three slightly different titles, from two different people, in the same month. Someone scopes it. Someone else scopes it again. A third person quietly starts building it. By the time anyone notices, you've burned a week of effort on work you only needed to do once.

Manual de-duping doesn't scale. Nobody can hold a 400-row backlog in their head, and "same outcome, different wording" is exactly the kind of match a human skims right past at 4pm on a Friday. So duplicates pile up, the backlog looks scarier than it is, and prioritization meetings get spent arguing about whether two items are really the same thing.

This tool does the tedious matching for you and leaves the judgment to a human. It reads your backlog, clusters the likely duplicates, and hands a backlog owner a tidy "here are the matches I found, which one survives?" review. Nothing merges until a person says so.

What you'll build

A small, private web app for your team that:

• Imports your backlog from a CSV or Google Sheet (title, description, requester, date, plus whatever else you track).
• Normalizes and fuzzy-matches the requests, grouping likely duplicates and near-duplicates into clusters based on similar wording, the same requester, and the same intended outcome.
• Presents each cluster for review so a backlog owner can see the matched items side by side, pick the surviving item, and either approve the merge or dismiss the cluster as a false match.
• Consolidates on approval only - merged-away items are linked to the survivor and kept in the audit trail, never silently deleted.
• Exports a clean, consolidated backlog as CSV in the exact columns your system expects.

What's inside the Implementation Plan

The plan is a single file you paste into Claude Code. It walks the AI through building the whole tool, step by step, with a ready-to-copy prompt at the end of each step.

Crucially, it opens by interviewing you about your business - your current intake process, the systems and sheets you use, the real field names and request-ID conventions in your data, your typical and peak backlog sizes, what actually makes two requests "the same," and your messy edge cases (recurring requests, parent/child tickets, requests that look identical but aren't). It reflects a short tailored spec back to you for a thumbs-up, then shapes the data model, the matching rules, and every later step around your answers. You get a tool fit to your backlog, not a generic template.

It also includes a "No API yet?" fallback: if you can't connect to your work-management system today, you import a sheet and export a clean CSV - so you can build and use this tool this afternoon regardless.

The governance it includes (this is the point)

This isn't a script that rewrites your backlog behind your back. Every safeguard a PMO needs is built in:

• Login, so only your team can open the tool.
• Row-level security, so each organization only ever sees its own backlog.
• A complete audit trail - who reviewed which cluster, who approved the merge, which items were merged away into which survivor, and when.
• A hard human-in-the-loop approval gate - the AI proposes clusters and a survivor, a backlog owner reviews and approves, and only then is anything consolidated. Never auto-merge.
• Duplicate guards keyed on the cluster signature, so the same proposed merge can't be processed twice.

Who it's for

PMO leads, backlog owners, and intake coordinators who own a request queue that grows faster than anyone can clean it - and who want the matching automated but the merging decision firmly in human hands.

You've got this - paste the first prompt and let the interview tailor it to your backlog.