Most legal-ops maturity frameworks in the consulting literature are designed for large enterprise legal departments: 30-plus attorneys, dedicated technology stack, vendor management programs, formal legal project management processes. They describe a kind of maturity that is aspirational for organizations where legal is a 3-person team supporting a 200-person company.
That gap matters because the teams that most need a clear maturity framework are typically the ones who cannot use the consulting-grade models. A two-attorney legal department with one operations associate handling intake, contracts, vendor management, and compliance does not have the bandwidth to run through a 50-page maturity assessment. They need to know: which specific things are broken, in what order should they be fixed, and how do they know when they have actually made progress.
This is our attempt at a practical maturity framework calibrated for that reality, built from what we observe when teams start using structured contract management for the first time.
Why Headcount and Budget Are Poor Maturity Indicators
The intuitive proxy for legal-ops maturity is resources. Bigger team, more tools, higher budget equals more mature. This proxy fails in both directions. We have seen three-person legal-ops teams running genuinely sophisticated processes, with clean intake, measurable cycle times, and accurate obligation tracking across 300 active agreements. We have also seen legal departments with 12 people and significant tool spend operating with no reliable intake system, no consistent SLA, and no way to answer the question "what is currently in the queue and who owns each item."
The correct maturity indicator is operational clarity. Can your team answer these questions reliably, without digging:
- How many contract requests came in last month, and what types were they?
- What is the current average cycle time from request to signed agreement, by contract type?
- How many active agreements are expiring in the next 90 days?
- Who owns each in-flight contract request right now?
- Which obligations from executed contracts are due in the next 30 days?
A team that can answer all five without hunting through email threads, spreadsheets, and shared drives is operating at a meaningfully different level than one that cannot, regardless of headcount.
Stage 1: Reactive Intake and Informal Tracking
The baseline stage is where most legal-ops functions begin, particularly in early-growth organizations where legal was initially handled by outside counsel or by the CEO and formal legal operations did not exist until relatively recently.
Characteristics: contract requests arrive by email or Slack with no standardized information. The attorney handling the request spends 15-20 minutes gathering the basic details they need before they can start drafting. There is no official queue. Work is prioritized by who asked most recently or most urgently. Cycle times are unknown because no one is measuring them. Executed contracts live in a shared drive with a folder structure that has evolved organically and is not consistently maintained.
This stage is not a failure. It is where most growing legal functions are when they first have to handle significant contract volume without a dedicated operations layer. The problem is that Stage 1 does not scale. When monthly contract volume reaches 20-30 requests, the lack of structured intake and tracking creates visible bottlenecks that the rest of the organization feels, even if they cannot name the cause.
The diagnostic question for Stage 1: if the person who owns contract management takes a two-week vacation, does the contract queue effectively stop? If yes, you are in Stage 1 regardless of how well the process appears to work day-to-day.
Stage 2: Structured Intake and Basic Cycle Time Visibility
The transition from Stage 1 to Stage 2 is primarily about intake. A structured intake form or process collects the information legal needs before a contract request enters the queue: counterparty name, contract type, deal value, relevant business unit, desired timeline, and any negotiation context. This removes the information-gathering overhead from the attorney's workflow and creates a consistent starting point for each request.
The secondary advance at Stage 2 is queue visibility. Someone, typically the legal ops manager or ops associate, maintains an active view of what is in the queue, who owns each item, and where things stand. This does not require sophisticated tooling. A shared spreadsheet with status fields and owner columns can serve this function if it is actively maintained. What matters is that the information exists and is accessible to the whole team, not just the person closest to a given request.
Cycle time measurement begins at Stage 2. Even rough measurement, such as recording the date a request was received and the date it was executed, provides the baseline data needed to identify where delays are occurring. Teams that have never measured cycle time tend to be surprised when they first do: the gaps between stages are often significantly longer than perception would suggest, and the pattern of delays often points clearly to a specific bottleneck (approval routing, counterparty negotiation, internal sign-off).
Stage 2 is achievable for most teams within 60-90 days of committing to it, without significant tool investment. The constraint is usually behavioral, not technical: the intake form only works if all requesters use it, and the queue visibility only works if it is maintained with discipline.
Stage 3: Obligation Tracking and Expiry Management
The advance from Stage 2 to Stage 3 is the transition from managing the contract process to managing what the contracts say. At Stage 2, legal-ops tracks requests through to execution. At Stage 3, it also tracks what happens after execution: which obligations are ongoing, when agreements expire, which renewal decisions need to be made and when.
This is where spreadsheet-based tracking starts to show its limits. A spreadsheet with 200 rows of active agreements and manually calculated renewal dates requires regular, disciplined maintenance to remain accurate. When agreements are amended, the spreadsheet needs to be updated. When a new agreement supersedes an old one, the old record needs to be marked inactive. The maintenance burden grows roughly linearly with portfolio size and tends to be deprioritized when the team is under pressure.
The Stage 3 capability that matters most is proactive alerting. Not just knowing when agreements expire, but having a process that surfaces upcoming expirations, notice deadlines, and recurring obligations early enough to act on them. A 90-day forward view of contract events should be a standing artifact that the legal-ops team reviews regularly, not a report someone generates reactively when a problem surfaces.
Stage 4: Data-Driven Process Improvement
Stage 4 is where the operational data collected in Stages 2 and 3 begins to drive decisions about process design. At this stage, the legal-ops team is not just measuring cycle time: it is analyzing where time is spent, identifying patterns in how different contract types or counterparty profiles perform, and using that information to improve templates, playbooks, and routing logic.
This requires that the data collected at earlier stages be structured and queryable. Cycle time by contract type. Negotiation round frequency by counterparty category. Approval delay patterns by approver and by department. These analyses are not complex statistically, but they require consistent data collection from the beginning, which is why the foundation work in Stages 2 and 3 is a prerequisite, not an optional step.
A team at Stage 4 can answer not just operational questions but strategic ones: where is legal spending disproportionate time relative to contract value, which agreement types would benefit most from standardized playbooks, and what approval workflow changes would reduce average cycle time. That level of insight is what allows a lean team to punch above its weight on throughput.
We are not saying that every team needs to reach Stage 4 to be effective. For organizations where total contract volume is manageable, Stage 2 or 3 may be entirely sufficient. The stage that matters is the one that addresses the current bottleneck, not the highest stage on a theoretical model.
Common Stalls and How to Move Through Them
The most common stall point is between Stage 1 and Stage 2: the intake form exists but is not consistently used. The cause is almost always that the form creates friction without visible payoff for the person submitting the request. Addressing this requires making the value proposition clear to requesters: structured intake reduces turnaround time because legal does not have to chase down information. When that value is demonstrated on a few requests, adoption tends to improve.
The Stage 2 to Stage 3 stall is usually about technical infrastructure: teams that have built a functional intake and queue system in spreadsheets find that obligation tracking requires either significantly more spreadsheet complexity or a purpose-built tool. The decision point is at roughly 100-150 active agreements. Below that, disciplined spreadsheet management is viable. Above it, the maintenance overhead begins to generate errors and requires a structural upgrade.
The Stage 3 to Stage 4 stall is a data quality problem. Teams that want to analyze cycle time patterns discover that their data collection was inconsistent: some requests have timestamps, others do not. Some contract types were tracked separately from others. Cleaning historical data is expensive. The forward fix is establishing consistent data collection at Stage 2 or 3 so that Stage 4 analysis is possible when the team is ready for it, rather than having to retrofit data quality retroactively.
Progress through these stages does not require a large-scale systems investment. It requires deliberate process design and consistent execution of each stage's core practices before moving to the next. The teams that try to leap from Stage 1 to Stage 4 with a major tooling investment typically end up with sophisticated software and immature processes, which is worse than where they started.