A required route is missing.
Describe the intake condition, the next action, and the expected result. Test available configuration and integrations.
Before you replace another toolSoftware problem.
Software problem.
Process problem.
Or both?
Name the problem first.
If the person who runs intake were away tomorrow, could someone else follow the process? Start there. Then test what the software actually prevents you from doing.
Two questions. Different fixes.
What needs to change?
The path
Steps, ownership, handoffs.
The tool
Capabilities, setup, cost.
A better purchase starts with a clear requirement.
By Brenda Brusegard · A practical decision guide
Why the distinction matters
Different problems need different fixes.
A tool can struggle with a specific routing rule, report, or integration. A process can struggle because nobody owns the next step.
Replacing software without understanding the workflow can carry the same gaps into the next system.
Turn “intake feels messy” into a test.
Where does it stall?
Name the step and the person responsible.
What blocks it?
Separate an unclear decision from a tested tool limitation.
A two-question check
What do you know today?
Choose the closest answer. This gives you a place to investigate, not a verdict on your firm or its software.
Start with the evidence.
Answer both questions to see what to review next.
Answers stay on this page and are not submitted.
Listen for the pattern
Same symptom. More than one possible cause.
Open a scenario to see the questions worth asking before you switch tools.
“Everyone handles intake differently.”
Review the shared questions, training, and ownership first. Then check whether the tool supports the agreed workflow.
“We changed systems. Nothing improved.”
Look for the cause that moved with you: workflow, data, configuration, adoption, or a requirement neither system met.
“Our emails keep landing in spam.”
Investigate sender setup, authentication, message practices, and delivery evidence. It may not require a different platform.
When the tool deserves a closer look
Make the limitation specific.
A report cannot answer the question.
Check whether the source data is captured and connected before concluding the reporting tool cannot do it.
The cost no longer fits.
Compare total cost at your actual team size, including setup, usage, migration, and ongoing support.
A named limitation is a useful starting point. Verify it with a reproducible example before deciding a replacement is the answer.
Get the process out of one person’s headMapping means asking,
Mapping means asking,
“What happens next?”
Make the invisible steps visible.
Walk through a real inquiry from arrival to signed engagement. Include the exceptions, pauses, and handoffs. Time depends on how much of the process you need to map.
The triggerWhat starts this step?
The ownerWho is responsible, and who covers?
The informationWhat do they need to act?
The next stepWhat happens next, including exceptions?
The order of work
Map. Document. Test the tool.
Map the current path
Show what actually happens.
Document the agreed path
Define ownership and exceptions.
Test against requirements
Configure or replace with a clear purpose.
The work may show that your current tool is adequate. If it is not, you now have something concrete to test in a demo.
Choose what to read next
Follow the question you still have.
Is the process ready?
Check whether intake is consistent, visible, and possible to hand over.
Where does it stall?
Explore the response, call, quote, and follow-up gaps.
Is it a tool limitation?
Compare capabilities against the workflow your team needs.
Practical details
Common questions
How do I know whether intake has a software problem or a process problem?
Check whether the process is documented, followed consistently, and able to be covered by another person. Then identify a specific tool limitation and test it. Gaps in documentation point to process work; documentation alone does not prove the tool is at fault. Both can need attention.
Will new software fix a law firm’s intake problems?
It can help when the limitation is specific and the intended workflow is clear. Unclear ownership, inconsistent questions, and missing follow-up also need process changes. Configuration, training, and integrations should be checked before replacing a tool.
Why can intake problems persist after buying software?
Possible causes include an undefined workflow, poor configuration, missing data, incomplete adoption, or a tool that does not fit the requirements. A repeated symptom is a reason to investigate the shared cause, not proof of one explanation.
What does mapping an intake process involve?
Walk through an inquiry from first contact to signed engagement. Record what happens next, who owns each step, what information is needed, and what happens when the usual path cannot be followed. The time required depends on scope and complexity.
What is a specific software limitation?
A required workflow the current product or configuration cannot support, or a measurable cost or usability constraint. Examples include required routing rules, reporting fields, or integration behavior. Test the requirement and available configuration before choosing a replacement.
Before the next purchase
Let’s name what needs fixing.
Tell us the step that stalls and what you have already tried.
