Build the assistant.
Earn the client’s trust.

Clients need confidence that you can deliver a useful service and protect their information. Your qualifications should therefore combine application engineering, retrieval, access control, evaluation, and customer communication. A certificate can support that evidence; a working system and a clearly explained evaluation are stronger demonstrations of delivery ability.

What the product actually does

An internal knowledge assistant helps an employee answer questions using company sources such as policies, product documentation, support procedures, or engineering runbooks. Retrieval augmented generation, usually called RAG, retrieves relevant evidence and gives it to a language model to compose an answer. The answer should identify its sources and acknowledge when the evidence is missing or conflicting.

This is a good starting pattern when facts change and sources must remain inspectable. Fine-tuning is a separate technique for adapting model behavior and is usually not the first solution to frequently changing company knowledge. First determine whether the customer's existing search or built-in assistant already solves the problem.

A useful first scope is question answering with source links and human escalation. Adding actions such as changing records or sending messages requires separate authorization, validation, and operational controls.

Skills you should be able to demonstrate

You do not need every framework. Learn one backend stack, one retrieval implementation, one cloud or managed platform, and one communication channel deeply enough to debug them. Add tools when a real requirement justifies them.

A reference architecture you should understand

Think of two connected flows.

Ingestion: approved source → connector → extraction and validation → chunks plus document metadata and access rules → searchable index.

Answering: signed-in user → server-side identity and group resolution → authorized retrieval → optional reranking → answer from retrieved evidence → citation validation → response and limited operational telemetry.

The index is not the original authority on who may see a document. You must define how source permissions are synchronized or checked at query time. Access rules belong in retrieval and service enforcement; a prompt saying “do not reveal confidential data” does not provide authorization.

Store enough provenance to explain an answer: source ID, source URL, version, timestamps, chunk location, and applicable access metadata. Handle document deletion and permission revocation as first-class events. Account for cached answers, conversation history, logs, and backups when deciding how long sensitive material can remain accessible.

Use tenant-specific isolation and enforce tenant filters on the server. Never accept a client-provided tenant ID as sufficient proof of access. Rerankers, model providers, and tracing systems also receive data and belong in the data-flow review.

Common failures and what a qualified engineer does

Documents can contain malicious instructions. Treat retrieved material as untrusted content and constrain what the system can do with it. OWASP identifies prompt injection, sensitive information disclosure, excessive agency, and vector-related weaknesses among relevant application risks. Use its taxonomy to structure realistic tests. OWASP GenAI risks

Three portfolio projects with distinct purposes

Project one shows business usefulness

Build a support knowledge assistant with synthetic product manuals, escalation rules, and known issues. Demonstrate five tasks: answer a common question, cite an exact procedure, distinguish product versions, identify conflicting instructions, and escalate a question absent from the corpus.

Deliver a short video, a simple architecture diagram, a repository with setup instructions, and an evaluation report. Explain the dataset size and limitations. A synthetic demonstration is useful evidence of engineering, but must not be presented as a customer deployment.

Project two shows enterprise readiness

Extend a system with at least three roles, restricted sources, document updates, and permission revocation. Demonstrate that a user without access cannot retrieve restricted chunks or infer restricted titles through citations. Test cross-session caches and mixed-permission conversations.

Document exactly which access patterns you tested. A finite suite finding no leakage is a release gate, not proof that all possible leakage is impossible.

Project three shows commercial judgment

Choose a platform already used by a plausible customer and compare its native assistant with a limited custom implementation. Use the same questions, source documents, and permission cases. Compare setup effort, quality, ongoing cost, operational ownership, and gaps.

Your conclusion may favor the native product. Showing that you can recommend the lower-maintenance option establishes credibility with buyers.

Readiness levels

You are ready for a discovery engagement when you can interview users, map sources and permissions, evaluate feasibility, and write an honest scope. You can do this before you are ready to promise a production deployment.

You are ready for a bounded pilot when you can deploy securely, measure results, demonstrate authorized retrieval, document limitations, and provide support during the pilot. Use senior support or a delivery partner for areas beyond your competence.

You are ready to own production when you can handle monitoring, incidents, rollback, data lifecycle changes, customer handover, and ongoing quality evaluation. Company-wide or sensitive deployments may require security and infrastructure specialists.

Credentials and formal education

