Legal Case Intake Template: Fields, Rules, and Notifications (US-Focused)

Case intake is the process and system a legal team uses to collect initial client and matter information, run checks (like conflicts), qualify the request, and route it to the right owner with the right next step. Good case intake is not just a form, it is a workflow with rules, approvals, and a clear audit trail from first contact to an opened matter or a declined request.

TL;DR

• Design intake around decisions: qualify, route, check conflicts, open matter, notify.
• Standardize fields, but keep the first step lightweight to reduce drop-off.
• Use rules to prevent bottlenecks: routing, SLAs, exceptions, and escalation paths.
• Notifications should be role-based (intake team, attorneys, conflicts, billing), not noisy.
• Dashboards should answer operational questions: volume, cycle time, conversion, backlog, and reasons for decline.
• When off-the-shelf tools don’t fit your practice, a custom intake app can unify forms, checks, integrations, and reporting.

Who this is for: Legal ops leads, managing partners, and intake managers evaluating how to standardize and modernize case intake at a US firm.

When this matters: When leads are slipping through the cracks, conflict checks are inconsistent, or you cannot reliably answer “what happened to that intake?”

Most legal teams do not lose work because they lack talent, they lose it in the handoff between “someone reached out” and “we opened a matter.” Case intake is where that handoff lives. It is also where risk shows up early: conflicts, unrealistic expectations, missing documents, unclear fee arrangements, and untracked follow-ups. A strong intake setup is not a prettier form. It is a set of fields that capture the minimum you need, rules that turn that information into decisions, and notifications that move work to the right person without creating inbox chaos. If you are evaluating software, replacing a patchwork of tools, or considering building a custom workflow, this guide lays out what actually matters for US legal teams, including role-based examples, practical templates, and the tradeoffs between buying and building.

Case intake is a workflow, not a form

In practice, “intake” gets overloaded. Some teams mean lead capture. Others mean conflicts. Others mean turning an approved request into an opened matter in a billing system. The clean way to think about case intake is this: it starts when information is first collected and ends when the firm has taken a clear action (accepted and opened, referred out, declined, or parked for follow-up) with a record of why. That framing matters because it changes how you design your system. You are not collecting data for its own sake. You are collecting data to make a sequence of decisions, with accountability at each step.

The triggers that force US firms to fix intake

Teams usually revisit intake when one of these becomes painful enough to show up in partner meetings: Leads are untracked or inconsistently followed up. Someone “owns” intake, but work arrives via phone, web, referrals, email, and walk-ins, so there is no reliable queue. Conflict checks are inconsistent. Information arrives incomplete, parties are unnamed, and the conflicts team is stuck in back-and-forth instead of reviewing. Case selection is subjective and undocumented. You accept matters that do not fit, or decline matters without clear reasons that help marketing, capacity planning, or referral partners. Handoffs to billing and matter management are manual. Accepted intakes still require duplicative data entry across systems. Reporting is guesswork. You cannot answer basic questions like where intakes come from, how long decisions take, or why you are declining certain work. If any of that sounds familiar, it is a sign your intake problem is really a workflow and data model problem, not a “we need a better form builder” problem.

A practical case intake template: fields that earn their keep

The best intake templates are opinionated about what gets captured when. Your goal is to collect enough to qualify and route quickly, then progressively capture detail only after you know the matter is real. Below is a field set that works for many US practices. Treat it as a starting point, not a universal checklist.

Two design moves are worth calling out: First, conflicts needs structured names. A free-text “tell us who is involved” is a guaranteed rework loop. Make parties explicit fields, even if you allow “unknown” as a value. Second, separate “intake summary” from “matter record.” If you force every intake to look like a fully opened matter, you will either scare off prospective clients or waste staff time collecting detail before you have decided to accept.

Rules that keep intake moving (without turning it into bureaucracy)

Once you have the fields, rules do the real work. They prevent two common failure modes: everything routes to the same overworked person, and exceptions become invisible. Common rule types for legal intake include:

