Transparency about how a product works isn't just good marketing. For a tool that surfaces signals that partners use to make consequential staffing decisions, it's a prerequisite for trust. If you're going to act on a pattern Kelpmont surfaces, you should be able to understand exactly where that pattern comes from — what data it reflects, what logic produced it, and where the boundaries of its reliability are.
This piece is a full account of Kelpmont's data inputs, pattern detection logic, and — equally important — the decisions we've made about what not to automate and why.
The Data Inputs
Kelpmont reads from three source systems, all via read-only connector:
CRM engagement records — the core historical dataset. We read: client organization records (including industry vertical classification), engagement/opportunity records (team composition, start and planned end dates, contract value, engagement type), and any outcome or satisfaction fields that exist in the firm's CRM schema. We do not read individual contact communication history, deal notes, or any free-text fields that contain client communication content. The data we access is structural and categorical, not communicative.
Time and billing records — the source for active engagement health signals. We read: project identifiers, timekeeper identifiers, dates, and hours logged. From these four fields, we derive utilization patterns, deliverable velocity indicators, and workstream pace signals. We do not read invoice data, billing rates, or client payment records. The time data we use is about engagement execution pace, not financial performance.
HRIS consultant profiles (optional) — where connected, we read: consultant name, role/title, start date at the firm, and any prior industry experience fields the firm has populated. We do not read compensation data, performance review content, or any HR classification data beyond role and experience. The HRIS connection is optional — it improves signal quality for consultants with thin CRM engagement history (recently joined staff, for example), but is not required for the core pattern engine to function.
The Pattern Detection Logic
Three pattern classes are derived from these inputs:
Vertical affinity mapping — for each consultant with two or more closed engagements in the CRM record, we calculate their engagement count and composite outcome score (derived from whatever outcome metric exists in the CRM — client satisfaction score, extension rate, or manual rating) by client industry vertical. The result is a profile: strong vertical experience areas, emerging vertical experience areas, and verticals with no history.
The affinity map is presented as a visualization — a grid — not as a recommendation. It shows where the pattern is, not what to do with it. The practice lead interprets the map in the context of the specific staffing decision at hand.
Team pairing records — for each lead-senior consultant pairing that appears on more than one engagement in the CRM record, we calculate the composite outcome for those paired engagements versus the same consultants' outcomes when paired differently. Where a consistent directional pattern exists (pairing X+Y consistently outperforms both consultants in other configurations), the pattern is surfaced. Where the sample size is too small (fewer than three paired engagements), no pairing signal is generated — the confidence threshold isn't met.
Engagement health scoring — for active engagements, we calculate a weekly health signal based on utilization variance from plan, deliverable pace signals (derived from time entry patterns against planned milestones), and client engagement behavioral proxies where available from CRM activity records. The methodology is described in detail in our earlier post on engagement health methodology. The score is displayed with a confidence band that narrows as more weekly data accumulates.
What We Don't Automate (and Why)
Three categories of decision that the patterns might seem to support — but that we've deliberately excluded from the system's output:
Staffing recommendations. Kelpmont does not produce a ranked list of recommended consultants for an engagement. It surfaces vertical affinity data and pairing records. The practice lead synthesizes those signals with the other variables that don't appear in the data — consultant development goals, client relationship context, workload distribution, strategic firm priorities — and makes the call. We're not saying automated recommendations are inherently invalid. We're saying that for the consulting firm context specifically, a system that recommends versus a system that informs produces materially different adoption dynamics, and the firms we serve are better served by the latter.
Performance rankings. Kelpmont does not produce consultant performance rankings. Outcome scores are always presented in vertical context (strong in healthcare, moderate in manufacturing) rather than as an absolute performance index. A consultant whose CRM record shows lower average outcome scores than their colleague may simply have been staffed in more unfamiliar verticals. An absolute ranking that abstracts away the vertical-fit dimension would be misleading and potentially damaging to the consultant's career trajectory in ways that have no evidentiary basis.
Client-facing signals. Nothing in Kelpmont is designed to be shared with clients. The engagement health score is an internal operational signal for the firm's practice management. It is not a client deliverable metric. We've been explicit about this in product design: there is no "export for client" functionality, and the health score visualization is deliberately framed as an internal tool. A client seeing their engagement's health score in the early weeks of a project — before the signal has stabilized — would be receiving a piece of analytical context they lack the background to interpret correctly.
Data Security and the Scope Boundary
Because firms are understandably protective of their client engagement records, a clear statement of scope is appropriate. Kelpmont holds your engagement data within your firm's instance — data is not aggregated across firms without explicit opt-in, and aggregate analysis (of the kind that informs our research publications) is conducted only on pattern-level statistics, not on identifiable client records.
The read-only connector architecture means Kelpmont cannot write to or modify any record in the firm's CRM or billing systems. The integration adds a reading layer; it doesn't add a writing surface. System administrators who are cautious about third-party integrations will find the permission scope narrow and the write footprint zero.
These design choices — transparency of input sources, pattern evidence rather than automated decisions, explicit scope boundaries on what we don't touch — are not just feature decisions. They're the architectural expression of how we think consulting firms should relate to their own data: as the owners of it, with tools that help them read it better, not tools that claim authority over it.