For consulting, prioritize credentials that match the systems your buyers already use. For employment, check the actual role requirements: some employers require a degree, others emphasize applied experience. There is no single certificate that proves you can safely deliver every internal assistant.

Microsoft offers an Applied Skills credential for building an agent in Copilot Studio, with an assessment covering configuration, knowledge, topics, tools, and publication. It is a relevant option for a Microsoft-focused service. Verify the active assessment before investing time because credential catalogs change. Microsoft credential

For an AWS or Google Cloud route, start with identity, deployment, data services, and the platform's AI documentation. Choose a current credential only after examining the requirements of your target roles or partner program. Do not collect unrelated badges while postponing a portfolio.

A practical self assessment

Score each skill area from zero to three: zero means unfamiliar, one means tutorial experience, two means independent implementation, and three means you can operate and debug it. Record a link to evidence for each score.

Before selling a pilot, aim for at least level two in the areas the scope depends on. Treat missing authorization or evaluation skills as blocking gaps even if your overall average looks good. Use the weakest essential area to choose your next learning task.

There are three different choices: the platform you implement, the channel through which you find work, and the type of organization that buys your work. Choose them together. A familiar platform with reachable buyers is a better starting point than a technically attractive stack with no route to customers.

Platforms you can build on

The fit recommendations below are practical judgments. They are not claims about market share or guaranteed demand. Confirm edition, connector behavior, identity integration, commercial terms, and deployment region for each client.

Microsoft documents user-permission-aware SharePoint grounding in Copilot Studio, subject to its authentication configuration and integration limitations. That makes it worth evaluating for an existing Microsoft environment, but it does not remove the need for tenant-specific tests. SharePoint integration

Rovo Search retrieves across connected tools and Atlassian sources. Start by testing that existing capability before proposing a replacement. Rovo Search

Google documents separate IAM roles and access scopes for Gemini Enterprise resources. Treat cloud resource authorization and an employee's document permissions as separate design questions. Google access controls

Bedrock provides retrieval and retrieval-plus-generation APIs, including source citations in the combined response. This supplies infrastructure for an application; your implementation still needs an appropriate user access model. Bedrock retrieval

Glean explicitly lists implementation and managed services among partner activities. This creates a possible consulting route, subject to acceptance and access. Glean partners

How to choose your first platform

Score each realistic route from one to five on customer access, your current skills, available demo access, workflow fit, and delivery effort. Give customer access and workflow fit double weight. Reject any choice that cannot meet required permissions or operating constraints, regardless of its score.

A Microsoft route is a reasonable default if you can reach Microsoft 365 customers and their administrators. An Atlassian route is sensible if you know engineering or support teams already using Confluence. An AWS or custom route fits strong backend engineers with buyers who need application integration. Treat these as starting hypotheses to test in customer conversations.

Avoid learning all platforms simultaneously. Spend your first month on one route and maintain a simple comparison with alternatives. You should be able to explain when your chosen platform is the wrong fit.

Where to find freelance clients

Upwork has a chatbot services category; use that as a discovery entry point, not evidence that a particular buyer has an active budget. Search terms include “internal knowledge assistant,” “RAG,” “Copilot Studio,” “SharePoint chatbot,” and “enterprise search.” Upwork services

Malt provides a freelancer marketplace and profile-based client discovery. Check the terms for your own market before assuming fee, onboarding, or payment conditions. Malt freelancers

Partner channels are often a second-stage route. For example, n8n's expert partner page currently describes an application process for established agencies and integrators and asks for existing customer experience. Start by delivering projects or collaborating with established partners rather than assuming immediate directory admission. n8n expert partners

For your first month, allocate roughly half your business-development time to warm contacts and agencies, a quarter to carefully selected marketplace opportunities, and a quarter to portfolio visibility and community participation. This is a suggested experiment, not a measured conversion formula.

Which clients to target

A useful initial customer has repeated questions, reasonably maintained source material, a clear owner, reachable users, and authority to fund a pilot. Headcount alone is a weak signal. A 40-person team with a painful workflow can be more suitable than a large company with fragmented ownership.

Use generic policy and process knowledge before introducing personal HR records, customer secrets, or high-consequence decision support. Scope should match your experience and the client's controls.

Look for observable triggers: growth in support volume, onboarding problems, a migration of documentation, a new knowledge-management owner, or a failed assistant trial. Treat each trigger as a reason to investigate, not proof that a company needs your service.

