Request intake
Capture the purpose, parties, deadline, documents, risk and decision needed before work starts.
Gotham helps US in-house legal teams take in requests, review NDAs, MSAs and vendor contracts against their playbook, research federal and state law and keep every contract, policy and deadline in one place. Only the exceptions go to a lawyer.
In-house work rarely arrives as a clean question. Requests come by email, chat and meetings, with missing context, short deadlines and unclear approvers. Automating only the answer can make the bottleneck worse if intake, handoffs and decision owners stay unclear.
A useful business case follows the whole path: the request, triage, the legal work, lawyer review, the business decision, approval and the record you keep. Value can show up as faster service, more requests handled, less outside counsel spend or fewer exceptions, not only lower headcount.
Capture the purpose, parties, deadline, documents, risk and decision needed before work starts.
Review NDAs, MSAs and vendor contracts against your playbook, flag deviations and send only the exceptions to a lawyer.
Research federal and state case law, the U.S. Code and federal regulations, with every answer cited.
Organise the record and build a chronology with each event linked to its source.
Build a workflow once, then run it the same way every time, with an approval at each step that matters.
Give each person a role, keep matters separate and decide who can see, edit or share each one.
Test the path from a business request to a reviewed answer and an owned next step.
Check that approved positions, fallbacks and escalation rules can be set up and changed safely.
Check whether non-lawyers can give context and get approved outputs without going around Legal.
Decide which system holds contracts, matters, documents, identity and approvals.
Check data location, retention, model providers, subprocessors, permissions, logs and whether data trains models.
Measure internal capacity, turnaround, avoided outside counsel spend and fewer exceptions separately.
A useful pilot has bounded inputs, a known reviewer and an output whose quality can be scored. Consider:
Use a private assessment to choose the first test and its success measures.