Case Intake for Legal Teams: A Process Map From First Contact to Close (With Automation Points)

Case intake is the end-to-end process a legal team uses to capture a new matter request, qualify it, check conflicts, collect documents, and route it to the right owner so work can start with clear scope and traceability. It includes the front door (forms, email, phone) and the internal steps (triage, approvals, deadlines), not just a single intake form.

TL;DR

• A good case intake system is a workflow: capture, triage, conflicts, engagement, kickoff, and closure.
• Design intake around decisions: accept/decline, priority, owner, timeline, and required documents.
• Automate the handoffs that create delay: routing, reminders, status updates, and missing-info chases.
• Use a client portal when you need secure document collection and transparent status without email back-and-forth.
• Security is mostly process: role-based access, auditability, and least-privilege intake views.
• Start with one high-volume workflow, then expand to other matter types once the data model is stable.

Who this is for: Legal ops leaders, firm admins, and practice managers who want a clearer, faster, more consistent way to bring new matters into the firm.

When this matters: When leads are coming in through too many channels, conflicts checks are slowing you down, or partners complain that “intake is chaos.”

Most legal teams do not lose time because they lack effort, they lose time because “intake” is fragmented. A prospective client emails a partner, someone takes notes on a call, a PDF intake form gets uploaded somewhere, conflicts are checked in a separate system, and key details live in inbox threads until the matter is already underway. In the US, where responsiveness, documentation, and confidentiality expectations are high, a messy case intake process creates real risk: missed deadlines, inconsistent screening, and partners making decisions without the same facts. This post maps case intake from first contact to completion, calls out where automation actually helps, and shows how no-code tools and a secure client portal can reduce back-and-forth without turning intake into a bureaucratic bottleneck. If you are evaluating software, building an internal intake app, or simply trying to standardize how matters enter the firm, the goal is the same: make intake a reliable decision system, not a scavenger hunt.

Case intake is a workflow, not a form

Teams often say “we need an intake form” when what they really need is a repeatable path from request to owned work. The form is only the capture step. Case intake also includes qualification (is this a fit, and is it urgent), conflicts, assigning an owner, collecting the minimum viable set of documents, and creating a trackable matter record so nothing disappears in email.

It also helps to draw a boundary: case intake is for new matters (or substantial expansions of scope). If you treat every question, policy check, or contract redline as “a case,” you will build a process that is too heavy to use. If you need that broader front door, that is closer to compliance or request intake, which has different routing patterns and SLAs. (If you are sorting that out, see the differences between compliance intake and case intake.)

A practical case intake process map (and where to automate)

Here is a process map that works for many US firms and in-house legal teams. You can run it lightweight or formal, but keep the same sequence so the data stays consistent.

Notice what is not automated: judgment. The partner or intake owner still decides whether to take the matter and what the scope is. Automation is for the handoffs that create latency: routing, reminders, missing-info chases, and keeping a clean audit trail of what was decided and when.

Legal-specific workflows worth standardizing first

If you try to boil the ocean, intake becomes a “system” people avoid. Start with one or two workflows where consistency matters and volume is high enough to justify the effort.

• Personal injury or consumer intake: high lead volume, fast qualification, heavy document follow-up.
• Employment matters: clear conflict patterns (current/former employees), repeatable fact collection, time-sensitive claims.
• Family law: sensitive information handling, frequent document exchange, many status touchpoints.
• In-house litigation holds or disputes: structured party capture, deadlines, outside counsel assignment, escalation rules.
• Corporate matters that start as “quick questions”: define a threshold for when it becomes a formal matter vs an advisory request.

For each workflow, write down the decision you are trying to make at triage. Example: “Do we accept this matter,” “Do we need an emergency filing,” or “Is this within our geography and practice focus.” Then make sure your intake fields exist to support that decision. A solid starting point is this case intake template with fields, rules, and notifications.

Requirements that matter more than feature lists

When teams shop for intake tools, they often over-index on the surface UI and under-index on what will keep the workflow reliable six months from now. A few requirements do most of the work:

• One canonical matter record: every request becomes a trackable object with an owner and status.
• Role-based access: staff, associates, partners, and intake coordinators should not all see the same fields or documents.
• A secure client portal option: so document collection and status updates do not live in email threads.
• Flexible routing rules: assign by practice area, office, jurisdiction, and urgency, not just a generic queue.
• Integrations you will actually use: email, calendar, document storage, and whatever system holds conflicts data.
• Auditability: log who changed status, who approved, and what information was used to decide.

If you are building on a no-code platform, prioritize a clean data model (matter, party, document, task, communication) before you polish the UI. The UI will change. The data model is what makes reporting, handoffs, and permissions possible.

Build vs buy: the decision is really about differentiation

For many teams, the practical question is not “can we buy intake software,” it is “where do we need custom behavior.” Buying is attractive when your workflow matches the market. Building is attractive when your process is part of how you win, or when you need intake to connect to internal systems that off-the-shelf tools cannot fit neatly.

• Buy if: you want standard best practices, minimal configuration, and your main pain is simply getting out of email and spreadsheets.
• Build if: you need custom routing, custom dashboards per role, unique conflict workflows, or a branded client portal experience that matches how you operate.
• Hybrid if: you keep your system of record (matters, contacts, billing) but build an intake layer that standardizes capture, triage, and document collection.

