Onit legal service request closure is the final stage of an intake workflow, where a request is completed, cancelled, merged, or converted into a matter, and the record becomes history you can report on. Every turnaround figure and outcome report depends on requests being closed the same way, with the same data, every time.
What is Onit legal service request closure?
Onit legal service request closure is the set of actions and rules that end a request’s life in the intake workflow and record how it ended. A request closes when Legal has resolved it, handed it into a matter, or decided it needs no further work.
Closure tells the requester their ask is finished, and it stops the clock on every time-based measure. Without closure design, requests sit open for months, closed records carry no outcome, and turnaround figures inflate.
What are the ways an Onit LSR can be closed?
An Onit LSR can be closed by completing it, converting it into a matter, cancelling it, or merging it into another request. Each path ends the request differently, and each needs its own rules.
- Completed. The lawyer answers the question or finishes the task inside the request. In Unity LSR, Quick Complete closes a simple ask in one step and requires an Outcome/Delivery entry.
- Converted to a matter. The request becomes a matter record when the work needs budgets, outside counsel, or long-running tracking, and the request closes with a converted outcome.
- Cancelled. Withdrawn or out-of-scope requests close with a required Cancel Reason and an optional comment the requester can see.
- Merged as duplicate. A repeated request is folded into a target request, so the work is counted once.
Decide which roles can use each path. Quick Complete and Cancel are usually limited to Intake Admins and assignees, so nobody closes a request before Legal has reviewed it.
What should be required before closing an Onit legal service request?
Closing an Onit legal service request should require a small set of fields that explain the outcome, so every closed record can answer how it ended and what was done. Four fields cover most departments.
- Outcome. A required value recording how the request ended, such as advice given, document approved, converted, or cancelled. It drives most closure reporting.
- Resolution summary. Two or three sentences on what Legal did or advised. A future lawyer searching for precedent will read this first.
- Final documents. The signed agreement, advice memo, or approved policy attached to the record, so nobody has to search email for the result.
- Effort band. An optional range, such as under one hour, one to four hours, or more than a day. It is the cheapest way to see where lawyer time goes.
Make the requirements depend on the closure path. A cancelled request needs a reason and nothing else, while a completed advice request needs the outcome and summary. Test each combination before go-live, because a required field that blocks closure on one path is easy to miss until lawyers report it during hypercare.
How should closure reason codes be designed in Onit?
Closure reason codes in Onit should be a short, fixed list that separates genuine outcomes from cancellations, so reports can tell completed work apart from work that never happened. Six to ten codes is usually enough.
- Outcome codes. Advice given, document approved, document drafted, converted to matter. These describe work Legal delivered.
- Cancellation codes. Withdrawn by requester, out of scope for Legal, duplicate, and handled by self-service. These describe demand that did not need a lawyer.
- An “other” code with a comment. A safety valve, watched closely. If it passes 5 percent of closures, the list is missing a code.
The cancellation codes are often the most valuable. A steady volume of requests closed as “handled by self-service” or “out of scope” shows which content or routing changes would keep that demand away from Legal. A self-service legal portal reduces volume when it answers the questions requesters ask most, and closure codes tell you which questions those are.
How does converting a request to a matter close the Onit LSR?
Converting a request to a matter closes the Onit LSR as converted and opens a matter record that carries the request’s context forward. The request’s clock stops at conversion, and the matter’s clock starts.
Set rules for who can convert and when. Most departments let the assigned lawyer convert once the work clearly runs beyond a set threshold, such as more than five hours of effort, outside counsel involvement, or a likely dispute. Requests below that line close as completed. Write the threshold into lawyer guidance so the matter count stays consistent.
Keep the link between the two records. The matter should show which request created it, and the closed request should point to the matter. The Onit LSR to matter workflow covers conversion criteria and field mapping in more detail, and that link is what lets you trace a matter’s cost back to the business request that started it.
What should requesters be told when an Onit request closes?
Requesters should receive a closure notification that states the outcome, summarizes what Legal did, and links to any final documents. That one message decides whether the business sees the front door as a black box or a service.
Build the notification from the closure fields, so the outcome and resolution summary become the message body and documents are linked directly. A generic “your request has been closed” email prompts follow-up questions by email and pulls work back outside the system. One optional rating question in the same message is enough to spot recurring problems within a quarter.
Should closed Onit requests be reopened or resubmitted?
Closed Onit requests should be reopened only for follow-ups on the same ask, and anything new should come in as a fresh request linked to the old one. Unity LSR supports both routes: requesters can reopen a completed request or ask a follow-up question, and resubmit a cancelled request as new.
- Reopen window. Allow reopening for five to ten business days after closure, for follow-up questions on the same ask. The original owner gets it back.
- New linked request. After the window, a follow-up becomes a new request linked to the closed one, so each request keeps its own timeline.
- Reopen tracking. Count reopened requests by type. A reopen rate above 10 percent for any type usually means requests are closing before the question was fully answered.
How should Onit handle requests that stall before closure?
Requests that stall before closure should be closed automatically after a set period of inactivity, with reminders first, so the open queue reflects real work. The usual culprit is a request waiting on the business for information that never arrives.
A practical rule is two reminders to the requester, at five and ten business days, followed by closure at 15 business days with the code “no response from requester.” The requester can reopen within the window if the information turns up. On-hold requests need a similar limit, such as a review prompt when the expected resume date passes. Reminders work best when request updates are designed so the requester knows exactly what Legal needs.
How does Onit request closure data feed reporting?
Onit request closure data feeds reporting by fixing the end date, the outcome, and the effort for every request, which turns the closed record into the basis for turnaround, demand, and capacity reports. That matters because a 2025 survey of in-house legal teams found 77 percent handle parts or all of their reporting manually, and clean closure data is what makes automated reporting possible.
- Turnaround by type. Time from submission to closure, split by request type and outcome. It only works if requests close when the work actually finishes.
- Outcome mix. The share of requests completed, converted, or cancelled each month. A rising cancellation share signals demand reaching Legal that belongs elsewhere.
- Effort by type. The effort bands recorded at closure, rolled up by type and business unit, which shows where lawyer time goes and supports staffing decisions.
Check closure data monthly for the first 90 days, looking for missing summaries and bulk closures.
Conclusion
Onit legal service request closure is where every request becomes a record you can trust, so it deserves the same design care as intake and routing. Define each closure path and who can use it, require a short outcome, summary, and final document, and keep reason codes to a fixed list that separates delivered work from cancelled demand. Tell requesters exactly what was done, allow a short reopen window, close stalled requests after reminders, and check closure data monthly so your turnaround and outcome reports reflect what actually happened.
How Basla can help
Basla provides delivery teams for Onit implementation, covering business analysis, closure path and reason code design, notification configuration, matter conversion rules, testing, documentation, and hypercare after go-live. Basla’s business analysts agree with Legal how each request type should end, then configure and test the closure rules, and Basla delivers legal technology consulting through staff augmentation or a Basla-managed delivery unit.
On a global Legal Service Request implementation, Basla built eight Front Doors to handle language and country variations, and Basla teams have delivered matter management and eBilling across more than ten global jurisdictions.
Frequently asked questions
What is Onit legal service request closure?
Onit legal service request closure is the final stage of the intake workflow, where a request is completed, cancelled, merged, or converted into a matter. Closure records the outcome and stops the clock on turnaround measures.
How do you close a request in Onit?
A request in Onit is closed by completing it with an outcome, using Quick Complete for simple asks, converting it to a matter, cancelling it with a reason, or merging it as a duplicate. Which actions appear depends on the request’s type, status, and the user’s role.
What is Quick Complete in Onit?
Quick Complete in Onit is an action that closes a simple request in one step and requires an Outcome/Delivery entry. It suits asks such as sending a standard template or answering a short question.
Can a closed Onit request be reopened?
A completed Onit request can be reopened by the requester, who can also ask a follow-up question, and a cancelled request can be resubmitted as new. Most departments allow reopening for five to ten business days and treat later follow-ups as new linked requests.
What happens to a request when it becomes a matter in Onit?
When a request becomes a matter in Onit, the request closes as converted and a linked matter record carries its context forward. The link lets you trace a matter back to the original request.
Why do closure reason codes matter?
Closure reason codes matter because they show how requests ended and why some needed no legal work. Codes such as “handled by self-service” or “out of scope” point to the content and routing changes that keep that demand away from Legal.
*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.*