A grounded sales development note for B2B sales leaders: lead intake with explicit evidence, decision rights, and a verified close.
Question and scope
The protocol does not estimate an industry benchmark; it produces a local description that B2B sales leaders can review. If the population is too small to sample, say so and report the complete set rather than implying a larger study. Define age from the first recorded request, not from the first time someone remembered to open the case. State whether the study covers one team, one client, or all cases in the defined service. If the evidence is sensitive, record the approved reference and access path rather than copying the content.
A useful scope is narrow enough to reproduce and specific enough to show whether unapproved sequence is being detected. The population should include cases handled by every owner and channel in scope, not only the queue with the cleanest records. If a definition changes during the review, keep the earlier classification and apply the new rule only to later cases. The protocol should be short enough for an operator to follow and specific enough for a reviewer to repeat. The note should distinguish what was observed, what was inferred, and what still needs an owner decision.
Population and unit
Test the unit definition on a case that crosses owners, a case that is still open, and a case that was reopened. The population should include unresolved cases, not only closures, or the study will overstate completion. The start event should be the first recorded request, not the first time the team opened the case. Report a case that moved between owners as one case with two owner periods unless the process creates a new requirement. Record this decision in the study log with the case key, the review date, and the person who approved the classification.
When several sequence approval updates belong to one request, state whether the request or each update is the unit and apply that rule consistently. Define whether a request that generates several sequence approval updates is one case or several before counting begins. The start event should be the first recorded request, not the first time the team opened the case. Use the same case key across the queue export and the evidence extract to avoid double counting. Keep the evidence reference beside the coded value so a reviewer can test the same case without rebuilding the queue.
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 completeness measure should name the required fields and the evidence state; an overall percentage is not reproducible. If two reviewers disagree, preserve both classifications until the definition is clarified. If the source changes after the observation, preserve the earlier value and add a dated note instead of replacing it.
If the definition of completion changes, keep the old and new rules side by side for the transition period. Use a stable case key and a separate identity crosswalk stored in an approved system. Define whether a case that waits for a third party is open, paused, or excluded, and apply that rule to every owner. Write the start and stop events as observable actions, not as opinions about whether the work felt finished. At Sales Development Rep, the reviewer should be able to explain this step to SDR from the case record alone.
Data dictionary and evidence
Test the dictionary on five cases before the full sample; ambiguous fields should be fixed before collection, not after. Keep the identity crosswalk in the approved system and restrict it to the review owner. Record the source identifier, the field name, the observation time, and the reviewer for every extracted value. Do not use a zero or an empty string to represent missing evidence. Use the same note in the case file and the study extract; do not create a second version in a personal document.
Each case needs the source, the observation time, the field supported, the owner, and the reviewer. If a field is derived, record the formula and the source fields used to calculate it. Record the source identifier, the field name, the observation time, and the reviewer for every extracted value. Pilot the dictionary with two reviewers and compare their classifications before the main sample. When a case needs an exception, record the reason, the owner, and the date before continuing the review.
Record the version or date of the opt-out record and the the opt-out register value so a later reviewer can see what was known at the first action. Record the extraction time separately from the event time so a late entry is visible. Keep the source reference and the coded value in the same row, and do not overwrite the original with a later correction. Use a separate field for reviewer notes so the coded values stay comparable. Keep the measurement note short enough to read with the case and specific enough to support the reported meeting show rate.
Sampling and collection
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. Include reopened, unresolved, and exception cases in the sample frame. Do not let the reviewer choose the sample after seeing the results. If two reviewers disagree, preserve both classifications until the definition or the evidence is resolved.
A convenience sample of recently closed cases will overrepresent easy work and underrepresent the tail that needs attention. A second reviewer should re-extract a small subsample and record disagreements before the full analysis. If a stratum has fewer cases than planned, report the smaller count instead of replacing it with a convenience case. Do not let the reviewer choose the sample after seeing the results. Link the observation to the exact field in the opt-out register and to the opt-out record that supports it.
A convenience sample of recently closed cases will overrepresent easy work and underrepresent the tail that needs attention. Collect the case from the CRM, the lead intake, and the approval record, and stop at the verified close. Keep the sample selection reproducible by recording the export date, filter, and random seed or start rule. Record the date of the sample and the version of the queue export. Do not let a summary written later replace the evidence that was available at the first decision.
Analysis and reporting
Compare pipeline accuracy across owners only after checking the case mix, the channel, and the evidence standard. 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. If the case moved between owners, include both owner periods in the review note and name the handoff time.
Compare reply rate across owners only after checking the case mix, the channel, and the evidence standard. Use case-level review to explain an outlier before treating it as a process signal. Keep the case-level table available for review and summarize only the measures that answer the question. End with the decision the evidence supports and the decision it does not support. Keep the review note with the case so the next sampler does not have to reconstruct the decision from memory.
Limitations
Selection bias remains if the team samples only records that are easy to open or cases handled by cooperative owners. Report the unknown population and the evidence that would be needed to describe it. If the reviewer also performed the work, note the independence limitation and use a second reviewer for a subsample. State that the result describes the observed sample, not the whole industry or every team in the service. When a value is missing, record the missing state and the reason instead of leaving an empty field in the extract.
Small samples are sensitive to one case; report the instability instead of presenting a percentage as a stable rate. Small samples are unstable; report the range and the cases that create the variation. Name the follow-up evidence that would reduce the largest uncertainty. Record the access problems that prevented a case from being reviewed. At Sales Development Rep, the lead intake review should end with a dated note and a named owner for the next check.
Review and next action
Report what moved, what did not, and which result is still unexplained. Choose one change and one measure to test it; a long action list is hard to evaluate. Set the next sample date before closing the review, so the action does not drift. Keep the prior procedure available so the next reviewer can compare the old and new states. If the evidence is sensitive, record the approved reference and access path rather than copying the content.
Choose one next action: fix the source, simplify the sequence approval, change the queue, adjust access, or pause the work until the owner decides. A quality review should end with a testable next step, not a general instruction to improve. Record the owner, the due date, and the exact change that will be tested at the next review. Record the owner, due date, and exact change that will be tested at the next review. The note should distinguish what was observed, what was inferred, and what still needs an owner decision.
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