Research Your Own Offer Before Scoring Prospects

Recognize the seller model already inside every score

A scorecard always contains assumptions about what makes an account useful. Those assumptions may be explicit criteria, copied industry filters, or a representative's intuition. Making them visible is the first step toward a reproducible assessment.

Write the commercial job the seller performs. Identify the output delivered to a customer and the circumstances in which it can be delivered well. A training service, managed operation, implementation project, and software subscription can solve related problems while requiring different customers and buying roles.

Ask what would make an apparently attractive company unsuitable. Unsupported environments, delivery geography that matters operationally, customer participation requirements, and direct competitive overlap can all change fit. Keep those conditions grounded in actual capabilities rather than aspirational positioning.

Do not begin by describing the ideal prospect in flattering terms. Start with the seller's work. A company being innovative, established, or fast growing does not establish that it can use the offer. The profile should make that connection testable rather than asking the researcher to reward positive-sounding business attributes.

Read the website as evidence of advertised offers

Review the pages that describe products, services, customer types, delivery methods, and limitations. Start with navigation and current offer pages, then inspect supporting material such as documentation, pricing, case studies, and service descriptions. Record the page purpose rather than treating every sentence as equally authoritative.

A website is evidence of what the business publicly advertises. It is not complete proof of internal capacity or every current commercial condition. A broad homepage statement may coexist with a narrower implementation page. Capture the narrower operational details when they determine whether a customer can be served.

Distinguish the seller's own work from partner capabilities. A website may mention a technology ecosystem or a delivery partner without establishing that the seller directly performs every associated service. The profile should identify who does what when that distinction affects target fit.

Mark historical material. An old case study can demonstrate a past engagement, but it should not automatically establish a current service line. Ask the buyer to confirm whether the capability remains offered. Do not remove the evidence; label its time and role in the profile so a later reviewer understands why it was or was not used.

Use a status model for seller claims

Give each consequential seller claim a status. Advertised means it appears in the public material reviewed. Buyer-confirmed means the buyer explicitly says it is currently part of the offer. Unresolved means the available information is insufficient or conflicting. Retired means the buyer confirms that it should no longer govern new target decisions.

These statuses prevent two opposite mistakes. A researcher should not treat every marketing phrase as a guaranteed delivery capability. Nor should the researcher ignore a current capability simply because the website has not yet been updated, provided the buyer has clearly confirmed the scope for this order.

Keep the source of confirmation visible. A buyer's brief and a public page are different sources. If the buyer changes a website claim, record the accepted instruction and profile version rather than silently rewriting the historical observation.

The status model is an original operating convention. It is not a universal certification system. Its value is that another reviewer can see why a criterion exists and where uncertainty remains before applying it to hundreds of targets.

Map capabilities to delivery dependencies

For each offer, list the work performed and the inputs it requires. A systems integration service may require supported applications, access to technical owners, and an implementation scope the seller can maintain. A strategy workshop may require a different level of access and a different customer commitment.

Separate public target conditions from conditions that need later confirmation. The target's advertised business model may be publicly researchable. Its willingness to assign an internal owner may not be. Put the first into the research criteria and the second into the validation questions.

Do not create a criterion merely because it sounds correlated with success. If you cannot explain why a condition matters to delivery, mark it as a hypothesis to test rather than a mandatory gate. This helps prevent inherited assumptions from narrowing the audience without a clear reason.

NASA's requirements guidance emphasizes that requirements should be clear and verifiable. That principle is relevant to expressing dependencies, while the seller-profile method here remains an original commercial research workflow. Write each dependency so a reviewer knows what evidence could establish it and what to do when that evidence is unavailable.

References: NASA: Appendix C, How to Write a Good Requirement ↗

Write exclusions before attractive target examples

Exclusions reveal the limits of the offer more clearly than a list of ideal customers. Ask which projects the seller declines, which environments it cannot support, and which relationship types create conflicts. Include examples of businesses that look relevant at first glance but should not enter the campaign.

