Legal client intake: structured requests, specializations and documents

What legal client intake is, and why structure helps

Legal client intake is the first exchange between a prospective client and a law office: the client explains what they need, and the office decides whether and how it can help. It happens on the phone, at the front desk, on WhatsApp, through a website form or inside an app.

Unstructured intake has predictable problems. The client explains the matter several times to different people. Key facts arrive in pieces across calls and messages. Documents are sent as blurry photos in a chat thread with no link to the request. And the office cannot tell quickly whether the matter is in its area, urgent, or conflicted.

A structured request fixes most of this without making the client fill in a long form. It asks a few questions in a sensible order, keeps the client's own explanation, carries the documents with the request, and gives the office a consistent record to review. AlMizan, the legal consultation marketplace FLUIDS designed and built for Oman, is built around exactly this idea: describe the request once, with the relevant documents.

How a structured intake request works, step by step

A structured intake request works best as a short wizard, one decision per step, ending with a review. AlMizan's request wizard follows this sequence:

1. Choose a specialization. Commercial, labor, family, real estate, and others. The choice tells an office what kind of matter to expect, and a platform can also use it to route the request to relevant offices.
2. Describe the matter. The client writes what happened and what they need, in their own words.
3. Attach documents or photos. Contracts, notices, letters or photos of papers, added to the request rather than sent separately later.
4. Select offices. The client sends the request to several offices at once, or directly to one office or lawyer.
5. Review and send. The client reviews the whole request before it is sent.

Two design details make a wizard feel lighter. First, in AlMizan a request can also begin from an office, lawyer or service the client is already viewing, so the next step follows from that starting point instead of asking the client to choose again. Second, putting the specialization first lets a product tailor what follows: once it knows the matter is, say, a labor issue, it can show prompts for the description and suggest the documents that are usually relevant.

What to ask in a legal intake form

Ask only what helps the office decide whether it can help and how to reach the client. The table below lists fields worth considering for a legal intake request; the specialization, description and attachments match AlMizan's wizard, and the rest are common additions to weigh in your own scope.

Keep the first request short. Further details belong in the consultation itself, once an office has accepted and the conversation is private between the client and that office.

What not to collect at intake

Do not collect sensitive information before an office needs it. At intake, the client has not yet chosen an office, and in a broadcast model several offices may see the request. Data minimization, collecting only what is necessary for the purpose, is a core principle of modern privacy laws, including Saudi Arabia's Personal Data Protection Law (PDPL) and Oman's personal data protection law.

• Full identity documents. National ID or passport copies are usually needed later, for engagement or filings, not to decide whether to take a request.
• Bank and payment details. These belong in a payment flow with a regulated provider, never in a free-text description or an attachment.
• Health or other special data unless the matter genuinely depends on it, such as some family or employment matters, and then only once an office has accepted.
• Detailed information about third parties beyond what the office needs to check for conflicts.
• Entire case files. Ask for the key documents first; the rest can be shared in the consultation.

Say this in the interface. A short line such as "Share the key facts and documents now; your lawyer may ask for more after accepting" reduces over-sharing and builds trust. Confirm what your product may collect, and how long it may keep it, with qualified counsel in each market.

Conflict checks and triage on the office side

Before an office accepts a request it needs to triage it and check for conflicts of interest. Software can make both faster, but the decisions belong to the office.

Triage

• Fit. Is the specialization one the office handles, and is the location one it serves?
• Urgency. Is there an upcoming hearing or deadline that changes priority?
• Completeness. Is there enough to decide, or does the office need to ask a clarifying question first?
• Capacity. Does the office have a lawyer available to take it on properly?

Conflict check

A conflict check confirms that the office is not acting, or has not acted, for the other side. The office searches its own records for the other party's name before taking the matter on. A marketplace cannot run this check for the office, because it does not hold the office's client list, but it can capture the other party's name in a consistent field and show it clearly.

There is a real design tension here. The more an office sees before accepting, the better its triage; the less it sees, the better the client's privacy. One reasonable approach is to show a summary to offices first and reveal attachments to the office that accepts. Another is to show everything but limit how many offices receive a broadcast. Decide this with the platform owner and counsel; it is a policy choice, not just a screen layout.

Handling documents and photos at intake

Documents make intake useful, and they also carry most of the risk. Treat every attachment as confidential from the moment it is uploaded.

• Legibility. Many clients photograph papers with a phone. Show a preview, allow retakes, and accept multi-page documents in one attachment where possible.
• Formats and size. Accept common formats such as PDF and images, and state limits before the upload starts, not after it fails.
• Private storage. Store attachments privately, linked to the request, and serve them only to the client and the offices allowed to see them.
• Labels. Let the client name each file, so "Lease contract" is not lost among unnamed photos.
• Removal. Let the client remove an attachment before sending, and define what happens to files on requests that are withdrawn or never accepted.

The conversation that follows acceptance needs the same discipline, which we cover in secure client–lawyer messaging. Other service businesses face similar intake questions, as in our guide to clinic booking apps.

If you are designing intake for a law firm or a legal marketplace, see the AlMizan case study, read about custom software development and marketplace platforms, or see how a law firm website can route consultation enquiries. Scope, price and timeline are agreed in a written proposal before development.