How to build a legal contract intake queue

What matters here

• An intake queue is four parts: a request form that enables triage, a triage step, visible status, and a self-service path.
• Ask for the counterparty, the value, the deadline and the document up front. Every missing field is a round trip that costs a day.
• Self-service for standard agreements removes more work than any efficiency gain elsewhere in the queue.
• Visible status removes the chasing, which is a real share of a legal team's interruptions.
• Triage by type and risk, not by who asked. Otherwise the loudest requester sets the priority.
• Contracts and the queue holding them are confidential, so scoped access is a hard requirement.

Who this is for

You run or support a legal function, or you run operations for one. You already know what your team spends its time on. What you want is one front door, a queue you can prioritise, and fewer requests that never needed a lawyer.

How it works in practice

One front door, and what happens to a request behind it.

1. 1

   The form adapts to the request type

   An NDA asks for less than a master agreement. One long form produces short answers on every field.

2. 2

   Standard requests never reach a lawyer

   If the answers stay inside the guardrails, the agreement generates from an approved template and the execution is recorded.

3. 3

   Anything outside the guardrails routes into the queue

   With the answers already captured, so nothing is retyped.

4. 4

   Triage sets type, risk, priority and owner

   Priority derived from deadline and value, overridable with a reason, so the loudest requester does not set the queue.

5. 5

   The requester can see where it is

   Which removes a real share of what a legal team's interruptions are made of.

6. 6

   Time splits into with-legal and waiting-on-you

   Which is the report that changes the conversation about turnaround.

1. 1

   A front door that captures enough to start

   Adaptive fields, and the four things every request needs.

   Copy

   In this Helix project, build me a legal contract intake queue.
   
   One request record: requester and team, request type, counterparty name
   and type, contract value, currency, deadline, the reason for that
   deadline, business context, whether a template was used, the related
   opportunity, and any documents.
   
   Request types to seed: new agreement, review counterparty paper, renewal,
   amendment, termination, NDA, data processing agreement, general question.
   
   Make the form adapt to the type. An NDA needs far less than a master
   services agreement, and asking for everything every time trains people to
   submit nothing useful.
   
   Require the counterparty, the value and the deadline on every request.
   Each missing field is a round trip that costs a day.
   
   Then a triage step that sets risk, priority, owner and target date.
   Suggest a priority derived from deadline and value, and let the triager
   override it with a reason. Prioritising by who asked means the loudest
   requester sets the queue and the highest-risk contract waits behind a
   routine NDA.
   
   I sign in through Helix, so do not build a login page. Read the signed-in
   user from the runtime. And do not put any key or connection string in the
   code: if this needs to reach another system, tell me and I will create the
   connection in my workspace.

2. 2

   Show the team what it is carrying

   And make the waiting-on-the-business time visible.

   Copy

   Build the queue: open requests sorted by priority then deadline, showing
   type, counterparty, value, requester, owner, age and days to deadline.
   
   Add a per-owner workload view split by type and risk, so assignment is
   based on capacity rather than on who replied first.
   
   Let me edit the status list, and cover the states that actually happen:
   received, triaged, in review, with counterparty, awaiting business input,
   awaiting signature, completed, withdrawn.
   
   Then track time in each status and report awaiting business input
   separately from everything else. A large part of what gets called legal
   delay is a request sitting with the person who raised it, and until that
   is visible legal wears the blame for it.
   
   Flag requests past their target date, and requests approaching a deadline
   with no owner.

   Worth knowing. Splitting turnaround into time-with-legal and time-waiting-on-the-business is the single most useful report here, and it costs one field.