Distinguish hard exclusions from preferences. A seller may prefer customers with an internal specialist, but be able to serve those without one. That preference should not become a gate unless delivery truly depends on it. Conversely, an unsupported technical environment should not be treated as a minor preference when the service cannot function there.

Record exclusions at the offer level. A business can be unsuitable for managed support and suitable for training. A company-level exclusion such as an existing customer suppression record can apply across offers, while a service dependency may apply only to one.

Keep sensitive internal judgments out of public-facing prose. The profile can state a practical delivery boundary without insulting a customer category or inventing a weakness. “We do not provide on-site installation” is a useful constraint. A speculative claim that a certain kind of company is difficult to work with is not a reliable research rule.

Worked example: a website overstates the current scope

A fictional seller, Northbank Workflow, has a homepage promising end-to-end digital transformation. Its detailed service pages describe document approval design, configuration of two supported platforms, and user training. An older case study mentions a custom mobile application built with a former partner.

If a researcher scores targets against the homepage alone, almost any business could qualify. If the old case study is treated as a current capability, mobile application prospects may receive positive fit scores despite the seller no longer offering that work.

The buyer confirms that the current campaign concerns document approval services and that custom mobile development is retired. The seller profile marks the broad homepage claim as advertised positioning, the two supported platforms as buyer-confirmed delivery scope, and the mobile service as retired. The case study remains in the evidence record with its historical context.

The resulting target criteria focus on businesses whose public services plausibly involve the supported document workflows. The researcher does not claim those businesses have inefficient approvals. It records a relevant operating context and proposes a question about process ownership.

A target seeking a new mobile product is now excluded from this campaign even if it appears commercially attractive. The profile has improved scoring by removing an unsupported seller assumption before target research begins. No numerical weight adjustment could have repaired the original ambiguity as effectively.

Worked example: two offers require different profiles

A second fictional seller, Tern Systems, offers both implementation projects and staff training. The implementation service requires a supported platform and an internal technical owner. The training service is designed for teams already using the platform but does not require a new implementation project.

A target company publishes a mature platform deployment and extensive internal documentation. For implementation services, that evidence may reduce the plausibility of a new setup project, although other needs remain unknown. For training, the same established deployment can support a relevant question about onboarding new staff.

Tern creates separate offer records under one seller profile. Shared facts such as company identity and supported platform remain reusable. Offer-specific gates, preferences, and validation questions are kept separate. The target can therefore receive different fit states without a contradiction.

The profile also identifies a third advertised offer that is still planned. It is not used to score the current batch. If Tern launches that offer later, the buyer can create a new version and assess which targets become newly relevant.

This example shows why a seller profile is more than a company summary. It represents the relationship between actual capabilities and customer conditions. Mixing the two offers into one high score would hide the decision the sales team must make about which conversation, if any, belongs with the account.

Produce a seller profile someone else can use

The finished profile should begin with a short current-offer statement. Follow it with capabilities, supported conditions, exclusions, evidence statuses, unresolved questions, and the version date. Include links to the public pages and references to buyer-confirmed instructions.

Add a concise decision summary for each offer. State what makes a target eligible, what makes it ineligible, and which missing facts require a hold or later validation. A new researcher should not need to read every source before understanding the governing rules.

Keep reusable facts separate from interpretation. The seller may advertise a service in several industries, but the current campaign may prioritize one segment. Record the advertised scope and the campaign choice independently so the next order does not mistake a temporary preference for a permanent capability limit.

Include a short list of prohibited inferences. For example, do not infer target dissatisfaction from the seller's benefit statement, do not infer budget from company size, and do not assume a public title proves purchasing authority. These reminders are useful when they address real risks in the offer, rather than becoming a generic checklist copied into every brief.

