Maintain Research Guides as Platform Features Change

A research handbook can remain persuasive long after its screenshots or subscription assumptions become wrong. The underlying method may still be sound, while one instruction now points to a moved control or a feature unavailable to the team's plan.

Separate stable research principles from platform-dependent steps. Identity verification, evidence scope, and contact boundaries should not disappear when a button moves. Tool instructions need their own dependencies, owners, and verification dates.

Create a feature-dependency register

For each operational instruction, record the task, vendor feature, official documentation, required plan or configuration, responsible owner, last checked date, and fallback. Do not maintain a long feature list disconnected from actual work.

A useful dependency describes the exact action: review account context inside a supported CRM, or preserve a search for later review. Integrates with the CRM is too broad because it can refer to several different capabilities and data flows.

As checked on October 23, 2026, LinkedIn's Sales Navigator account types and features distinguishes Advanced from Advanced Plus for CRM Sync, and its Get started with Sales Navigator and your CRM places the described CRM integration in Advanced Plus. Verify the relevant current documentation and actual account before relying on an integration; an independent access offer does not establish those entitlements.

A fictional handbook correction

An invented handbook tells every researcher to use CRM Sync after finishing an account review. The maintenance owner discovers that the instruction was copied from another team's setup and the present team's entitlement and administrator configuration were never verified.

The dependency entry becomes:

• Instruction affected: automatic transfer assumption in the account handoff procedure.

• Required capability: the specific supported CRM connection and authorized data flow, not merely viewing a profile.

• Evidence status: official documentation checked; actual tenant eligibility and setup still unverified.

• Immediate correction: remove the blanket instruction and mark the dependency unresolved.

• Permitted fallback: a reviewed manual handoff of information the team is authorized to transfer.

• Owner and next check: designated administrator verifies the actual plan, CRM, permissions, and supported behavior before any setup proposal.

The example is fictional. It does not claim that a live integration was tested, enabled, or repaired.

Distinguish cosmetic changes from behavioral changes

A menu label moving may require a screenshot update. A changed matching rule, export scope, permission requirement, or writeback behavior can affect data integrity and needs a deeper review.

Record what changed and what remains uncertain. Do not infer a product change solely because a feature is absent from one user's screen. Role permissions, rollout, region, plan, or configuration may explain the difference. Check the official source and the authorized administrator's evidence before rewriting the handbook.

When official pages appear inconsistent, narrow the claim and flag the dependency. Do not select whichever interpretation grants the most capability. A temporary manual process can be preferable to a confident but unsupported instruction.

Keep examples and training aligned

Search the handbook's linked checklists, onboarding exercises, and saved templates for the same dependency. An updated main page does not help if the training sample still says every plan includes the feature.

Mark screenshots with the relevant context and checked date. Avoid screenshots containing live contact data, credentials, or private records. Use approved demonstration material when visual instructions are needed.

If a step can create or modify shared records, the updated procedure needs an appropriate test and authorization before use. Reading documentation is not equivalent to observing the configured behavior in the team's environment.

Define review triggers, not just a calendar

Review after a plan change, administrator change, product announcement affecting the workflow, unexplained interface difference, or failed task. A periodic check can catch quiet drift, but it should not postpone a known issue until the next scheduled review.

Give users a short route to report an outdated instruction. Ask for the task and observed difference without requesting passwords or session information. Keep the report focused on what changed, not a speculative diagnosis.

Publish a clear maintenance note

The note should identify the affected instruction, current supported statement, remaining verification, fallback, and owner. Preserve prior versions where needed to explain past work, but make the current procedure unmistakable.

A maintained handbook is not one that predicts every product change. It is one that exposes its dependencies, admits when a feature is unverified, and lets the team continue legitimate research without inventing access or bypassing platform controls.

Continue with Plan a First Sales Hire's Research Training or Create a Useful Sales Research Service-Level Agreement.