Multi-category legal intake is a request model in which business users choose the legal service they need from a short list of categories, then complete a form built for that category. A contract request asks about the counterparty and value, a privacy request asks about data and countries, and each one routes to the team that handles it. The result is better data at submission, fewer follow-up questions, and routing that works without a lawyer reading every request first.
What is multi-category legal intake?
Multi-category legal intake is a structured front door design that splits legal requests into service categories, each with its own template, required fields, attachments, and routing rules, while keeping every request in one central queue. It sits between a single generic form, which asks too little, and a maze of separate portals, which splits your data.
Most requesters see it as a set of tiles or options on the intake page: contracts, privacy, employment, and so on. Behind those tiles sit a shared lifecycle and a shared data model, so legal can still report on all demand in one place. The model builds on the difference between a legal service request and general legal intake, treating each category as its own service with its own rules. It is a common project: in a 2025 survey of in-house legal teams, 54 percent named streamlining intake and matter management as a top priority.
Which legal service categories should an intake portal offer?
An intake portal should offer the legal services your team actually delivers, described in the words business users use, usually six to ten categories in total. Each category should correspond to a distinct set of questions, a distinct routing destination, or both.
- Contracts and commercial. Commercial agreements, standard NDAs, procurement and supplier contracts, amendments, and renewals, often split into two or three tiles where volumes are high.
- Regulatory and people matters. Data protection and privacy, compliance and regulatory questions, and employment and HR matters, each routed to a specialist team.
- Corporate and disputes. Corporate governance and company secretarial work, intellectual property, property and real estate, and litigation, subpoenas, and investigations, plus a general legal request option for anything else.
Start from your own data. Pull a year of requests from email and existing systems, sort them by what was actually asked, and let the volume decide which services deserve their own category.
How many legal intake categories are too many?
Legal intake categories become too many when requesters can no longer tell two of them apart reliably. Above roughly ten top-level options, misclassification climbs and people fall back on the general category.
- Test with real users. Give five to ten business users a set of sample requests and ask them to pick a category. Where they split between two options, the categories are too close.
- Combine and split later. Merge categories users confuse, then separate them with a triage question or a conditional field after submission.
- High-volume exceptions. A standard NDA is easy to recognize, high in volume, and often suited to self-service, so it usually earns its own tile even though it is technically a contract.
What should each category-specific intake template contain?
Each category-specific intake template should contain the shared core fields plus the fields, attachments, and prompts that category needs for a specialist to begin work. Most templates end up with three to five core fields and three to eight category fields.
- Shared core. Requester and business unit, a short description, the business deadline with the reason for urgency, and the country or legal entity involved. These stay identical across categories so reporting works.
- Category fields. A contract template asks for contract type, counterparty, value, governing law, and signature deadline. A privacy template asks for data categories, countries involved, processing purpose, and whether an incident is under way.
- Attachments and guidance. Name the documents each category needs, such as the draft agreement or the notice received, and add short help text so requesters know what good looks like.
Keep the core fields in the same position and wording in every template. Legal intake form best practices for enterprises apply to each template individually.
How does conditional logic work inside an intake category?
Conditional logic inside an intake category shows additional questions only when an earlier answer makes them relevant, so the form stays short for simple requests and complete for complex ones. Three patterns cover most needs.
- Threshold questions. A contract request above a value threshold reveals questions on liability and approvals that a low-value request never sees.
- Branching by answer. A privacy request marked as an incident reveals breach-specific questions and an urgent flag. A routine privacy question skips them entirely.
- Missing information checks. The form flags gaps before submission, such as a contract request with no draft attached, so the requester fixes it while they still have the context.
Conditional UI architecture lets one form scale across request types without multiplying templates you then have to maintain.
How should category-based intake route requests to the right team?
Category-based intake should route each request by combining its category with business unit, country or entity, urgency, risk, and workload, then sending it to a team, a named owner, or a self-service path. The category narrows the destination, and the other variables pick the exact queue.
- Category to team. Privacy requests go to privacy counsel, employment to the employment team, and contracts to commercial, with regional splits where needed.
- Priority and risk. Urgent deadlines, high values, and regulatory or litigation indicators move a request up the queue or to a senior lawyer, with a triage window of one business day.
- Workload balance. Where several lawyers cover the same category, assign by rotation or current workload.
Keep routing rules in a governed table that legal operations maintains. Accepted requests can then be assigned an owner and converted into tracked matters, and the legal request triage process handles anything the rules cannot place.
How do you handle legal requests that fit more than one category?
Legal requests that fit more than one category are handled by letting the requester pick the closest option and allowing legal to reclassify the request at triage with a reason code. Asking business users to resolve legal overlap themselves slows them down and still produces errors.
A contract that raises a data transfer question, for example, starts in contracts, and the triaging lawyer adds privacy review or moves it, with the change logged. Where two teams both need to act, create a linked task or sub-request for the second team so the original stays intact.
Track the reclassification rate by category. A rate above about 10 percent for one category signals that its label or examples need work.
Who should govern the legal intake category taxonomy?
The legal intake category taxonomy should be governed by a named legal operations owner, with each category assigned to a lawyer who owns its questions, routing, and service levels. Changes should be requested, approved, tested, and released on a regular cadence, often monthly.
For each category, record its purpose, required fields, attachments, routing rules, approval thresholds, service level, and owner in one place. Review the taxonomy quarterly using volume, reclassification, and general-category data, and retire or merge categories that users avoid.
Watch the general legal request category. If it holds more than 10 to 15 percent of volume, requesters are telling you a common need has no obvious home.
How do you test and measure multi-category legal intake?
Multi-category legal intake is tested by running sample requests through every category and branch, then measured by how accurately requests land in the right category and queue. Testing proves the build, and measurement shows whether requesters understand it.
- Category test cases. Write 20 to 30 test cases per category covering each conditional branch, missing information check, attachment rule, and routing destination.
- User pilot. Run a two to three week pilot with 15 to 25 business users from different functions, and watch which categories they pick for real requests.
- Ongoing metrics. Track first-routing accuracy (target 90 to 95 percent), reclassification rate, general-category share, form completion, and follow-up for missing information, reported by category.
These sit alongside the wider legal intake KPIs that track volume, turnaround, and satisfaction. Watch volume per category closely, since a 2024 operations index found 79 percent of law departments saw the volume of legal work increase over the past year.
Conclusion
Multi-category legal intake works when categories match how the business asks for help and each one carries exactly the questions and routing it needs. Keep the list short, share the core fields across every template, use conditional logic for depth, let legal reclassify at triage, and govern the taxonomy with real data. Done well, the front door delivers complete, correctly routed requests from the first submission.
How Basla can help
Basla provides delivery teams for legal intake and request management software implementation, covering legal technology consulting, multi-category legal intake design, category templates and conditional logic, routing tables, taxonomy documentation, testing, and hypercare. Basla teams have built a legal service request implementation with eight front doors for language and country variations, each routing requests into a single shared lifecycle.
Frequently asked questions
What is multi-category legal intake?
Multi-category legal intake is a front door design in which requesters choose a legal service category and complete a form built for that category. Each category has its own fields, attachments, and routing, while all requests share one central queue.
How many categories should a legal intake portal have?
A legal intake portal usually works best with six to ten top-level categories. If users cannot reliably tell two categories apart, combine them and separate the work with a triage question.
What fields should every legal intake category share?
Every legal intake category should share core fields for the requester and business unit, a description, the business deadline with its reason, and the country or legal entity. Category-specific questions sit on top of that core.
Should NDAs have their own intake category?
NDAs usually deserve their own intake category because they are easy to recognize, high in volume, and often suitable for self-service with approved templates.
What happens when a legal request fits two categories?
When a legal request fits two categories, the requester picks the closest one and legal reclassifies it at triage if needed, logging the reason. Linked tasks can bring in a second team.
How do you know if intake categories are working?
Intake categories are working when first-routing accuracy stays at 90 to 95 percent, few requests are reclassified at triage, and the general category holds only a small share of volume.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*