Legal Service Request vs Legal Intake: The Difference

Your vendor says intake, your GC says front door, and the project plan says LSR. What each term actually means, where they overlap, and which one belongs in your documentation.

Legal service request vs legal intake is a distinction most departments stop drawing, because the two terms describe closely related things and get used interchangeably often enough that the difference stops registering. A legal service request is the item submitted. Legal intake is the process that captures it. The distinction is small in conversation and consequential in a requirements document, where an ambiguous term produces a configuration nobody agreed. This article covers what each term means, where the boundary sits, and how the rest of the vocabulary in this area fits around them.

What is a legal service request?

A legal service request is a single unit of work submitted to the legal department, recorded with a category, an owner, a status, and a timestamp. For context, in a 2025 survey of in-house legal teams, 54 percent named streamlining intake and matter management as a top priority. The numbers bear this out: a 2024 operations index found 79 percent of law departments saw the volume of legal work increase over the past year. It is a noun, describing the thing that exists after someone asks for help.

Each request carries the information a lawyer needs to begin, and persists as a record the department can report on. That record is what turns invisible demand into measurable workload, covered in more detail in what a legal service request is.

Onit and other platform vendors use LSR as a product capability name, which is one reason the term appears more often in enterprise legal departments than in law firms.

What is legal intake?

Legal intake is the process by which requests reach the legal department, covering the forms, the routing rules, and the handling that turns an ask into a structured record. It is a process noun, describing how requests arrive. The request itself is the artifact that process produces.

Three components make up an intake process. The entry points where requests are submitted, the conditional logic determining what each requester is asked, and the routing that sends the result to the right person. The design and configuration of those components is covered in building legal service request intake.

The term travels more widely than LSR does, appearing in law firm client intake and legal aid contexts where the meaning differs considerably.

Where does the boundary between them sit?

The boundary sits between the process and the artifact it produces, which means the two terms answer different questions. Legal intake answers how work arrives, and a legal service request is what arrives.

The practical test is whether the sentence still makes sense with the other term substituted.

  • “We received 400 legal service requests last month” works, since requests are countable items.
  • “We received 400 legal intakes last month” reads oddly, because intake is the process.
  • “Our legal intake process routes by matter type” works, since routing is part of the process.
  • “Our legal service request routes by matter type” describes one item, and probably means the process.

Substituting freely is harmless in conversation. In a requirements document it produces scope arguments during user acceptance testing.

Why does the terminology vary so much?

Terminology varies because vendors name capabilities differently and each name travels with its platform into the departments that adopt it. Nobody standardized the vocabulary, and three separate traditions feed into it.

Enterprise legal management platforms brought legal service request as a module name. Service management thinking brought legal ticketing, borrowed from IT service desks. And the legal operations community brought legal front door, describing the same capability from the business user’s perspective.

Legal operations leaders increasingly describe using technology to provide a portal that connects the business with its lawyers, replacing the disjointed process that typically precedes one. That description covers intake, requests, and self-service together, which is why front door has become the umbrella term in legal operations conversation.

How do the related terms fit together?

The related terms describe different layers of the same capability, and mapping them once prevents repeated confusion.

  • Legal front door. The whole entry point as the business user experiences it, including self-service content. Covered in what a legal front door is and why adoption fails.
  • Legal intake. The process capturing and routing requests.
  • Legal service request. The individual item produced.
  • Legal ticketing. The same territory described in service management language, common where legal sits close to an IT service function.
  • Matter intake. The narrower process of opening a matter, which frequently follows a request and rarely replaces one.
  • Contract intake. Intake specific to contract requests, carrying its own fields for counterparty, value, and governing law.

Contract intake diverges enough to need separate design attention in multinational departments, covered in contract intake design across regions and languages.

Which term should a legal department use?

A legal department should choose one term for each layer and apply it consistently across requirements, configuration, training, and reporting. Which term matters far less than the consistency does.

Two practical considerations guide the choice. Platform vocabulary is worth matching where possible, since configuration screens, documentation, and vendor support will all use the vendor’s names, and fighting that creates translation work forever. And business-facing language should favor whatever the business already understands, which is usually the plainest option available.

A short glossary at the front of the requirements document resolves most of it. Defining the terms once, in writing, costs ten minutes and prevents the meeting where two people discover they scoped different things.

Does the distinction affect implementation?

The distinction affects implementation wherever scope is written down, because the two terms imply different deliverables. A statement about legal intake describes forms, logic, and routing. A statement about legal service requests describes records, fields, statuses, and reports.

Three places reward precision.

  • Requirements. “Configure legal intake” and “configure the legal service request record” are different pieces of work.
  • Testing. Intake tests exercise submission and routing, while request tests exercise the record, its statuses, and its reporting.
  • Reporting. Volume metrics count requests, and cycle time metrics measure the process.

The sequence in which these get built is itself a decision, covered in intake first or matters first.

Conclusion

Legal service request vs legal intake is a distinction close enough to ignore in conversation and sharp enough to matter in writing. The request is the item, the intake is the process, and the front door is how the business experiences both.

Two things follow for a department introducing structured requests. Pick one term per layer and use it everywhere, including in the requirements document, the configuration, the training material, and the reports, because consistency costs nothing and ambiguity costs a scope argument during testing. And write the glossary before the requirements, since the ten minutes spent defining terms is the cheapest risk reduction available on the whole program.

A pilot on one request type, proving the structure on limited scope first, settles these questions in practice.

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 the difference between a legal service request and legal intake?

A legal service request is the individual item submitted to the legal department, carrying a category, owner, status, and timestamp. Legal intake is the process that captures and routes it, covering the forms, conditional logic, and routing rules. The request is what arrives, and intake is how it arrives.

Are legal service request and legal intake the same thing?

They describe the same capability from different angles and are frequently used interchangeably in conversation. The difference becomes consequential in requirements documents and test plans, where an ambiguous term can produce a configuration nobody agreed to.

What does LSR stand for?

LSR stands for legal service request. The abbreviation appears most often in corporate legal departments, partly because enterprise legal management platforms use it as a module or capability name.

What is the difference between legal intake and a legal front door?

Legal intake is the process capturing and routing requests. A legal front door is the whole entry point as the business user experiences it, including self-service content alongside the intake forms. Front door has become the umbrella term in legal operations conversation.

Is legal ticketing the same as legal intake?

Legal ticketing describes the same territory in service management language, borrowed from IT service desks. The term is more common where the legal function sits close to an IT service organization or uses a shared service management platform.

Which terminology should a legal department standardize on?

A department should pick one term per layer and apply it consistently across requirements, configuration, training, and reporting. Matching the platform’s vocabulary reduces translation work, and business-facing language should favor whatever the business already understands.


*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.*