AltStack is designed for the build and hybrid paths: it lets teams generate a prompt-to-app starting point, then refine it with drag-and-drop customization, role-based access, integrations, and production-ready deployment. If you are comparing options, this guide to case intake tools and when to build your own can help you pressure-test the decision.

Security: treat intake like a controlled entry point

Intake is where sensitive information first enters your environment. Security failures here are rarely dramatic hacks, they are usually over-sharing and loose handling: the wrong people can see the wrong record, an attachment gets forwarded, or a link is accessible longer than it should be.

• Default to least privilege: most users should see the intake queue, not every detail of every matter.
• Separate “lead” from “accepted matter”: apply stricter access once a matter is accepted and documents arrive.
• Use structured uploads: a client portal with permissions beats ad hoc email attachments.
• Make conflicts gating explicit: do not allow kickoff tasks until the conflicts step is completed and recorded.
• Log decisions: who accepted the matter, who declined it, and why, captured in the record.

What to measure so intake actually improves

You do not need fancy analytics to know whether case intake is working. You need a few operational signals that tie directly to speed, quality, and predictability.

• Time to first response: how long before a requester gets a real acknowledgment and next step.
• Time in triage: how long matters sit unassigned or awaiting a decision.
• Conflict cycle time: time from “submitted” to “cleared/blocked.”
• Missing-information rate: how often intake stalls because key fields or documents were not collected up front.
• Conversion rate: submitted to accepted (and the top decline reasons).
• Workload visibility: open matters by owner and stage, so staffing is proactive, not reactive.

If you want to implement this, start smaller than you think

The fastest path to better intake is not a perfect enterprise rollout. It is a tight first version that one practice group will actually use. Pick a workflow, define acceptance criteria, and build the minimum: capture, triage, conflicts gating, assignment, and a client-safe way to exchange documents. Then iterate based on what breaks.

If you want a concrete build example, this walkthrough shows how to build a case intake app in 48 hours using a no-code approach. Whether you build with AltStack or not, the key is the same: make the workflow visible, make ownership explicit, and stop letting critical matter data live only in inboxes.

Case intake is one of those operational systems that quietly sets the tone for everything downstream. When it is clean, teams move faster with fewer surprises. When it is messy, every matter starts with avoidable friction. If you are exploring your options, map your current intake, mark the handoffs, then decide what to buy, what to build, and what to standardize first.

Common Mistakes

• Trying to solve intake with a single static form instead of an end-to-end workflow.
• Capturing too much information up front, which lowers completion rates and increases bad data.
• Letting multiple intake channels create duplicate records and inconsistent screening.
• Skipping explicit conflicts gating, then scrambling once work has already started.
• Treating the client portal as optional even when document exchange is a core part of the workflow.

Recommended Next Steps

1. Map your current intake path and identify where decisions and handoffs actually occur.
2. Choose one workflow to standardize first and define acceptance criteria and required fields.
3. Decide your security model early: roles, least privilege, and what clients can see or upload.
4. Pilot with a small group, then expand once routing and data quality stabilize.
5. If you are considering tooling, compare build vs buy based on how much custom behavior you need.

Frequently Asked Questions

What is case intake in a law firm?

Case intake is the process of capturing a new potential matter, screening it (including conflicts), collecting essential facts and documents, and assigning ownership so the team can start work with clear scope. It is broader than an intake form because it includes triage, decisions, routing, and the internal record that tracks what happened.

What should be included in a case intake form?

Include the minimum information needed to make a decision and complete conflicts: requester contact info, involved parties, matter summary, location/jurisdiction, urgency, and key dates. Add workflow fields like practice area, intake source, status, and owner. Collect documents through a structured upload step when possible, not as email attachments.

Who owns the case intake process?

Ownership varies by organization, but someone must be accountable for moving items through triage. In many firms it is an intake coordinator or practice manager with partner oversight for accept/decline decisions. In-house, it is often legal ops or a shared services function that routes requests to the right attorney and enforces minimum data quality.

How do you automate case intake without making it feel robotic?

Automate handoffs and follow-ups, not judgment. Good candidates are routing rules, reminders when an item sits too long, automatic creation of tasks when a matter is accepted, and structured document requests via a client portal. Keep the decision points human, and design the form so it asks only what is needed at that stage.

Do we need a client portal for case intake?

You need one when document collection and ongoing status questions are common. A secure client portal reduces email back-and-forth, improves organization of uploads, and helps control who can access what. If your matters rarely require client-provided documents at intake, you may be fine with a simpler internal workflow first.

Is no-code a realistic approach for legal intake systems?

Yes, especially for teams that need custom workflows, dashboards, and role-based access without waiting on a full engineering backlog. No-code works best when you have a clear data model and a defined process map. The risk is uncontrolled sprawl, so set standards for fields, permissions, and who can change routing logic.

How long does it take to implement a better intake workflow?

It depends on scope and how many systems you must integrate, but most teams can pilot a focused workflow quickly if they limit the first release to capture, triage, conflicts gating, assignment, and basic reporting. The bigger time cost is usually alignment: agreeing on required fields, routing rules, and who owns decisions.