Where you can work as an employee

Target applied AI engineering teams, enterprise software companies, consultancies, systems integrators, internal IT teams, and platform providers. Search for AI Engineer, Applied AI Engineer, LLM Engineer, AI Solutions Engineer, AI Consultant, Search Engineer, and Forward Deployed Engineer. Responsibilities vary more than titles.

Use LinkedIn AI engineering searches for broad discovery and Wellfound for startup roles. Verify each opening on the employer's own site before applying. These are discovery channels, not a list of confirmed suitable vacancies.

For engineering roles, emphasize code quality, retrieval evaluation, deployment, and incidents you can explain. For solutions roles, emphasize discovery, demonstrations, integration decisions, and communication with customers. For consultancy roles, add scope control, documentation, and handover.

Check location, language, time-zone overlap, work authorization, and remote-work restrictions for each role. “Remote” does not necessarily mean available worldwide.

Consulting versus employment versus a product

Consulting is useful when you can sell and deliver a bounded outcome. Employment can be a better route if you need production experience, mentorship, or reliable income. An agency becomes viable when delivery is repeatable and you can maintain quality through others. A product becomes credible when several customers share the same workflow and will pay for a common solution.

Do not build a multi-tenant SaaS product merely because two demos look similar. Validate common requirements, support load, security obligations, and a repeatable customer acquisition channel first.

Persuade clients by reducing uncertainty: understand the workflow, show relevant evidence, bound the scope, and agree on how success will be measured. A buyer needs to believe the problem matters, you can deliver, and the expected improvement is worth the cost.

Position your offer around a buyer and a task

Use this structure: “I help [team] answer [repeated questions] using [approved sources] inside [existing tool], with source links and access controls.”

For example: “I help B2B support teams find approved troubleshooting procedures in their internal knowledge base, with citations and escalation when the answer is missing.” Only add numerical performance claims after measuring them.

Avoid describing yourself only as someone who builds chatbots. That description gives the buyer little basis to judge scope, reliability, or relevance. Name the work employees need to complete.

Qualify prospects before writing proposals

Score pain, source readiness, sponsor access, budget feasibility, and a credible decision timeline from zero to two. Use the score to prioritize conversations, not as a substitute for judgment. A high score does not override a missing right to use the data.

A promising prospect can identify repeated questions, provide sample sources, name the person accountable for the workflow, and explain how a purchase would be approved. Ask who owns identity, knowledge maintenance, and operations after launch.

Pause or offer an assessment when sources are missing, nobody owns the outcome, or the buyer expects a company-wide system before reviewing a small pilot. Decline commitments that require capabilities you cannot reliably provide.

Run a discovery conversation

Spend the first part understanding the current task. Ask a user to show how they answered a recent question, which systems they searched, how they knew the answer was current, and where they became stuck. Concrete examples are more useful than a general complaint that search is bad.

Then establish frequency, task duration, users affected, and the consequences of an incorrect answer. Ask which native search or AI features they have already tried. Finally, discuss data access, decision-makers, budget, and a realistic next step.

Send a short written recap: the problem, proposed scope, unresolved assumptions, and who will provide each dependency. The recap should be understandable to someone who did not attend the meeting.

Use a short demonstration to prove the difficult parts

A five-minute demo can show one normal question with citations, one ambiguous question, one missing answer, one restricted document test, and one updated source. Explain what the system did and what it still cannot do.

Use public or synthetic material until the client approves their own test dataset. If you show performance figures, identify the dataset, test conditions, and measurement period. Do not imply that a polished demonstration has already proven production reliability.

Offer three commercial stages

An illustrative pilot might cover one department, one language, one channel, two source collections, and 15 test users. The client and engineer must replace these limits with an agreed scope. Exclude autonomous actions and broad data migration unless they are separately designed and priced.

Do not promise a delivery date before checking access, source quality, connector availability, and administrator support. Distinguish engineering effort from elapsed calendar time.

Estimate from effort and uncertainty

Use a transparent model: estimated delivery days × your sustainable day rate, plus a visible allowance for identified uncertainty and explicit third-party costs. Separate assessment, implementation, and recurring support.