• Routing rules: Assign by practice area, jurisdiction, language needs, or whether the lead is existing client vs new.
• Qualification gates: Require minimum data before conflicts review, or block progression until required party fields are populated.
• Conflict workflow rules: Auto-create a conflicts task and prevent “accepted” status until cleared or formally waived.
• SLA and escalation: If a new intake sits untriaged past a threshold, escalate to a manager or reassign to a pool.
• Exception handling: Flag high-risk categories (for example, time-sensitive filings) for immediate review.
• Deduplication rules: Detect potential duplicate intakes by email, phone, party name, or similar matter description.

You do not need to automate every edge case on day one. The litmus test is simple: if a human makes the same decision repeatedly using the same inputs, it should be a rule. If the decision depends on nuanced judgment, keep it human, but capture the reason in a structured way so you can learn from it later.

Notifications: fewer pings, better handoffs

Most intake systems fail quietly through notification noise. If everyone is notified about everything, people start ignoring the channel and you are back to chasing updates. A better pattern is role-based notifications tied to status changes and deadlines. For example:

• Intake coordinator: New intake created; missing minimum data; no activity by due date.
• Conflicts team: Intake ready for conflicts review; conflicts info updated after review started; conflicts decision recorded.
• Assigned attorney/partner: Intake assigned; client meeting scheduled; accept/decline decision needed.
• Billing/admin: Accepted intake awaiting matter setup; engagement letter required; retainer requested/received.
• Marketing/BD (optional): Accepted matters by source; declined reasons trends; referral partner follow-up needed.

If you are integrating with email and chat, be explicit about what belongs where. Use chat for “work is waiting on you” alerts, and keep the system of record as the intake app itself. Otherwise, decisions get made in threads that never make it back into the file.

Workflows to start with (legal-specific, role-based)

If you try to redesign intake for every practice group at once, you will stall. Start with a few workflows that represent most of your volume, or most of your risk. Here are three strong starting points, with what each role needs.

• New client intake (general): Intake team captures basics and parties, conflicts runs review, attorney decides, admin opens matter and triggers onboarding.
• Existing client new matter: Verify client identity, collect matter description and parties, run conflicts, route directly to relationship partner for fast decision.
• Referral intake: Track referrer, capture acceptance criteria, ensure close-the-loop notification back to the referring party when appropriate.

For an end-to-end view of handoffs and automation points, use this intake-to-completion process map as a reference while you design statuses and ownership.

Integrations and dashboards: what to evaluate (and what to avoid)

Mid-funnel evaluation usually comes down to three questions: will this fit our reality, will it connect to what we already use, and will we be able to run the firm better because of it. On integrations, prioritize reliability and ownership of the data flow. Typical needs include connecting intake to email and calendars for scheduling, document storage for uploads, and a billing or matter management system for matter creation. If you are replacing a SaaS tool, plan for a transition period where both systems run in parallel and you define which one is the source of truth for each field. On dashboards, resist vanity metrics. The best dashboards answer operational questions, like what is aging in the queue, which practice areas are overloaded, where intakes are coming from, and which decline reasons are trending. That is how you reduce cycle time and prevent leads from slipping.

Build vs buy: the decision is usually about workflow complexity

Off-the-shelf intake tools can work well when your workflow is standard and you are happy adapting your process to the product. The moment you need nuanced routing, custom status logic, multiple practice-specific templates, or tightly controlled permissions, teams start stitching together forms, spreadsheets, and inbox triage again. A useful decision framework is to look at the cost of exceptions. If exceptions are rare, buy. If exceptions are frequent, expensive, or risky, build or customize. If you are surveying options, this overview of tools and build paths can help you compare categories without getting lost in feature lists.

Where AltStack tends to fit is the middle ground: you want ownership of the workflow and data model, plus production-ready deployment, role-based access, integrations, and dashboards, but you do not want to staff a full engineering project. In other words, you are replacing a brittle SaaS patchwork with a custom internal tool that matches how your firm actually operates.

