A useful legal intake process makes it easy to ask for help and clear who acts next. Define the service, questions and decisions before turning the process into a form.
Free for up to five users. No credit card required.
Adapt fields, workflows, and dashboards without code. Explore 1,000+ app templates and use cases
Explore a fictional example. Sign in to preview or use the app.
Write a short description of the service and the categories business teams will recognize. Explain where personal advice, unrelated administrative requests and specialist work should go. A clear service scope prevents a polished form from becoming a queue for every unresolved question in the organization.
Name the intake owner or the rule that resolves the reviewer. Decide who covers absence and what happens when a request spans more than one legal specialty. Avoid a shared queue that everyone can see but nobody is responsible for checking.
Separate accepting work from approving the underlying business action. A request accepted for contract review does not authorize the contract, spend or launch. Name the later decision and the people who hold that authority.
Start with requester, department, type of help, requested outcome and relevant date. Ask why the date matters. Add supporting context according to category rather than showing every possible legal question to every requester.
The reviewer decides whether the request is ready to handle. If a draft, commercial summary or essential fact is missing, return the record with a specific explanation. Do not silently begin work while the team is still trying to determine what the request means.
Let the requester update and resubmit the existing record. Preserve the review history and supporting context. The correction loop should be easier to follow than starting another email thread with a different version of the request.
Accept or decline the request, record the decision and identify the person responsible for the next step. Open a matter when the work needs an ongoing record. Some short questions may be resolved without creating a full matter.
Look at the reasons requests are returned, common category mistakes and where ownership is unclear. Revise the questions and guidance that cause repeated friction. More mandatory fields are not automatically a better process.
| Situation | Decision to make | What the requester should hear |
|---|---|---|
| Urgent request with little context | Who can escalate it, and what facts are still essential? | Why the urgency needs explanation and who will assess it. |
| Incomplete request | Who returns it, what is missing and how it is resubmitted? | The specific information needed to restart review. |
| Several teams involved | Who is accountable for coordinating the response? | One clear owner for the next commitment. |
| Outside legal service scope | Who declines or redirects it? | A concise reason and an appropriate next step. |
| Sensitive source material | Where should it be supplied and who can access it? | The approved restricted route, not a promise based on a label. |
| Accepted request awaiting assignment | Who notices and resolves the gap? | Who is handling the work and when to expect the next update. |
When the later decision is approval of a document, connect it to a document review workflow →
| Service decision | Agree this with the business | Keep the promise useful |
|---|---|---|
| First response | Who confirms that a request has reached legal and when | Distinguish acknowledgement from delivery of advice. |
| Routine work | How complete requests enter the normal queue | Give a next update date rather than an unexplained status. |
| Urgent work | Which business event justifies escalation and who decides | Keep one accountable owner even when the normal order changes. |
| Waiting for information | Who asks for the missing facts and follows up | Tell the requester exactly what will restart the work. |
| Advice delivered | How the business confirms the useful result | Close the matter after the response and follow-up work are complete. |
Track incomplete requests by reason, unassigned accepted work and commitments waiting on business information. These measures can show where a question, ownership rule or handoff needs to change. Define the start and end event before reporting a response-time number; submission, triage, advice delivery and matter closure are different events.
Jodoo lets the team adapt fields, choices, conditional questions, built-in review steps and queue views without rebuilding the service from scratch. Use the intake queue to find missing information and the matter views to keep accepted work connected to its next commitment.
Introduce the process with a small group of requesters and reviewers. Use fictional examples, collect the questions they ask and simplify the confusing parts. Then configure real permissions, retention and document handling under your organization’s requirements before opening the service broadly.
A shared entry point can work well, but the questions should adapt to the category. Keep a short common core and show additional fields only when they help the reviewer assess that request.
Define an escalation path for genuine urgency, while retaining the minimum facts and ownership needed to act. A separate urgent channel should still leave a traceable request and next commitment rather than creating invisible work.
Create a matter when the work needs ongoing ownership, actions, documents, updates or review history. A short clarification may not need that full lifecycle. Agree on the rule so different reviewers do not create inconsistent records.
Often it is a clear intake owner and a specific return-for-information path. A form alone will not solve an unowned queue. Establish the handoff, then improve the questions that repeatedly prevent useful review.
Open the example, explore the records and make your own copy to adapt it to your team.
Explore the legal intake example