Illustrative arithmetic, not market pricing: a 3-day assessment at EUR 600 per day is EUR 1,800. A pilot estimated at 12 days at EUR 650 per day is EUR 7,800. A 20% contingency adds EUR 1,560, giving EUR 9,360 for the scoped work before applicable taxes and separately agreed platform charges.

These numbers are examples for learning estimation. Your actual rate depends on geography, experience, demand, scope, liability, and delivery cost. Keep contingency treatment clear: it can be included in a fixed price or handled as a separately approved allowance, but should not be an unexplained extra charge.

For support, define included hours, monitoring responsibilities, response windows, exclusions, and overage rates. A monthly retainer should correspond to actual work and availability. Avoid unlimited support or 24/7 commitments without staffing to fulfill them.

Explain business value without inventing savings

Use a client-validated baseline and separate saved capacity from realized cash savings. A useful model is:

Monthly capacity value = eligible users × adoption × relevant tasks per month × minutes saved per successful task ÷ 60 × loaded hourly cost × realization factor.

The realization factor represents how much saved time becomes useful capacity. Avoid double-counting adoption or success if task volume already measures actual successful usage.

Illustrative base case: 60 users × 0.60 adoption × 20 tasks × 4 minutes ÷ 60 × EUR 45 per hour × 0.50 realization = EUR 1,080 per month of capacity value. With EUR 700 in monthly operating and support costs, the net modeled benefit is EUR 380 per month. A EUR 9,360 pilot would take about 24.6 months to recover on that simplified basis. This may be too weak to justify the project.

An upside scenario using 0.80 adoption and 8 minutes saved, with the other inputs unchanged, produces EUR 2,880 of monthly capacity value and EUR 2,180 net after the same costs. Simple payback becomes about 4.3 months. A conservative case with 0.40 adoption and 2 minutes saved produces only EUR 360 of capacity value, below the assumed recurring cost.

These scenarios show why discovery and measurement matter. Do not sell the upside case as a forecast. Include assessment and rollout costs in a complete investment decision, and check whether growing use increases operating costs. Time savings do not automatically reduce payroll or create revenue.

Answer common buyer objections

What establishes trust

Show artifacts a buyer can inspect: a relevant demo, evaluation results, architecture, a data-flow explanation, a delivery plan, and a clear handover. Use actual customer references only with permission. If you are early in your career, say so and demonstrate the work you have completed.

A strong closing question is: “Would it be useful to validate this on an agreed set of questions and approved sources before deciding on a wider rollout?” The next step is a concrete evaluation, not an unsupported promise.

Keep a measurable sales process

Track prospects through researched, contacted, replied, discovery, qualified, proposal, won, and lost. Record next actions and reasons for loss. Count meaningful conversations and qualified opportunities, not just messages sent.

If responses are low, revisit targeting and relevance. If calls happen but proposals do not, improve discovery and qualification. If proposals fail, investigate trust, scope, timing, price, and the decision process. If pilots fail to expand, inspect value and adoption before spending more on acquisition.

A useful knowledge assistant needs a maintained knowledge base, a tested access model, measurable quality, and an owner after launch. Plan these at the start of the pilot rather than treating them as work to add after a successful demo.

Define a pilot before implementation

Write down the department, tasks, source collections, source owners, permitted user groups, delivery channel, supported language, and excluded use cases. Include a maximum agreed scope for documents or data volume where it affects effort.

Identify dependencies: tenant access, platform licenses, service accounts, sample questions, source permissions, and a client reviewer. Record an owner and target date for each. State that delays or changes in dependencies may affect the schedule.

Assign responsibility clearly. The business sponsor owns the outcome; knowledge owners approve source content; IT owns identity and infrastructure decisions; the engineer owns implementation and test evidence; pilot users provide workflow feedback. One person may fill multiple roles, but every responsibility needs a name.

Build an evaluation set that reflects real work

Begin with approximately 80 to 120 questions if the workflow supports that diversity. This is a planning suggestion, not a universal minimum. Include common questions, multi-source questions, ambiguous queries, missing answers, outdated or conflicting content, access restrictions, and malicious instructions embedded in documents.

Record the persona, expected source evidence, expected behavior, and whether the question is answerable. Keep development examples separate from a held-out acceptance set. Let subject-matter experts review the expected answers and adjudicate disagreements.

