Pilot Quick Start

Use this guide for the launch pilot path only. It walks a firm admin, attorney, staff member, and client through the flows CaseSolo is ready to demonstrate and support during pilot validation.

For feature status labels, see the Feature Status Catalog.

Pilot Outcome

At the end of this pilot path, your firm should have:

• A new personal-injury case with a client and working case workspace.
• Assigned tasks and deadline follow-up visible from the dashboard.
• Uploaded documents that can be previewed, shared, processed by OCR, and

fulfilled from the client portal.

• Internal messages and case communications recorded in the app.
• An AI agent run that is reviewed before anyone relies on the output.
• A client portal session used for case updates and requested-document upload.
• Billing and AI credit screens reviewed without treating unproven money movement

as launch-complete.

• A support diagnostics payload ready if anything behaves unexpectedly.

Before You Start

1. Use a firm admin account for setup.
2. Use an attorney or staff account for the working case flow.
3. Use a real pilot client email only after your team is ready to send portal

access codes and notifications.

4. Keep one browser tab open for the app and one notes document for pilot

evidence: screenshots, IDs, URLs, and anything unexpected.

5. Treat live provider actions as enabled only when your admin has confirmed

provider readiness in Integrations and Integration Reliability.

Pilot Workflow Map

| Step | Area | Primary Screen | Done When | Pilot Status | |---|---|---|---|---| | 0 | Five rooms | Home engine rooms | You can name intake, medical truth, cited demand, negotiation, and IOLTA as the daily path. | Validated locally. | | 1 | Intake and case | Work > Cases or New Case | A case exists with client, incident, case type, owner, and status. | Validated locally, manual pilot receipt still required. | | 2 | Tasks | Tasks and case task tabs | A task is assigned, visible after refresh, searchable, and completable. | Validated locally. | | 3 | Documents | Documents and case documents | A file uploads, previews, shares, deletes cleanly, and does not appear falsely complete after failed storage. | Validated locally. | | 4 | Portal requested docs | Portal and requested documents | A client uploads a requested file and the case record updates only after storage succeeds. | Validated locally for requested documents. | | 5 | Communications | Messages, Communications, and case timeline | Internal or case communication is sent or logged and unread/timeline state updates. | Validated locally; live SMS/email requires provider readiness. | | 6 | AI review | AI & Automate > Agents | An agent run completes, shows citations/confidence, and is approved or rejected before use. | Validated locally; live provider and credit evidence still needed. | | 7 | Billing | Money > Billing | Plan, usage, AI credits, and invoice/payment-link readiness are reviewed. | Implemented, needs Stripe sandbox/manual smoke before money-path launch. | | 8 | Support diagnostics | Settings > Diagnostics | The support payload is copied and attached to any pilot issue. | Validated locally. |

1. Intake And Create The Case

1. Open Work > Cases.
2. Select New Case.
3. Enter the client, incident date, case type, basic liability facts, and owner.
4. Save the case.
5. Open the created case and confirm the case number, client name, status, and

timeline are visible.

Record the case number in your pilot notes. Use that case for the rest of the pilot so every task, document, message, AI run, and portal action stays tied to a single story.

2. Assign A Task

1. Open the case task area or the global Tasks page.
2. Create a task with a clear title, due date, priority, assignee, and case link.
3. Search for the task by title.
4. Refresh the page and confirm the task still appears.
5. Mark the task complete, then reopen it if your pilot script requires another

action later.

If a task is assigned to the wrong person, edit the assignee and save. If the task is not visible after refresh, capture the task title, assignee, case number, and the current page URL.

3. Upload And Review Documents

1. Open Documents or the case document area.
2. Upload a PDF, image, or text document.
3. Confirm the document appears only after upload confirmation.
4. Preview the document.
5. Share the document if the pilot script includes secure sharing.
6. Run OCR or document processing where available.
7. Delete a nonessential test file and confirm it disappears after refresh.

Do not treat unsupported file types or failed uploads as complete. CaseSolo is designed to clean up pending records when storage transfer fails.

4. Fulfill A Requested Document From The Portal

1. Confirm the client has a valid email address.
2. Send or prepare the portal access path.
3. Open the client portal as the client.
4. Enter the access code and open the requested documents area.
5. Upload the requested document.
6. Return to the staff case workspace and confirm the request is fulfilled.

Current pilot boundary: requested-document fulfillment is the proven portal path. Portal invoices/payments and the full client-firm messaging loop remain launch hardening work until the Phase B portal-loop tasks close.

5. Record Communications

1. Open Messages or Communications.
2. Send or log an internal, team, direct, or case-linked message.
3. Confirm unread badges update where expected.
4. Open the case timeline and confirm the communication is visible when logged.
5. Edit or delete a test message if your pilot script includes cleanup.

Current pilot boundary: internal and case communication flows are locally browser-proven. Live SMS, live email, opt-out handling, and provider delivery receipts require confirmed provider readiness.

6. Run AI With Human Review

1. Open AI & Automate > Agents.
2. Pick the agent that matches the pilot case, such as intake qualification,

medical summarization, demand drafting, or gap analysis.

3. Review the input data before running the agent.
4. Run the agent.
5. Inspect output citations, confidence, model/provider details, and cost/credit

information where shown.

6. Approve useful output or reject output that is unsupported, incomplete, or

not ready for legal use.

Do not copy AI output into client communications, legal filings, settlement work, or portal updates until an attorney has reviewed it. Rejected AI output should not mutate case records.

7. Review Billing And AI Credits

1. Open Money > Billing.
2. Confirm the current plan, seats, storage usage, AI credit balance, and billing

history are readable.

3. Review invoice or payment-link readiness if your admin has enabled legal

payments.

4. Capture any Stripe sandbox IDs or payment-link IDs if a controlled payment

smoke is part of the pilot.

Current pilot boundary: billing screens and legal payment-link contracts exist, but money movement, Stripe webhooks, trust deposits, and reconciliation need approved sandbox evidence before they are considered launch-complete.

8. Copy Support Diagnostics

If anything looks wrong:

1. Open Settings > Diagnostics.
2. Select Copy Diagnostics.
3. Add the copied payload to your support note.
4. Include the case number, task title, document name, message subject, AI run,

or billing reference involved.

5. Include a screenshot or screen recording when possible.

The diagnostics payload helps support compare your browser, app version, build metadata, user, firm, and current URL without guessing.

Pilot Boundaries

Use these boundaries for honest pilot expectations:

• Ready for pilot workflow: dashboard navigation, cases, tasks, document

upload/share/preview/delete, OCR, requested portal documents, internal messages, AI review, workflow builder proof, notifications, and support diagnostics.

• Needs controlled smoke before launch claim: contacts merge/conflict paths,

billing payment flows, reports/export, provider-backed AI cost evidence, and security/failure-mode manual QA.

• Blocked until credentials or product hardening: real provider OAuth and

delivery, portal invoice/payment loop, full client-firm portal messaging loop, production authenticated API proof, and the consolidated trust single-store work.

• Not pilot launch scope: native mobile, broad i18n/RTL, CaseSolo Index,

Settlement Treasury production rails, and long-horizon ecosystem protocols.

Pilot Evidence Checklist

For each pilot run, capture:

• Tester name and date.
• Browser and viewport.
• Firm, case number, and role used.
• Screenshots of each completed step.
• Any console or network error, including route and status code.
• Support diagnostics payload for every issue.
• Whether the issue is a blocker, a note, or expected preview behavior.

Keep this evidence with the launch manual QA matrix so the team can separate validated pilot behavior from work that still needs smoke or provider approval.