The profile should fit within the buyer's accepted research inputs. For StackShortlist Your-offer intelligence, use the website and a brief of up to three thousand words, provided as PDF, DOCX, TXT, or pasted text. Prioritize decisive context over repeated marketing copy.

Translate the profile into a research handoff

Give each criterion a stable ID and connect it to the seller capability it supports. A researcher should be able to explain why a target attribute matters without inventing a new rationale for every account. This connection also helps the buyer remove criteria that no longer serve a purpose.

Specify the evidence expectation and unknown treatment. If a required business model is not publicly clear, the account may remain unresolved. If a preference is absent, the account can still qualify without a priority contribution. Keep those consequences explicit.

Provide examples with explanations. A clear inclusion demonstrates the intended customer condition. A clear exclusion demonstrates a delivery boundary. A borderline example demonstrates how to preserve uncertainty. The examples should teach the rule rather than become a list of companies to imitate superficially.

Do not ask the target researcher to settle unresolved seller strategy. If the team has not decided whether it wants partners or customers, the brief needs that decision before scoring begins. Otherwise the same observation can be interpreted in incompatible ways while every dossier sounds plausible.

Review the seller profile for hidden assumptions

Ask someone who did not write the profile to describe the offer and name one eligible and one ineligible target. If they cannot do so without a verbal explanation, the document is still missing decision context.

Inspect broad adjectives. Terms such as premium, scalable, innovative, or complex can have different meanings across teams. Replace them with the operational condition that matters. If the condition cannot be defined, keep it out of mandatory scoring until the buyer can explain its purpose.

Check for contradictions between current instructions and public pages. The buyer may legitimately confirm a change that the website does not yet show, but the profile should record that precedence. A researcher should not be left to choose between conflicting sources without a rule.

Review whether the profile accidentally promises unoffered services. A platform logo does not necessarily mean every feature or implementation environment is supported. A partner relationship does not necessarily mean the seller owns all delivery responsibility. Clarify those boundaries before turning them into target eligibility.

Finally, test the profile against a company the sales team previously declined. If the model gives that company a strong fit without capturing the known reason for rejection, either the profile needs a missing constraint or the historical rejection needs a more careful explanation.

Version changes according to their decision impact

Not every website edit requires rescoring the entire account universe. Distinguish wording changes from capability changes. A clearer description of an existing service may leave criteria intact. A new supported environment or a retired offer can materially change eligibility.

Assign a profile version and record the change reason. Identify the criteria affected and the target records that depend on them. This creates a controlled update path instead of a broad instruction to refresh everything whenever the website changes.

Preserve the earlier profile with earlier research. An account can move from excluded to eligible because the seller expanded its capability. That does not make the earlier research wrong. Historical context is essential when a representative later asks why an account was previously deprioritized.

Keep buyer-confirmed and public-source updates distinguishable. A sales conversation may reveal an internal service change before the website is updated. The profile can incorporate that instruction for the accepted order while retaining its origin. If the change remains tentative, label it planned or unresolved rather than applying it as current capability.

Use the profile as a decision reference

The profile should remain accessible when the team reviews dossiers, writes approaches, and evaluates feedback. It explains why a company was selected and which assumptions still need confirmation. Without it, representatives can reinterpret a score according to whichever offer they happen to be discussing.

When a target provides new information, compare it with the profile's specific dependencies. If the company uses an unsupported environment, update eligibility for the relevant offer. If it has a different internal owner than expected, update the role hypothesis without discarding unrelated fit evidence.

Keep commercial intent separate. A target that fits the seller's capabilities may still have no current interest. The profile helps establish relevance; it does not create demand or permission to contact. The next conversation should validate the remaining uncertainty rather than repeat an unconfirmed pain claim.

Review the profile after enough real use to reveal patterns. Which exclusions were missing? Which criteria caused recurring disagreement? Which public observations were useful? Add the precise learning and preserve the reason. A seller profile becomes valuable through clarity and controlled revision, not through a growing list of flattering descriptions.