A grounded sales development note for B2B sales leaders: account research with explicit evidence, decision rights, and a verified close.
Question and scope
The question should name the unit, the start event, the stop event, and the decision the result is meant to inform. The population should include cases handled by every owner and channel in scope, not only the queue with the cleanest records. Distinguish an administrative pause from a failure: a pause waits for a named decision, while a failure leaves the next action unowned. Record the exclusions in advance so a difficult case cannot be removed after the result is known. Record this decision in the study log with the case key, the review date, and the person who approved the classification.
This protocol asks how account research can be described from the operational record in sales development without turning a completion count into a quality claim. The unit definition should be stable enough that two reviewers can classify the same case the same way. Write the primary measure and one supporting measure; a measure without a denominator or observation window is not ready. The protocol should be short enough for an operator to follow and specific enough for a reviewer to repeat. Keep the evidence reference beside the coded value so a reviewer can test the same case without rebuilding the queue.
Population and unit
When several meeting handoff updates belong to one request, state whether the request or each update is the unit and apply that rule consistently. A case that moves between owners stays one case unless the process defines a new requirement at the handoff. The stop event should be the verified destination update, not the last message in the thread. If the queue was archived during the window, report the loss and exclude the affected period rather than assuming the cases were resolved. If the source changes after the observation, preserve the earlier value and add a dated note instead of replacing it.
Record the opening count by owner and channel, because a single total can hide a queue concentrated in one person. Report the number of cases that could not be classified and the reason, rather than forcing them into a category. Write the rule for a missing objection log before the first case so the treatment is consistent. If a request was reopened after the window, keep it in the original population and report the later event separately. At Sales Development Rep, the reviewer should be able to explain this step to sales manager from the case record alone.
Definitions and measures
Measure elapsed time from the first recorded request to the verified destination update, and report waiting intervals separately. A blank field, a not-applicable field, and a confirmed negative field should have different codes. A duplicate request is a separate intake event even when it points to the same underlying need; record the link. Define whether the measure counts requests, cases, or destination updates, and use that unit consistently. Use the same note in the case file and the study extract; do not create a second version in a personal document.
If the definition of completion changes, keep the old and new rules side by side for the transition period. Test the data dictionary on a small set of cases and revise ambiguous fields before the main sample. A completeness measure should name the required fields and the evidence state; an overall percentage is not reproducible. Keep a change log for every definition adjustment and the date it took effect. When a case needs an exception, record the reason, the owner, and the date before continuing the review.
Data dictionary and evidence
Keep free-text notes separate from coded fields so the analysis does not depend on inconsistent wording. Record the extraction time separately from the event time so a late entry is visible. Use one row per case and one column per required field; do not bury evidence in a long free-text note. A case key should remain stable if the case moves between owners or changes status. Keep the measurement note short enough to read with the case and specific enough to support the reported sequence approval cycle.
Each case needs the source, the observation time, the field supported, the owner, and the reviewer. Keep the identity crosswalk in the approved system and restrict it to the review owner. Run a five-case pilot before the full sample and revise any field that two reviewers interpret differently. Record the source location, not just the file name, so a reviewer can reopen the exact evidence. If two reviewers disagree, preserve both classifications until the definition or the evidence is resolved.
Record the version or date of the account research brief and the the CRM value so a later reviewer can see what was known at the first action. Keep the identity crosswalk in the approved system and restrict it to the review owner. Run a five-case pilot before the full sample and revise any field that two reviewers interpret differently. Pilot the dictionary with two reviewers and compare their classifications before the main sample. Link the observation to the exact field in the CRM and to the account research brief that supports it.
Sampling and collection
Include adverse cases: a missing lead intake, a conflicting source, an unavailable SDR, and a tight deadline. A second reviewer should re-extract a small subsample and record disagreements before the full analysis. Stratify by risk, channel, and owner so the sample is not dominated by the easiest queue. Keep a table of planned, eligible, selected, and reviewed counts for each stratum. Do not let a summary written later replace the evidence that was available at the first decision.
If the population is small, report every case and the reason the sample is exhaustive rather than presenting a false precision. If a source cannot be accessed, mark it unavailable and record the access problem rather than asking the operator to reconstruct it from memory. Do not expand the sample only because the early result looks weak or strong. A case that is difficult to access is still part of the frame; report the access failure rather than replacing it silently. If the case moved between owners, include both owner periods in the review note and name the handoff time.
Record the eligible count, the sample size, and every exclusion so another reviewer can reproduce the sample. Use the same collection form for every case and keep the original record linked to the extracted fields. Use a random or systematic start rule and then take consecutive cases within each stratum. Use a random start and a fixed interval when the frame is ordered, and record both. Keep the review note with the case so the next sampler does not have to reconstruct the decision from memory.
Analysis and reporting
For account research, report the age distribution and the share of cases waiting on a named decision rather than a single average. Use case-level review to explain an outlier before treating it as a process signal. Write the finding in plain language and separate what was observed from what the team believes caused it. Use a case-level table to explain an outlier before treating it as a process signal. When a value is missing, record the missing state and the reason instead of leaving an empty field in the extract.
If the sample is small, report the instability and the cases that drive the result instead of a precise-looking percentage. If two measures disagree, report both and explain what each one counts. Show the unresolved cases by owner, age, and dependency instead of reporting a single completion percentage. End with the decision the evidence supports and the decision it does not support. At Sales Development Rep, the account research review should end with a dated note and a named owner for the next check.
Limitations
The cited public sources frame recordkeeping, privacy, security, or control practice; they do not provide a local result. Small samples are unstable; report the range and the cases that create the variation. State that the result describes the observed sample and not the entire industry or every team in the service. State that the result describes the observed sample, not the whole industry or every team in the service. If the evidence is sensitive, record the approved reference and access path rather than copying the content.
The method also cannot observe work that never entered the queue, which may be the most important missing population. The record may be incomplete or delayed, so the method cannot infer work that never entered the queue. Report the limits of the the lead enrichment tool data, including fields that were unavailable or changed during the window. A missing record is evidence about the record, not proof that the work was never done. The note should distinguish what was observed, what was inferred, and what still needs an owner decision.
Review and next action
Report what moved, what did not, and which result is still unexplained. If the result is inconclusive, say so and choose a narrower question rather than claiming a trend. Choose a measure that can move within one cycle and a second measure that checks for unintended effects. Schedule the next review before the action begins, not after the result arrives. Record this decision in the study log with the case key, the review date, and the person who approved the classification.
Record the decision and the next check so the study does not end as an archive. Repeat the protocol with the same definitions and window, then compare the same measures. Keep the old process note until the new process has been tested; do not erase the baseline. Report a failed action with the same detail as a successful one so the team can learn from it. Keep the evidence reference beside the coded value so a reviewer can test the same case without rebuilding the queue.
Sources
Apply the operating question
Use the finding to define one source, output, review owner, and exception path inside a real workflow.
Discuss the workflow