If you work in a corporate legal team or an in-house IP department, you already have plenty on your plate: managing a global portfolio, keeping up with filings, handling enforcement. But there's one process that quietly eats up more time than it should, and it's not even close to the work you were hired to do. It's creating and managing Requests for Proposal for IP legal services.

Think about how most RFPs actually get done today. Someone drafts a document, emails it around for input, sends it out to a handful of firms, then waits. Proposals come back in different formats. Comparisons happen in spreadsheets. Follow-ups get buried in inboxes. There's no single place where the whole process lives, and if someone asks six months later why a particular firm was selected, good luck piecing that together.

It's not that any single step is broken. It's that the whole workflow is held together with duct tape.

The visibility question

One of the first friction points is deciding who even sees the RFP. Sometimes you want to cast a wide net. Other times you already know which firms you want to hear from, or you've already picked someone and just need to formalize the instruction. Most of the time, the tooling doesn't care about these distinctions. You end up managing visibility through CC lines and separate email chains, which is about as reliable as it sounds.

Too many tools, not enough context

The traditional RFP process tends to be painfully sequential. One person drafts, another reviews, then it goes out, then providers ask questions, then you answer them one by one. Context gets lost at every handoff because every handoff happens in a different tool. The draft lives in Word, the discussion lives in email, the supporting documents live in a shared drive somewhere, and the timeline lives in someone's head.

By the time the RFP is actually out the door, half the team isn't sure what the final version said.

The proposal comparison problem

Here's a frustration anyone who's evaluated RFP responses will recognize: every firm structures their proposal differently. One gives you a detailed cost breakdown, another buries pricing in a narrative paragraph, and a third sends a PDF that looks like it was written for a different RFP entirely.

Trying to compare these side by side is an exercise in creative spreadsheet work. You end up spending almost as much time normalizing the responses as you did writing the RFP in the first place.

The handoff that loses everything

Even after you've picked a firm, the pain isn't over. Now you need to actually start the work, which means re-sending documents, re-introducing team members, re-explaining context, and hoping nothing important got lost along the way.

All the thinking, discussion, and decision-making that went into the selection process? It lives scattered across inboxes and file versions that nobody will ever look at again. The new matter starts from scratch, as if the RFP never happened.

It doesn't have to be this way

None of these frustrations are inevitable. They're the result of forcing a structured process through unstructured tools. When the RFP workflow is actually designed as a workflow (with collaboration, standardized responses, and continuity built in) the whole thing gets simpler.

Better process, better proposals, better outcomes. And more time for the work you actually care about.