Evaluate retrieval separately from generation. Relevant evidence can be missing even when a plausible answer appears; good evidence can also be retrieved and then misrepresented. When using automated graders, calibrate them against human review and retain examples of disagreements.

Example acceptance criteria to negotiate

These are proposed starting thresholds for a low-consequence, bounded pilot. Change them to match the workflow and risk. Passing a small test set does not establish universal reliability.

Report counts alongside percentages. For example, “17 of 20 unanswerable questions handled correctly” reveals more than “85%.” Do not combine all metrics into one score that hides a permission failure.

Compare against the current workflow and, where feasible, the native product. Use comparable tasks and counterbalance task order so learning from the first attempt does not artificially favor the assistant. Record verification time and rework, not just answer generation time.

Release and handover

Before release, verify authentication, permission revocation, deleted documents, stale caches, document parsing failures, source conflicts, rate limits, timeouts, and budget controls. Test the deployed user experience, not only a developer preview.

Give the client an architecture and data-flow description, source inventory, evaluation results, deployment procedure, rollback instructions, known limitations, support contacts, and a knowledge maintenance schedule. Explain what changes require reevaluation: models, prompts, parsers, retrieval settings, connectors, or permissions.

During an incident involving possible data exposure, restrict the affected retrieval path, preserve appropriate diagnostic evidence, involve the designated client owner, and follow the client's incident process. Restore service only after the relevant checks pass. Avoid retaining sensitive prompt contents in general-purpose logs by default.

Operations after launch

Review unanswered questions and source gaps with knowledge owners. Monitor failed synchronization jobs, unauthorized-access events, latency, usage, and spend. Use sampled human review to detect quality drift. Maintain a regression set for previously fixed failures.

Track actual active usage and completed tasks. Low usage may signal poor workflow placement, missing trust, or a weak business case. New prompts alone will not fix missing source ownership.

The first 90 days

The plan assumes about 15 to 20 focused hours per week alongside other work. Adjust scope to your available time. It is an execution plan, not a promise of a sale within a fixed period.

A suggested weekly business-development cadence is five researched contacts, two tailored marketplace applications, one partner conversation, and one useful public contribution. Quality and relevance matter more than hitting these illustrative counts. These are activities to try, not conversion forecasts.

Decision points that prevent wasted work

After six to ten discovery conversations, revise the niche if nobody can describe a frequent, costly knowledge problem. If the problem is real but documentation is unusable, offer knowledge cleanup or an assessment before building an assistant.

If buyers like the demo but will not share approved sample data or name a sponsor, investigate whether the interest is practical or exploratory. If pilots show weak savings, stop or narrow the offer. A candid recommendation not to expand can preserve trust.

If you cannot independently implement required identity and deployment controls, pursue employment, subcontract under an experienced team, or reduce the scope. Do not let a sales deadline determine your technical readiness.

A weekly review template

Record what you learned from users, what failed in evaluation, which prospects moved forward, what you spent, and the next smallest experiment. Choose one technical improvement and one commercial improvement for the following week. Keep the record in this folder so progress is visible over time.

Replace all bracketed fields with accurate details. These drafts are prepared for you to adapt; no messages have been sent. Keep prototype results separate from client results, and describe experience only when you can substantiate it.

Profile headline and summary

Headline: AI Engineer for Internal Knowledge Assistants and [Platform] Integration

Summary: I help [type of team] find reliable answers in their approved internal knowledge. My work covers [capabilities you can demonstrate], source citations, access-control testing, and evaluation against real user questions. I start with a focused assessment and recommend a pilot only when the sources, workflow, and business case support it. Portfolio: [link to actual demo and evaluation].

If you have no production references, add: “My portfolio currently includes [accurately describe demonstration projects]. I am seeking a bounded pilot or a delivery partnership in [specialty].”

A first message to a potential client

Subject: Internal knowledge questions at [company]

Hi [name],

I noticed [specific, verified observation]. I am exploring how [team type] handles repeated questions about [workflow].

I build assistants that answer from approved internal sources, with citations and access controls. If finding the right information is slowing your team down, I would be interested in learning how you handle it today.

Would a short conversation next week be useful? I can share a relevant demonstration at [link].

[Your name]

A relevant follow up

Hi [name],

One practical question for this workflow is how staff know they have the current version of [procedure]. My demonstration includes [actual feature or test] because that issue affects trust in the answer.