A realistic rollout plan for your first few weeks

The fastest path is to ship a narrow intake workflow that people will actually use, then expand. A practical sequence looks like this: define your intake statuses and ownership, build the minimum field set for step one, implement routing and conflicts tasks, then add dashboards. Run a short parallel period where you compare “old way vs new way” so you can find missing fields and edge cases before you force a cutover. If your team is considering a custom build, this example approach to building a case intake app quickly is a good reference for scoping the first version without boiling the ocean.

Closing thought: treat intake like revenue and risk infrastructure

Case intake sits at the intersection of growth and governance. When it works, your team responds faster, makes clearer decisions, runs cleaner conflict checks, and opens matters with less rework. When it fails, you lose opportunities and accumulate risk in undocumented exceptions. If you are evaluating a SaaS replacement or a custom build, focus less on surface-level “form features” and more on whether the system can represent your real workflow: fields that support decisions, rules that keep work moving, and notifications that create accountable handoffs. If you want to see what that looks like in your environment, AltStack can help you prototype a tailored intake workflow and dashboard quickly, without committing to a long rebuild.

Common Mistakes

• Collecting too many fields up front, which increases abandonment and staff rework.
• Using email as the system of record, so statuses and decisions are lost in threads.
• Routing everything to a single person instead of using rules and pools.
• Skipping structured conflict-related fields (parties, related entities), causing repeated clarification loops.
• Launching without clear ownership, SLAs, and escalation paths for stuck intakes.

Recommended Next Steps

1. Map your current intake channels and define a single queue and owner for triage.
2. Draft your first-version field set: minimum to qualify, then progressive detail after acceptance.
3. Define statuses and the exact rules that move an intake from one status to the next.
4. Decide which integrations are required for day one vs later (calendar, docs, billing/matter systems).
5. Pilot with one practice group, then expand templates and routing once the workflow is stable.

Frequently Asked Questions

What is case intake in a legal context?

Case intake is how a firm captures a new request, qualifies it, runs checks like conflicts, and routes it to the right decision-maker, ending in an accepted matter (opened in your system) or a documented decline/referral. It should include fields, statuses, and an audit trail, not just a web form.

What fields should a legal case intake form include?

Start with contact info, referral source, practice area, a short matter summary, urgency, jurisdiction, and structured party names for conflicts. Add deeper fields only after qualification, like full party trees, key dates, document checklists, and engagement details. The right template minimizes drop-off while still supporting decisions.

How do you automate conflict checks during intake?

At minimum, structure party names and related entities, then create a conflicts review task automatically when an intake is “qualified.” Block “accepted” status until the conflicts decision is recorded (clear, potential conflict, waived, or declined). Automation helps most when it reduces back-and-forth and makes exceptions visible.

Who should own the case intake process at a firm?

Operationally, intake needs a clear owner, often an intake manager, legal ops lead, or designated coordinator. Decision ownership can still sit with attorneys or partners, but one person or team should own triage, queue health, follow-ups, and making sure conflicts and admin steps actually happen on time.

Should we buy an intake tool or build a custom case intake app?

Buy when your workflow is standard and exceptions are rare. Consider building or heavily customizing when routing logic, permissions, templates, and integrations are central to how you operate. The practical question is how costly your exceptions are: rework, missed leads, inconsistent conflict checks, or poor reporting usually justify more ownership.

How do integrations typically fit into case intake?

Integrations connect intake to scheduling (calendars), communication (email), documents (uploads and storage), and downstream systems like billing or matter management. The key is defining the source of truth for each field and avoiding duplicate entry. Many teams run a short parallel period during migration to prevent dropped intakes.

What dashboards are most useful for intake operations?

Operational dashboards focus on queue health and bottlenecks: intake volume over time, stage aging, backlog by owner or practice area, acceptance vs decline outcomes, and top decline reasons. The goal is to reduce cycle time and make workload and decision patterns visible, not to produce vanity metrics.