How do I set up HubSpot for a law firm?
Short answer
Build the data model first: a Matter custom object, an Intake deal pipeline with a conflict check stage before anything client facing, ... and the seven contact fields an intake needs.
Then layer the workflows on top, starting with the gate that holds an enquiry until the conflict check is recorded. Professional tier for most of it, Enterprise for the Matter object. The trap: every date in this kit is a date somebody typed, so the reminders are only as good as the person who entered them.
Read the whole answerShow less
What a spec looks like
The nine sections, and the files
Every spec follows the same nine sections, so a team reads one and knows how to read all of them.
- Outcome, when to use it and when not to
- Prerequisites: properties, lists, tiers, with the JSON to create them
- Enrollment and re-enrollment, then every step with its parameters
- Known pitfalls, a test plan, variants, and the YAML build spec
PDF, Markdown, properties JSON, workflow JSON, custom code where used. Test plan and known pitfalls in every spec.
Each spec states its minimum tier. The 12 free ones open in full, the others show their public preview.
The 43 specs, in build order
40 chosen from the library, 3 written for this kit.
The data model: Matter, the Intake pipeline, the intake fields
A Matter custom object with thirteen fields, one deal pipeline with a conflict check stage in the middle, and the contact fields an intake form has to collect. Everything else sits on this.
What each spec doesHide
Intake, routed and gated
The enquiry reaches the right practice area within minutes, and it cannot reach a consultation stage while the conflict check is still open.
What each spec doesHide
Show the 4 other specs in this groupShow fewer
From consultation to signed engagement letter
Fee proposals that are chased on a schedule, an engagement letter that gets two reminders and then a partner, and a signature that opens the matter the same day.
What each spec doesHide
Show the 4 other specs in this groupShow fewer
Client requests: documents, bills, deadline notices
Three inbound request types with their own queues and response targets, a clock that stops while the firm waits on the client, and out of hours cover that is written down.
What each spec doesHide
Show the 2 other specs in this groupShow fewer
Key dates, seen by two people
Every dated deadline the firm has written into its own diary produces reminders at ninety, thirty and seven days, to the responsible attorney and to a second named person, with an acknowledgement on the record.
What each spec doesHide
The intake that did not close, and the client who did
Enquiries that go cold get closed rather than forgotten, referrers get thanked, retainers and panel reviews get their reminder cascade, and consent is handled apart from matter correspondence.
What each spec doesHide
Show the 9 other specs in this groupShow fewer
The data model, 37 properties
A kit is not a folder of specs. It is the property schema the trade needs, then the workflows that run on it.
Contacts7 properties
| Internal name |
|---|
intake_source |
conflict_check_status |
conflict_check_date |
opposing_party |
limitation_date |
engagement_letter_signed |
referral_partner |
Companies4 properties
| Internal name |
|---|
entity_type |
sector |
general_counsel_contact |
panel_status |
Deals9 properties
| Internal name |
|---|
practice_area |
estimated_fee |
fee_type |
responsible_attorney |
referral_fee_yn |
conflict_check_status |
engagement_letter_sent_date |
engagement_letter_signed_date |
matter_number |
Tickets4 properties
| Internal name |
|---|
request_type |
document_requested |
billing_query_type |
matter_number |
Matter (custom object)13 properties
| Internal name |
|---|
matter_number |
practice_area |
matter_status |
responsible_attorney |
opened_date |
closed_date |
fee_arrangement |
jurisdiction |
key_date |
key_date_type |
key_date_verified_by |
key_date_backup_owner |
key_date_acknowledged_date |
The pack ships this as JSON, ready for one call to the properties API, plus a README that says what each field is for and which spec reads it.
The 3 things that break this, and how the specs stop them
Re-enrollment off means the gate fires once
The conflict check gate moves an intake record back when somebody pushes it forward too early. With re-enrollment off it does that exactly once.
The second time, the record sails through and the workflow history shows nothing wrong. Turn re-enrollment on for every deal stage change and test it twice, because this is the failure that makes people stop trusting the whole build.
How the specs stop itShow less
A workflow filter cannot read across an association
Branching an intake record on a property of the associated contact is not dependable, so the kit copies the conflict check status and the matter number onto the deal and onto the ticket.
It looks like duplicated data because it is. The alternative is a gate that silently lets records through, which is worse than no gate at all.
How the specs stop itShow less
Delays are wall clock, not working days
An engagement letter sent on a Thursday gets its three day reminder on a Sunday, and a task due in four hours from a Friday evening enquiry lands at two in the morning.
Set a business hours schedule on the portal, or branch on the day of the week before the delay. Every fixed delay in this kit also ships with a wait until variant.
How the specs stop itShow less
What this kit builds
A law firm loses work in three places, and none of them is the legal work. The enquiry that sat in a shared inbox for six hours while three other firms answered. The engagement letter that went out and never came back, noticed a month later when somebody asks who is handling it. The date in a diary that one person is watching, on the week that person is away.
This kit is the data model and the forty three workflow specs that put those three things in one portal. The model comes first: a Matter custom object with a number, a practice area, a status, a responsible attorney, opened and closed dates, a fee arrangement, a jurisdiction and five fields that make a key date into something two people see and one person acknowledges. Then an Intake deal pipeline with a conflict check stage sitting before anything client facing, seven contact fields an intake form should collect, four company fields for panel work, and four ticket fields that split document requests, billing queries and inbound deadline notices into their own queues. Thirty seven properties in a JSON body you can post, with the option lists spelled out.
On top of that sit the workflows. Routing by practice area with a first response clock. A gate that holds an enquiry until the conflict check is recorded, and moves it back when somebody pushes it forward early. The engagement letter chase at three and seven days. Key date reminders at ninety, thirty and seven. Consent handled apart from matter correspondence, because those are two different things and only one of them can be withdrawn.
It fits a firm of five to eighty fee earners, and the operations person at a larger practice who has been asked to make intake visible.
Read the restShow less
How the pieces fit together
Build the model before the automation. Create the Matter object, rename the practice areas, the referrers and the jurisdictions to yours, then create the contact, company, deal and ticket properties. The practice area values on the deal and on the Matter have to match character for character, and ten minutes of renaming here saves the fortnight where nothing joins up and nobody knows why.
The pipeline is second, and its shape carries the whole kit. Conflict check sits between New enquiry and Consultation booked, on purpose, because a stage gate needs somewhere to hold a record. Engagement letter sent and Engagement letter signed stay as two stages, because the gap between them is the thing being measured.
Routing third, since everything downstream assumes a record has an owner and a responsible attorney. Then the gate on top of that, then the letter chase, which reads the same responsible attorney field for its escalation.
Key dates last, once matters are real. It is the piece with the most moving parts, and it depends on fields the first three steps created. It is also the piece to build slowly, because a reminder people learn to ignore is worse than no reminder.
What you get
- 43 specs: 40 selected from the library and 3 written for this sector
- Each spec ships as PDF and Markdown
- The kit data model: 37 properties across contacts, companies, deals, tickets and the Matter custom object, as ready to post JSON plus the schema call
- The Intake pipeline stage list, in order, with the two gates it has to support
- A README that says what each property is for, which specs break without it, and which three lines the model does not cross
- Workflow JSON in Automation API format, switched off on import
- Custom coded actions: two specs use one, the duplicate check and the Matter association check, both on Data Hub Professional. None of the three specs written for this kit needs code. Three others name code only as an optional fallback and say so on the spec
- A test plan per spec, with the records to create and the history tab to check
- Variants per spec, including wait until versions of the delay based steps
- One click install for Full and Agency buyers
Who it is for, and who should skip it
Start here, because it decides most of it. This kit automates the administration of a practice: intake, routing, chasing, statuses, diary reminders, fees and client requests. It does not touch legal work and it is not built to. Nothing in it gives advice, calculates a limitation period, decides whether a conflict exists, or tells you what your professional rules permit. The key date specs count down against a date a named human entered and checked, and they say so on every screen. If you are looking for something that reasons about the law, this is the wrong product, and so is a CRM.
Take it if you run or support a firm portal and you are rebuilding the same intake gate, the same letter chase and the same reminder cascade from a blog post and a screenshot. Take it if you are at a consultancy setting up the second or third firm this year.
Skip it if you are a sole practitioner with a paper diary that works. Skip the Matter half if your portal is on Professional with no path to Enterprise, since three specs assume a custom object. And if your practice management system already owns intake, conflicts and the diary, buy the full library instead and use it for the marketing and client service half, because two systems gating the same process is an argument waiting to happen.
Questions admins ask
Does HubSpot have a matter management object for law firms?
Not as standard. You create one as a custom object, which needs an Enterprise subscription on at least one hub. The kit ships the schema body, thirteen properties and the associations to contacts, companies, deals and tickets. On Professional the workaround is a second deal pipeline named Matters, one deal per matter, which keeps the key date reminders and the matter reporting and costs you the clean link between one matter and several related records.
Can HubSpot run a conflict check?
No, and the kit does not pretend otherwise. What it automates is the administration around the check: the task lands on the conflicts clerk within minutes with the other side's name in the title, the intake record is held at the conflict check stage until a status is recorded, the decision and its date are stamped on the contact, and a timeline note leaves the trace. A person runs the search and decides. The firm defines what a conflict is and what a waiver needs.
Is it safe to put matter information in a CRM?
The data model here is built to avoid that question. Every field holds an administrative fact: a source, a status, a date, an owner, a fee arrangement. There is deliberately no case summary field, no narrative field, nothing sized for the story, because a property in HubSpot is searchable, listable and exportable, and a field like that ends up in a marketing segment eventually. Names of the other side sit in one field because a conflict search needs something to search. The file itself stays in your practice management system.
Can the key date workflow calculate a limitation period?
No. It counts down against a date a named person entered and marked as checked, and it has no knowledge of any procedural rule. The reminders go to two people at ninety, thirty and seven days, they repeat in the last week until somebody acknowledges, and an unacknowledged date that passes escalates to the practice head. Treat it as a second pair of eyes over a diary that already exists, not as the diary. An automation can be switched off, hit a portal limit or address a deactivated user without telling anyone.
What tier do I need for this?
Three specs touch the Matter custom object, so they need an Enterprise subscription on at least one hub, and two of those three also need Data Hub Professional for a code action. Two further specs sit on Data Hub Professional without needing Enterprise. One runs as low as Service Hub Starter. The rest need Professional, on Sales Hub, Service Hub or Marketing Hub depending on the spec, and two of the service specs need Service Hub Professional for business hours and the SLA clock pause. Every spec states its own minimum on the first screen, and a Starter only portal cannot run this kit.
Read 12 complete specs before you pay.
One per category, same format as the paid ones. Email only, no card.
We email the link, then a short note when specs change. Nothing else.
Here it is. Download the pack now (.zip) The link is in your inbox too.
Browse the library