A custom research order should tell the researcher which decisions to make and how to recognize a defensible answer. A website URL and the instruction “find companies that need us” leave too much unresolved. The researcher may understand your marketing category while missing the service boundary that determines whether an account is useful.
This guide provides a fillable brief schema, a completed fictional example, and a second example showing how an unclear request can be repaired. The method is designed for practical scoping: define the offer, translate it into observable conditions, name the unknowns, and agree the output before production begins.
What you’ll be able to do
- Identify one primary offer and explain the delivery boundaries that the website leaves unclear.
- Write eligibility, preferences, exclusions, and unknown treatment as separate instructions.
- Request observations and fit reasoning without asking the researcher to invent private pain or budget.
- Preserve a versioned brief and a clear owner for scope decisions.
- Settle the scope before checkout, then judge delivery against the specification you paid for.
Write the brief for a person making decisions
The reader of your brief needs to classify companies, choose useful evidence, and explain conclusions. Give them information that helps those tasks. A long company history is less valuable than a clear statement that you only serve businesses using a particular delivery model.
Begin with the action the research should enable. You may want to identify eligible accounts, decide which service line fits, prepare a partner review, or understand an existing list. These tasks can use similar company facts but require different interpretation. State the intended action in the first paragraph.
Name the buyer-side owner who can answer questions. The researcher should not have to reconcile conflicting instructions from a founder, a sales representative, and an operations manager. One person can collect input from the team and approve the final accepted version.
Keep assumptions visible. If your website advertises several offers but only one is relevant to the order, say so. If a newly launched service has not yet been added to the site, describe its current delivery capability honestly. Do not ask the researcher to infer unannounced features or treat a future roadmap as an available service.
Clarify your own offer first Build a seller profile that reflects what the company can actually deliver.
Use a fillable schema with decision fields
The schema below is an original starting point. Copy the field names into your preferred document and replace each prompt with a concrete answer. Leave genuinely unknown information labeled unknown rather than filling every field with promotional language.
Keep the order readable by using short paragraphs and numbered rules. A researcher should be able to refer to requirement E3 or exclusion X2 when explaining a borderline account. The identifier matters because criteria often sound similar in conversation while having different consequences.
Do not confuse a field prompt with a mandatory product feature. The accepted quote determines what can be delivered. Use the schema to request and clarify scope, especially when you need a specific output format, source detail, or account relationship model.
StackShortlist Your-offer intelligence accepts the buyer's website and a brief of up to three thousand words through PDF, DOCX, TXT, or pasted text. That limit is enough for a focused specification when repeated marketing copy is removed. Put critical rules in the main brief rather than scattering them across several attachments without explaining precedence.
| Brief field | What to enter | Decision it supports |
|---|---|---|
| Seller and primary offer | Website, offer name, work performed, delivery limits | Which capability the target is assessed against |
| Campaign action | What the team will do after reviewing the research | How much context the output needs |
| Company unit | Legal entity, operating business, brand, or other agreed unit | Counting and duplicate treatment |
| Eligibility rules | Observable mandatory conditions with evidence expectations | Which companies can be accepted |
| Preferences | Useful but nonessential attributes | Priority among eligible companies |
| Exclusions | Unsupported customers, conflicts, supplied suppression records | Which accounts must be removed or held |
| Unknown treatment | What to do when a required claim is unproven | Whether to accept, reject, or hold |
| Output and acceptance | Fields, dossier questions, sources, version, and checks | How delivery will be reviewed |
Describe the offer in operational terms
Write what you do, for whom, with which inputs, and within which boundaries. A workflow consultancy might say that it maps approval steps, configures supported software, trains a customer owner, and leaves a documented operating process. This is more useful than saying it helps ambitious businesses become efficient.
List dependencies that can make an account unsuitable. These may include an unsupported platform, a requirement for on-site work outside your service model, or a customer type you are not equipped to serve. Distinguish a true delivery constraint from a sales preference. A constraint belongs in eligibility or exclusions; a preference belongs in prioritization.
Describe what the customer must contribute. Some services require access to internal staff, existing documentation, or an implementation owner. Public research may not establish that those inputs are available, so the brief should ask for a validation question rather than treating every target as ready to proceed.
Include two short capability examples and one counterexample. For instance, a fictional integration firm can explain that it connects business applications and configures workflows, but does not build a replacement core product. This prevents the researcher from recommending accounts whose visible needs fall outside the actual service.
Write eligibility rules that another reviewer can apply
A good rule contains a condition, an evidence expectation, and an unknown treatment. “Advertises a recurring software product, supported by a current product or pricing page; hold if the business model remains unclear” is more reproducible than “modern SaaS.”
Avoid using a desired outcome as a selection criterion. “Needs our service” asks the researcher to decide a private problem without defining observable support. Break it into conditions such as a relevant operating model, supported environment, and a public context that makes a conversation plausible.
Specify how combinations work. If every requirement is necessary, use an All interpretation. If any one of several alternatives can establish eligibility, state the Any rule and explain whether alternatives represent different segments. Do not mix mandatory and optional conditions in the same sentence.
Provide a borderline example for the most ambiguous rule. If hybrids can qualify, explain which part of their offer must be distinct. If agencies are excluded, explain whether a product company with an implementation service is still eligible. The goal is not to anticipate every possible business, but to make the key boundary understandable before the larger order is researched.
Make exclusions concrete and independently testable
Exclusions deserve their own numbered list because they can override positive fit. Existing customers, active opportunities, direct competitors, unsupported service models, and prohibited internal categories should not be buried in a paragraph about the ideal customer.
Separate supplied exclusions from researched exclusions. A suppression file contains buyer-provided records that need identity matching. A rule such as “exclude firms selling only recruitment services” requires company interpretation. The output should make clear which kind of exclusion affected an account.
Give enough identifiers for supplied records to be matched reliably. A company name alone can be ambiguous. Where available, include a stable internal ID and website, while preserving the original input. Do not ask the supplier to erase or silently consolidate uncertain matches; unresolved identity should remain reviewable.
Define exception authority. If a company appears strategically interesting but fails an exclusion, who can approve a scope change? The answer should be a named role on the buyer side. Researchers should not override a rule because the account looks attractive, and sales should not redefine the accepted list after delivery without acknowledging the change.
Completed fictional brief: a workflow consultancy
Seller: Pinebridge Operations, a fictional consultancy, designs approval workflows for business service firms. Its website describes process mapping, configuration of two supported document platforms, and handover training. The current order concerns the workflow service only; its separate reporting workshop is outside scope.
Campaign action: the sales team will review a company dossier, confirm the appropriate operating role, and decide whether a short process discussion is relevant. The team does not want a claim that any target has inefficient operations. It wants a supported reason the service could apply and the strongest counterargument.
Company unit: one operating business with a distinct service offering and commercial team. Regional pages for the same business do not create additional accounts. Separately operated subsidiaries may remain distinct when the relationship is supported and recorded.
Eligibility E1: the company publicly advertises recurring business services involving document-based approval or onboarding work. Eligibility E2: the service is delivered to business customers. Preference P1: a public case or service description explains several handoff stages. Exclusion X1: software vendors whose only relevant activity is selling a product. Exclusion X2: companies on the supplied customer and active-opportunity list.
Unknown treatment: unclear business model or uncertain entity matching goes to review. Missing evidence of a preference does not reject the company. The dossier must distinguish observed service descriptions from hypotheses about internal workflow. It should not claim current budget, dissatisfaction, or a planned project.
Output: company identity, business model, eligible service evidence, relevant role observation, seller-specific fit explanation, counterevidence, and one validation question. Each decisive observation should have a source location and observation date. The acceptance owner is the operations lead, who will review a labeled sample before approving the final scope.
Worked example: repairing an ambiguous custom request
A fictional buyer, Shoreline Analytics, initially asks for “growing companies that need better dashboards and can afford a premium service.” The sentence contains three difficult assumptions: growth, dashboard weakness, and budget. None is defined, and the latter two may not be publicly observable.
The buyer and researcher first clarify Shoreline's actual service. It builds reporting workflows for multi-location service businesses that already collect operational data in supported systems. It does not sell a general business intelligence product and cannot rescue an account with no accessible underlying data.
The revised brief asks for public evidence of multiple operating locations and a relevant service model. It requests visible information about the business's advertised systems only where supported evidence exists. It explicitly leaves internal reporting quality and budget unknown. The dossier should propose a question about how location-level information reaches the operating team.
A target with several location pages now has a plausible context for review, but the dossier must consider the alternative that reporting is already centralized and effective. The buyer also adds an exclusion for businesses whose model depends on individually owned franchises when Shoreline requires a central implementation owner.
The repaired request is narrower and more honest. It gives the researcher observable eligibility rules, prevents invented pain, and tells the representative what must be validated. It does not promise that every eligible business will be dissatisfied with its dashboards or interested in changing them.
State what evidence the dossier should preserve
Ask for source information proportional to the importance of the claim. A decisive eligibility statement needs a clear supporting location. A broad company summary may use several related pages. Avoid a delivery where every claim points to the homepage regardless of where the information was found.
Record the scope of the observation. A case study can establish a disclosed past project, while a current service page describes an advertised capability. Those are different kinds of evidence. The researcher should not silently convert either into a claim about all customers or every current employee.
Specify how contradictions are handled. If the company homepage and a product page suggest different models, the dossier should explain the conflict and identify the effect on eligibility. A clean narrative that hides contradictions is harder to review than an explicit unresolved state.
W3C's Data on the Web Best Practices includes provenance information among its recommendations. The practical brief rule here is original: preserve enough claim-level context for a buyer to repeat the inclusion decision. That does not require a particular technical format, but it does require the evidence to remain connected to the conclusion.
References: W3C: Data on the Web Best Practices ↗
Describe the output as a contract between users
List the structured fields separately from the narrative questions. Company IDs, eligibility states, criterion versions, and priority labels should remain sortable. A fit explanation, counterargument, and approach question belong in readable prose. Connecting both with the same company ID allows different users to work at the right level.
Define null and unknown conventions. A blank should not force an importer to decide whether a field was not applicable, not researched, or not found. Ask for explicit states where the distinction affects acceptance. Keep any explanatory text in a separate note if the field must remain machine-readable.
For existing lists, preserve the input ID and return a status for every supplied record according to the accepted scope. If two inputs map to one company, show the mapping. If a company cannot be resolved, return that state without inventing a website to keep the table full.
State how contacts are treated. Completed new StackShortlist leads require a named founder or administrator with business email; phones are optional. Own-list research does not guarantee additional contacts. If your plan depends on a specific buying role or a particular contact field, state that requirement in your brief rather than assuming it follows from a detailed dossier.
Write acceptance checks before submitting the brief
Acceptance checks should follow directly from the brief. If the company unit is an operating business, test whether group relationships and duplicate aliases are handled consistently. If a criterion requires a public service page, inspect whether the source supports the exact claim. If an unknown blocks eligibility, verify that it did not silently enter the accepted count.
Use a small labeled sample to test the rules. Include clear inclusions, clear exclusions, and borderline cases. Ask reviewers to explain decisions with criterion IDs. Disagreement should lead to clearer wording or an unresolved state rather than a forced positive result.
Distinguish defects from later preference changes. A researcher who follows the accepted hybrid-business rule should not be judged against a new exclusion invented after delivery. Preserve the accepted version and record revisions. This makes review fair and gives the next order a better starting point.
Write the correction process as a practical request: company ID, affected field or rule, evidence, expected treatment, and whether the issue blocks use. Avoid vague feedback such as “the list feels weak.” Specific findings can be checked and corrected; impressions are much harder to act on.
Trace each check to a rule
Use the same identifiers in the brief, sample review, and final acceptance notes.
Test boundary cases
Include a hybrid, a shared-domain entity, and an unknown mandatory attribute where relevant.
Preserve the version
Keep the accepted brief with the order and log later changes separately.
Return precise findings
Identify the company, evidence, failed requirement, and requested correction.
Turn requirements into acceptance tests Use explicit denominators and evidence states to review the delivered batch.
Resolve feasibility before you check out
Paying for an order is not proof that the requested population is available. Before you check out, decide which conditions are essential, which are preferences, and whether the desired combination is realistic at the requested quantity; ask support if you are unsure. A category in a source catalogue is not a live inventory guarantee.
For StackShortlist, the minimum order is one hundred companies. Starting Your-offer intelligence prices are $79 per one hundred new companies and $69 per one hundred supplied companies. Each requirement after the first adds $0.10 per company under either All or Any matching. Payment is taken at checkout, and the research starts after payment.
If availability is uncertain, revise the brief deliberately. Remove a preference before relaxing a genuine delivery constraint. If you broaden a business model, record the new boundary and review a corresponding example. Do not agree to an unnamed “similar” audience that the sales team cannot interpret later.
Confirm the complete-input condition for scheduling. The stated delivery windows begin after the accepted, paid order has complete inputs: up to one thousand leads within twenty-four hours, 1,001–10,000 within seven days, and larger orders within fourteen days. A missing seller brief should not be treated as an invisible detail after the production clock has supposedly started.
Keep the brief alive through delivery and learning
Store the final brief with the delivered files and make it available to the people using the research. A representative should understand the seller offer and the reason an account was selected, while an operations reviewer should be able to reproduce the acceptance checks.
Record later learning as specific updates. If a target explains that a published service is no longer offered, update the affected claim and reconsider eligibility. If the seller changes its supported platforms, create a new profile version and identify which earlier decisions depend on the old constraint.
Avoid changing the entire rubric because one prospect declined an approach. A decline can reflect timing, role, channel, or preference rather than a research error. Capture the fact actually learned and update only the reasoning it affects. This preserves a useful evidence trail.
A good brief becomes shorter and more precise over time. Remove fields nobody uses, clarify the boundaries that repeatedly cause disagreement, and keep examples that teach the difficult decisions. The goal is a repeatable research task that remains understandable to someone who was not present when the campaign was conceived.
Common questions
How long should a custom research brief be?
Long enough to settle the decisions that matter, but short enough to review without hunting through repeated marketing copy. StackShortlist supports a brief of up to three thousand words for Your-offer intelligence. Prioritize the current offer, delivery constraints, criteria, exclusions, and examples over a complete history of the company.
Can I include several offers in one brief?
Yes, but give each offer separate eligibility and fit questions, and agree the actual research scope. Do not combine several service lines into one score unless the combination has a clear decision meaning. Identify the primary offer and explain how an account should be handled if it fits only one alternative.
What if I do not know my ideal customer precisely?
Start with your actual delivery constraints and a few clear inclusions and exclusions. Use a scoped sample to expose ambiguous boundaries. Do not compensate for uncertainty by asking the researcher to find companies that need you without defining observable support. Preserve unresolved cases while the rules are clarified.
Should I ask for a guaranteed pain point?
Ask for supported observations, relevant implications, counterevidence, and a validation question. A private operating problem cannot be assumed from a public website. If a source explicitly describes a problem, preserve its date and scope rather than presenting it as an unqualified current fact.
What should happen when the brief changes after work starts?
Record the new version, explain which requirement changed, and identify the affected records or outputs. Confirm any revised scope before additional work is treated as agreed. Preserve the original accepted brief so corrections to the research can be distinguished from changes in the buyer's requirements.
Sources & further reading
Primary references support the technical details. Worked examples are illustrative; workflows and checklists are practical methods to adapt to your own process.
Something changed? Tell the editorial team.