If this is a current priority, I would be happy to compare it with your existing process. If it is not, no problem.

[Your name]

Use a small number of relevant follow-ups and respect a request not to contact the person again.

An agency partnership message

Hi [name],

Your work on [verified service or project] looks relevant to my focus on internal knowledge assistants. I can support [specific capability you can deliver], including [actual evidence].

I am interested in scoped subcontracting or a joint pilot where your team owns the client relationship and we agree on responsibilities before work begins.

Here is a short demo and evaluation: [links]. Would it be useful to discuss where this fits your current delivery needs?

[Your name]

A marketplace proposal

Your requirement to [specific task from the listing] suggests the first step is to validate [source quality, permissions, or integration dependency].

I would propose three milestones: confirm the workflow and test questions; implement a limited assistant with citations and appropriate authorization; evaluate it with your users and document the result.

Relevant evidence: [real project, clearly labeled prototype if applicable]. Before committing to an estimate, I would confirm [two or three critical unknowns]. The pilot can exclude [explicit scope boundary] to keep the work manageable.

Discovery notes

Client and date: [ ]

Workflow and users: [ ]

A recent real question and how it was answered: [ ]

Question frequency and current time per task: [ ]

Consequences of an incorrect answer: [ ]

Sources, owners, formats, and update frequency: [ ]

Existing search or assistant and its specific gap: [ ]

User roles, restricted content, and identity system: [ ]

Business sponsor, IT owner, and purchasing approver: [ ]

Budget feasibility and decision timeline: [ ]

Pilot success measures and baseline: [ ]

Next action, owner, and date: [ ]

A pilot proposal outline

Problem and intended outcome

[Team] currently uses [process] to answer [question type]. The observed baseline is [measurement, sample, and date]. The pilot will test whether [specific improvement] is achievable without unacceptable quality or access failures.

Scope

Included: [department], [sources and data limits], [user groups], [channel], [language], [question types], and [test period].

Excluded: [autonomous actions, additional sources, migration, unsupported formats, or other boundaries].

Deliverables

An agreed source inventory and access design; the configured assistant; an evaluation report; a user feedback session; an operations and handover guide; and a recommendation to expand, revise, or stop.

Dependencies and schedule

The client provides [access, licenses, reviewers, approved data] by [date]. Work is estimated at [days] after dependencies are available. Delays, new requirements, or unexpected source problems trigger a documented schedule and scope review.

Acceptance

Use an agreed held-out question set and named reviewers. Define correctness, citation support, missing-answer handling, permission tests, latency, freshness, cost, and user-task improvement. Any observed unauthorized disclosure blocks acceptance until resolved and retested. Record known limitations.

Commercial terms to agree

Assessment fee: [ ]. Pilot fee and pricing basis: [ ]. Third-party costs and responsible payer: [ ]. Milestone payment schedule: [ ]. Included revisions: [ ]. Change-request process: [ ]. Support period and hours: [ ]. Ownership of deliverables and pre-existing components: [ ]. Data handling and deletion responsibilities: [ ].

This outline is a commercial drafting aid, not a finalized legal agreement. Use the client's procurement and contracting process to settle binding terms.

Decision after the pilot

The sponsor reviews the evaluation, adoption, operating cost, and unresolved limitations. Expansion requires an explicit scope and ownership decision; it is not assumed from completion of the pilot.

A case study structure

Customer context: [Use a name only with permission.]

Problem and baseline: [Measured task, volume, time, and period.]

Constraints: [Sources, permissions, tools, budget, and delivery limits.]

Implementation: [What you actually delivered and why.]

Evaluation: [Dataset, sample sizes, baseline, reviewers, and test conditions.]

Outcome: [Measured result with denominators and period.]

Limitations: [Failures, excluded workflows, and confidence limits.]

Handover: [Who owns the knowledge and operation.]

For synthetic projects, put “Demonstration using synthetic data” at the top and report technical results without implying business savings.

Sources checked on 2 November 2026. Platform capabilities, partner requirements, and commercial terms can change. Follow the linked official documentation when scoping a real engagement.

The niche recommendations, sales process, learning plan, pilot thresholds, pricing examples, and ROI scenarios are proposed working methods. They are not vendor promises, salary surveys, market benchmarks, or measured customer results. No named organization is represented as a qualified prospect or confirmed buyer.