A legal request portal is a single, structured entry point where employees submit requests for legal help, answer the questions legal needs to act, and track each request until it closes. It replaces the shared inbox, the direct message to a favorite lawyer, and the Friday spreadsheet with one channel that captures the same data every time.
Building one is mostly a design exercise. Platforms such as Onit, ServiceNow, and low-code workflow tools handle forms and routing well. Success depends on the choices you make before configuration starts, and this guide takes them in the order a delivery team does.
Why do legal departments build a request portal?
Legal departments build a request portal because email intake hides demand and leaves every request dependent on the person who received it. For context, in a 2025 survey of in-house legal teams, 54 percent named streamlining intake and matter management as a top priority. A request in one lawyer’s inbox has no requester of record, no business unit, and no category, so nobody can report on it or reassign it.
- Missing information. Lawyers spend the first exchange asking for the counterparty, the deadline, and the draft, so a two-day request can take five.
- Invisible workload. The general counsel cannot see how many requests are open or where work stalls, so staffing conversations rest on anecdote.
- Follow-up noise. Requesters with no status view send chaser emails, and each one interrupts the lawyer doing the work.
PwC’s Legal Operations Portal materials, drawing on CLOC’s 2020 Legal Operations Maturity Benchmarking Report, cite up to a 40 percent reduction in legal administration and a productivity gain of more than 50 percent for legal teams. Treat those as ceiling figures, and measure your own baseline before launch.
What should a legal request portal include?
A legal request portal should include four working parts on day one: structured intake, routing, requester visibility, and reporting. Document generation and AI-assisted triage can follow once those four are stable.
- Structured intake forms. One entry point, a short list of request types, and conditional questions that change with each answer.
- Rules-based routing. Each request lands in the right queue by type, region, value, and risk, so nobody forwards email by hand.
- Status for the requester. The business sees where a request sits and who owns it, which removes most follow-up email.
- Reporting and an audit trail. Every submission, assignment, and decision is recorded, giving you real volume and cycle-time data within the first month.
If you are replacing an older front door that people avoided, remember that legal front door adoption fails for predictable, fixable reasons. Most of them are design decisions you control.
How do you define request types for a legal intake portal?
Request types for a legal intake portal are defined by grouping the work legal already does wherever the questions, workflow, or owner change. Most departments launch with six to ten types.
A typical launch set covers contract review, NDAs, privacy assessments, disputes, employment matters, regulatory inquiries, and a general legal question. Pull three months of requests from the shared inbox and tag each one before you design anything. That sample shows which types carry volume and which belong under a general category.
Create a separate form only when a request needs different questions, approvals, or owners. Twenty request types on a landing page slow people down, and requesters start picking the first option that looks close, which quietly corrupts your reporting.
Which fields should a legal intake form capture?
A legal intake form should capture only the fields legal needs to route, prioritize, and resolve the request on the first pass. For most request types that means eight to twelve visible questions.
The core set is request type, description, counterparty, deadline and the consequence of missing it, estimated value, jurisdiction, and attachments. Everything else should be conditional: a contract review asks whether the draft is third-party paper, and a privacy assessment asks about data categories. Conditional logic keeps each requester on only the questions that apply to their request.
Identity data should never be typed by hand. With single sign-on, each requester’s division, region, and cost center can be placed on the form automatically, which makes the later reporting trustworthy. For multi-country portals, intake forms across regions need translated labels, help text, and validation.
How should the portal triage and route legal requests?
The portal should triage and route legal requests with a simple risk score and four routing tiers. Score each request from 1 to 5 on value, complexity, jurisdiction, data sensitivity, and deviation from standard terms.
- Tier 1, escalation. Litigation, regulatory contact, or uncapped liability goes straight to senior counsel.
- Tier 2, material deviation. High value, sensitive data, or heavy redlines go to a specialist reviewer.
- Tier 3, limited changes. Routine contracts with minor edits go to legal operations or a named lawyer.
- Tier 4, standard and low risk. A standard NDA or approved template goes to self-service, with no lawyer involved.
Keep the first version simple, because every rule you add is one more rule to test. Give each queue a named owner and a backup. A request routed to someone on leave is the email problem all over again.
Where does self-service fit in a legal intake portal?
Self-service fits in a legal intake portal wherever the request type is known and the answer is already approved. When the form recognizes a standard NDA or a policy question, it can hand over the answer and close the request with no lawyer time spent.
In a well-designed flow, the requester can often be shown the correct answer, template, or policy automatically. Your rate depends on how much of your volume is genuinely standard, so start self-service with the two or three highest-volume, lowest-risk types. Log every self-served request as closed, so reporting shows the work legal absorbs each month.
What systems should the legal portal connect to?
The legal portal should connect to identity, matter management, contract, and signature systems so each request becomes a working record without rekeying.
- Identity and HR directory. Single sign-on supplies the requester’s name, business unit, region, and manager.
- Matter management. Requests needing ongoing work convert into matters that carry the intake data, so cycle time runs from first submission.
- CLM and eSignature. Contract requests open a contract record, and self-served templates go to signature in the same workflow.
Many departments launch intake before matter management, because a working portal produces the demand data that shapes matter types and staffing. Map every integration during design, even the ones that go live in a later wave.
How do you test and launch a legal intake portal?
A legal intake portal is tested by running realistic requests through every form, routing rule, and user role, then launched with a pilot in one business unit. Last quarter’s actual requests make better test data than invented ones.
Test paths multiply quickly. Eight request types, four tiers, and three regions produce 96 routing combinations before any edge case, so script the high-volume paths first.
Run the pilot for four to six weeks, then expand in waves with two to four weeks of hypercare after each.
How do you measure legal portal performance?
Legal portal performance is measured through adoption, submission quality, routing accuracy, and cycle time, tracked monthly from the pilot onward. Recalibrate your starting targets after the first full quarter.
- Adoption. Portal requests divided by all known legal requests, with a starting target of 90 percent within six months.
- Complete-submission rate. Requests legal can act on without going back to the requester. Aim for 90 percent, with rework under 10 percent.
- Correct-routing rate. Requests that reach the right queue first time. Aim for 95 percent, and read each misroute as an ambiguous request type.
- Cycle time and SLA compliance. Time to first response and to close, measured against the service levels you publish.
Review forms and routing rules every quarter, because a portal nobody maintains slowly pushes people back to email.
Conclusion
A legal request portal succeeds when the design decisions come before the configuration. Build a short catalog of request types from real demand, keep each form to the questions legal needs, route with a score and a few clear tiers, and give requesters a status view. Then test every path and role, pilot with one business unit, and measure from the first week. That sequence gives you a portal the business uses and a reliable picture of legal demand.
How Basla can help
Basla provides delivery teams for legal intake and request management software implementation. Those teams design, configure, test, and support legal intake on Onit and the platforms around it. Basla has built a Legal Service Request implementation with 8 Front Doors covering language and country variations, supported legal technology across 100+ jurisdictions for a global retail organization, and executed more than 1,000 test records for a contract lifecycle management rollout.
Basla delivers legal technology services through staff augmentation or a Basla-managed delivery unit. The delivery bench covers business analysis, form design, routing configuration, UAT, documentation, and hypercare, and it has scaled 2x to meet compressed timelines. That takes the weight off your legal operations team from design through a stable go-live.
Frequently asked questions
What is a legal request portal?
A legal request portal is a single online entry point where employees submit requests for legal help through structured forms and track them to completion. It gives legal consistent data, rules-based routing, and reporting on volume and cycle time.
How long does it take to build a legal intake portal?
Build time for a legal intake portal depends mainly on the number of request types, routing rules, regions, and integrations. A first release covering the highest-volume types and one pilot business unit goes live much sooner than a full catalog.
Should a legal request portal use one form or many?
A legal request portal should use one entry point, with separate forms only where questions, approvals, or owners differ. Conditional questions let related requests share a form and keep the landing page short.
What is the difference between a legal request portal and a legal front door?
A legal front door and a request portal describe the same single place the business goes for legal help. Front door usually emphasizes the requester experience, and portal usually describes the intake and routing mechanics.
Who should own the legal intake portal after launch?
Legal operations should own the legal intake portal after launch, including forms, routing rules, and reporting. Lawyers own templates and approved answers, and a quarterly review keeps both current.
How do you get employees to use the legal portal?
Employees use the legal portal when it is faster than email and is the only route in. Keep forms short, pre-fill identity data, show request status, and redirect emailed requests to the portal from launch day.
*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.*