Most discovery calls with law firms follow a familiar pattern. The attorney describes their current setup, asks a few questions about integrations, and either decides to move forward or does not.
The call we had with a solo attorney who is also a management consultant went differently.
She came in having already researched the Microsoft Graph API and identified it as the connection point she wanted. She asked about UTBMS litigation codes before we had finished the demo. She raised the question of inbound email tracking versus outbound, described exactly how she bills for received correspondence, and asked whether the AI-generated narrative prompt was configurable at the matter level.
These are not typical questions from a first-call prospect. They are the questions someone asks when they have thought carefully about their workflow and know specifically what they need a tool to do.
What she surfaced, across about thirty minutes of conversation, is one of the most thorough diagnostics we have encountered of what a complete legal timekeeping solution needs to look like.
The Inbound Email Problem
One of her most specific insights was about email direction.
Most timekeeping tools track sent emails. The logic is that a sent email represents a completed action, a communication made on behalf of a client, and that action has a clear timestamp. Received emails are messier. The time you spend reading and processing a received email is harder to attribute to a specific moment, and the volume of inbound email is high enough that tracking all of it would generate noise.
But she bills for both. She bills for drafting correspondence. She also bills for receiving and reviewing it. In her billing practice, reading a twenty-page letter from opposing counsel and a ten-page attached exhibit is billable time. That work happens when the email arrives, not when she responds.
She was not asking for something exotic. She was asking for a tool that reflects how billing actually works for many attorneys. Charging for received and reviewed correspondence is standard practice. The question is just whether the timekeeping tool is set up to capture it.
Her workaround suggestion was practical. Treat inbound the same way as outbound, applying a minimum increment and flagging the entry for her review. She could then adjust the duration for any received email that deserved more or less than the default. She was not asking the tool to know how long she spent reading each email. She was just asking it to surface the email and let her make that judgment.
Retroactive Email Processing
She also raised the issue of backward-looking billing, which surfaces repeatedly in our conversations with law firms that are adopting timekeeping tools mid-practice.
When a firm installs a timekeeping tool, it starts capturing from that point forward. Any email sent before the integration was connected does not exist in the system. For a firm that has been in practice for years, this means there is a backlog of unbilled activity sitting in sent mail folders that the tool cannot reach.
She was specifically interested in whether the system could be used to process older emails, to go back in time, pull a defined period of sent and received messages, and apply the same billing logic it would use on new emails. This is not a feature that exists in most commercial timekeeping tools. But it is technically achievable. The Gmail and Outlook APIs allow access to historical email. The matter-matching logic would need more manual review than it would for live email, because old emails involve contacts and matters that may have changed, but the pipeline itself is not a fundamental change to how the system works.
She saw this as a near-term practical need, not a long-term vision. She had backlogged billing that needed to happen soon, and she wanted to understand whether technology could accelerate that process.
Billing Instructions at the Matter Level
Her insight about configurable AI prompts per matter was probably the most forward-looking observation in the conversation.
She works with corporate clients who have their own billing guidelines. Large companies and insurers often provide their outside counsel with written instructions specifying what types of activity are billable, what billing increment to use, what narrative language is acceptable, and what kinds of entries they will not pay. These guidelines vary by client.
A timekeeping tool that generates narratives using a single, generic AI prompt produces outputs that may need significant editing for clients with specific requirements. But a system that allowed the attorney to attach billing guidelines or natural language instructions to a specific matter, so that every narrative generated for that matter reflects the client's requirements, would reduce editing time substantially.
This is a feature that benefits corporate-facing practices more than consumer practices, but it is the kind of capability that makes a timekeeping tool genuinely integrate with how senior attorneys actually work, rather than requiring them to adapt their work to the tool.
She also asked about UTBMS codes, the standardized billing codes used widely in corporate litigation. A significant portion of her clients require time entries to use these codes. A timekeeping tool that generates a narrative but does not associate a billing code leaves the attorney still needing to add that code manually for every entry before it goes to the client.
Attorney-Client Privilege and Third-Party Data Access
She raised the ethical dimension of using a tool that reads email content, which is a question we hear increasingly often as more firms evaluate AI-based timekeeping.
The concern is practical and legitimate. An attorney who sends an email to a client is creating a privileged communication. When a timekeeping tool reads that email to generate a billing entry, a third party is processing content that is legally protected. Does that processing create a problem?
The legal analysis here is not ours to make. But she was asking the right question, and it is one that every law firm evaluating these tools should think through with their own professional responsibility counsel. The technical safeguards, encryption, logical data separation, short retention periods before deletion, are meaningful but they are not the same as a legal opinion on whether the processing is consistent with privilege and professional responsibility obligations.
Her point was not that the tool was problematic. It was that she, as a careful professional, wanted to understand the answer before she made a decision. That is the right posture.
What Sophisticated Buyers Teach Product Teams
The value of a conversation like this one is not primarily in the deal it might produce. It is in the specificity of the requirements it surfaces.
She identified six or seven distinct capabilities that a complete timekeeping tool would need to serve her practice well. Some of those capabilities exist already. Some are on the roadmap. Some had not been explicitly considered before she named them. That kind of feedback, from someone who thinks carefully about workflow and can articulate what she needs in concrete terms, is exactly what shapes a product into something genuinely useful rather than something that solves a narrow version of the problem.
The attorneys who engage deeply with product teams in early stages are not doing the vendor a favor. They are also improving the tool they eventually adopt, and the tools available to the broader profession.