3. 3

   Remove the requests that never needed a lawyer

   Self-service with guardrails, and a record of every execution.

   Copy

   Now the part that gives the team its capacity back.
   
   Keep templates as records: name, type, when to use it, when not to, the
   approved version, a document link, an owner, and a last reviewed date.
   
   Build a guided path for standard requests. The requester answers a few
   questions, and if the answers stay inside the guardrails, generate the
   agreement from the approved template and record that it was used, by whom,
   with which counterparty, on what date.
   
   Any answer outside the guardrails routes into the normal queue with the
   answers already captured.
   
   Then track two numbers: how many requests were handled without a lawyer,
   and how many escalated afterwards because the counterparty asked for
   changes. The second tells me whether the guardrails are set correctly.
   
   And flag templates not reviewed within a period I set.

   Worth knowing. Recording every self-service execution matters as much as enabling it. An agreement signed from a template legal cannot see is not a saving.

4. 4

   What happens after signature

   Obligations, and the reporting that shapes next year's paper.

   Copy

   Keep executed agreements: counterparty, type, effective date, term end,
   notice period, auto renew, value, signatory, document link, and the
   request it came from. Derive a notice deadline and sort by that rather
   than term end.
   
   Then obligations: what we committed to, an owner, a due date, whether it
   recurs, and a status. Report by owner and flag overdue ones. This is the
   part everybody means to do and nobody does.
   
   Finally, report requests by type, team and month; turnaround by type with
   the waiting-on-the-business time excluded and shown separately;
   self-service share; and the counterparties we contract with most often,
   which is usually where negotiating a standard form once pays for itself
   many times.

5. 5

   Connect it to real systems

   The step that turns a working prototype into something with your data in it.

   Copy

   Now connect it to the systems we actually run, so it works on real data
   rather than the rows you seeded.
   
   Anything in angle brackets is a placeholder. Swap it for whatever we use
   instead, and have the app name the connection it wants rather than assume
   a vendor, so changing my mind later is a config change and not a rewrite.
   
   <Salesforce>. Read the opportunity behind a contract request, which is
   where the value and deadline come from.
   
   <Google Drive>. Keep drafts and executed agreements where the business
   already looks for them.
   
   <DocuSign>. Read signature status, so awaiting signature is a real state
   rather than a guess.
   
   <Slack>. Accept requests from wherever people send them, because they will
   not all use the form.
   
   <Okta>. Tell the app who is signing in and whether they are in the legal
   group, which is what its visibility rules run on.
   
   <Ironclad>. If contract lifecycle already lives somewhere, read and write
   there rather than running a second system.
   
   <NetSuite>. Read the spend behind a contract request, which is usually
   what sets its priority.
   
   <Google Sheets>. Export the obligations register, because whoever owns an
   obligation will want it in a sheet.
   
   Only write where I have said to write. Everything else is read only.
   
   Do not write a key, a token or a connection string anywhere in the code,
   and do not ask me to paste one. Tell me which connections you need and I
   will create each as an authentication in my Helix workspace. Reference
   them by alias.

   Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.

6. 6

   Ship it

   The last step of every build: a URL, and the right people on it.

   Copy

   Deploy my app.

   Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Contracts and legal advice are confidential, so set Access Control before sharing: requesters see their own matters, legal sees the queue.

What it connects to

Legal work arrives from everywhere and ends in a document, so intake and storage are both connections.

• Salesforce

  Read the opportunity behind a contract request, which is where the value and deadline come from.

• Google Drive

  Keep drafts and executed agreements where the business already looks for them.

• DocuSign

  Read signature status, so awaiting signature is a real state rather than a guess.

• Slack

  Accept requests from wherever people send them, because they will not all use the form.

• Okta

  Tell the app who is signing in and whether they are in the legal group, which is what its visibility rules run on.

• Ironclad

  If contract lifecycle already lives somewhere, read and write there rather than running a second system.

• NetSuite

  Read the spend behind a contract request, which is usually what sets its priority.

• Google Sheets

  Export the obligations register, because whoever owns an obligation will want it in a sheet.

Each line says whether the app reads, writes or both. Anything not described as writing should be read only.

Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.

Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.

Related guides