Legal service request intake is the structured entry point through which employees across a business ask their in-house legal team for help. It replaces the emails, calls, and corridor conversations that legal departments have traditionally absorbed, capturing each request as a categorized record with the information a lawyer needs attached from the start. The configuration decisions taken during an intake build determine how much of that promise the business actually experiences, and this article covers the ones that matter.
What does building legal service request intake involve?
Building legal service request intake means designing the entry points, forms, conditional logic, and routing that turn an ask for legal help into a structured record. For context, in a 2025 survey of in-house legal teams, 54 percent named streamlining intake and matter management as a top priority. The definition of a legal service request, the common request types, and how one moves to closure are covered separately in what a legal service request is.
This article covers the configuration side. Six decisions carry most of the outcome: how many front doors the department needs, how conditional logic keeps each form short, what breaks across languages, how routing resolves without human triage, which fields determine future reporting, and how the first weeks after go-live are staffed.
Why does legal service request intake matter now?
Legal service request intake matters now because demand on legal departments is rising while headcount stays flat. CLOC’s 2026 State of the Industry Report, based on the 2025 Harbor Law Department Survey, describes a structural productivity gap in which workload surges in complex areas while budget and headcount growth flatten, with regulatory compliance demand cited by 63 percent of departments and cybersecurity by 58 percent.
A department absorbing more work with the same people has two options. It can push low-risk work downstream through self-service, and it can remove the administrative overhead of chasing information on the work that does reach lawyers. Structured intake delivers both, which explains why legal operations guidance consistently places it early in a maturity roadmap.
How many front doors does a global legal department need?
A global legal department usually needs several front doors, because one form cannot serve every region, language, and matter type without becoming unusable. Deciding the number is a scoping exercise carried out before configuration begins.
On one legal service request implementation, Basla built eight separate intake front doors covering language and country variations within a single deployment. Four factors drove that count.
- Language. Business users complete forms accurately in their working language, and translation applies to field labels, help text, and validation messages.
- Jurisdiction. Local legal requirements change which questions must be asked and which are irrelevant.
- Matter type. A contract review request and a litigation hold request need different questions entirely.
- Business unit. Routing, approval thresholds, and mandatory fields often vary by division.
Front door count carries a maintenance cost, so the aim is the smallest number that keeps each form short and relevant. Conditional logic reduces the count considerably, which is why it belongs in the design conversation early.
How does conditional logic keep intake forms usable?
Conditional logic keeps intake forms usable by showing each business user only the questions their situation requires. A form that asks everything of everyone gets abandoned, and abandoned forms send work back to email.
The design principle is progressive disclosure. Ask the request type first, then reveal the fields that type requires. A contract review request opens questions about counterparty, value, and term. A litigation hold opens questions about custodians and date ranges. The user experiences a short form while the department captures complete data.
Rule complexity accumulates quickly at enterprise scale. On one program, Basla configured more than fifty custom business rules, including compound conditional actions where several conditions resolve together before the platform acts. The reasoning behind that approach appears in why workflow automation fails without conditional logic, and the interface implications in conditional UI architecture for legal intake at scale.
What breaks when intake spans multiple languages?
Multi-language intake breaks in the places teams forget to translate. Field labels get attention during design workshops, and several other elements routinely do not.
- Validation messages. An error message appearing in English on a Japanese form stops the user completely.
- Help text and tooltips. These carry the guidance that makes a form self-explanatory.
- Dropdown values. Picklist options need translating alongside the labels above them.
- Notification templates. Confirmation and status emails reach the requester, so they need the same treatment.
- Date and number formats. Regional formats affect both display and validation behavior.
Testing has to cover each language with a user profile from that region, because a form rendered correctly for an administrator in one locale can behave differently for a business user in another. That principle extends across configured platforms, as covered in why skipping role-based security testing breaks go-lives.
How should legal request routing be configured?
Legal request routing should be configured from the answers the intake form already collects, so the request reaches the right lawyer without a human triaging it first. Routing that depends on someone reading each submission reintroduces the delay the front door was built to remove.
Four inputs carry most routing decisions: matter type, business unit, jurisdiction, and a value or risk threshold. Each needs a defined owner and a defined fallback for submissions that match no rule, because unrouted requests sit unnoticed until someone chases them.
Two behaviors deserve explicit configuration and testing. Reassignment, meaning what happens when the first recipient is the wrong one, and absence handling, meaning where a request goes when the assigned lawyer is on leave. Both surface in the first month of live use, and both are cheaper to design than to retrofit.
What does intake design mean for matter data quality?
Intake design determines matter data quality permanently, because every downstream report draws on fields the intake form captured. A department that omits business unit at intake cannot report spend by business unit later without a remediation project.
Three fields repay attention during design. Matter type drives categorization and therefore every workload analysis. Business unit or cost center drives spend allocation. Requested-by and requested-for identify who asked and who benefits, which frequently differ.
Reporting quality also depends on consistency over time. Changing a picklist six months after go-live splits historical data across old and new values, which is why the initial taxonomy deserves proper attention.
What happens after a legal front door goes live?
A legal front door generates a predictable wave of questions in its first weeks, because business users are meeting a new process at the moment they need legal help. Planning that support keeps the configuration team available for genuine defects.
On one enterprise legal platform rollout, Basla’s delivery team handled roughly two hundred tickets in the first week after go-live. Around sixty percent were users asking how to complete a task, and the balance were genuine defects requiring a developer. The hypercare window ran for eight weeks with every report triaged before anything reached the configuration team, a model described in why launches fail without a dedicated hypercare triage desk.
Adoption deserves separate attention from support. Business users who find the form confusing will revert to emailing a lawyer they know, and that behavior is difficult to reverse once it establishes. Watching submission volumes by business unit in the first month shows quickly where adoption is holding and where it needs intervention.
Conclusion
Legal service request intake succeeds when the business finds it easier than sending an email. Every design decision serves that test, and departments that treat intake as a form-building exercise tend to produce something complete for legal and burdensome for everyone else.
Five decisions shape the outcome. Scope the number of front doors deliberately against language, jurisdiction, matter type, and business unit. Use conditional logic so each user sees a short form while the department captures full data. Translate validation messages, help text, dropdown values, and notifications alongside the field labels. Configure routing from the answers the form already holds, with a defined owner and a fallback for every path. And settle the matter taxonomy before go-live, because changing it later splits your reporting history.
How Basla can help
Basla provides delivery teams for legal intake and request management software implementation, covering legal technology consulting, business analysis, intake and workflow configuration, testing coordination, documentation, and post-go-live support. Basla has delivered legal technology across more than a hundred jurisdictions, with hands-on experience supporting Onit legal service request, matter management, eBilling, and contract workflows.
Frequently asked questions
What is legal service request intake?
Legal service request intake is a structured entry point through which employees across a business submit requests to their in-house legal team. It captures each request as a categorized record with the required information attached, replacing scattered emails and calls with a single route the department can track and report on.
How many intake forms does a legal department need?
Legal departments generally need several forms, scoped against language, jurisdiction, matter type, and business unit. One implementation covering multiple countries and languages used eight separate intake front doors within a single deployment, and conditional logic reduces the count by revealing only relevant questions.
Why do legal intake forms fail?
Legal intake forms fail when they ask every user every question, which makes completion slow enough that people revert to email. They also fail when translation covers field labels while leaving validation messages, help text, dropdown values, and notification templates in the original language.
How should legal requests be routed automatically?
Legal requests should be routed from the answers the intake form already collects, using matter type, business unit, jurisdiction, and a value or risk threshold. Every routing path needs a named owner, and submissions matching no rule need a defined fallback so nothing sits unnoticed.
What data should a legal intake form capture?
A legal intake form should capture matter type for categorization, business unit or cost center for spend allocation, and both requested-by and requested-for, since those frequently differ. These fields determine what the department can report on afterwards, and adding them retrospectively requires a remediation project.
What support does an intake build need after go-live?
An intake build needs a triage layer for its first weeks, because most early reports are users asking how to complete a task instead of genuine defects. On one enterprise rollout roughly two hundred tickets arrived in the first week, around sixty percent of them questions, and an eight-week hypercare window with every report triaged first kept the configuration team available for real defects.
*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.*