Give every company the same business problem
Start with a short brief that describes the visitor, the task and the result your team needs. For a service business, that might be helping visitors understand an offer and recording an enquiry with a name, a usable contact method and the requested service. Include where the assistant will appear, the languages you need, your existing website and the destination for leads. Separate requirements for the first release from ideas for later. Sending the same brief to each company makes proposals comparable: otherwise one team may price a simple FAQ widget while another includes account access, document search and CRM automation.
Decide what the assistant can answer and change
An assistant that explains services needs different controls from one that retrieves private order details or changes a booking. Ask the developer to describe the approved knowledge sources, how content updates reach the assistant and what happens when an answer is unavailable. Then identify each permitted action and its prerequisites. An order lookup may require a signed-in customer; changing an order may also need confirmation and a record of the change. A sales assistant can welcome an unusual project idea without inventing a fixed price, a delivery promise or experience your company has not supplied. The proposal should name these boundaries.
Ask for a demonstration with your own awkward examples
A prepared conversation shows the interface, but your examples reveal how the proposed workflow behaves. Supply anonymised questions about your actual services, an ambiguous request, a misspelt email, a visitor who changes their contact details and a request outside the agreed scope. Ask to see a successful lead arrive in a test destination and an unsuccessful save produce understandable feedback. If the demonstration uses a simulated CRM connection, have the team label it clearly. For any customer reference, ask what was delivered, what remains in development and whether the client has approved public use of the example. A prototype is useful evidence of an approach when its limits are stated.
Evaluate the integration as a separate deliverable
A fluent chat response does not prove that the right record reached your sales team. Discuss which system owns the contact, which fields are required, how duplicates are matched and who receives the enquiry. Ask how the application distinguishes a draft, a submission accepted for processing and a confirmed CRM save. The team should explain what happens if your CRM is unavailable, credentials expire or the visitor submits twice. Include a test environment and realistic records in the scope. If your business starts with Google Sheets, document who can access the sheet, the expected columns and what would need to change when you move to a CRM.
Compare the full operating commitment
Request separate descriptions of discovery, development, integration, evaluation, hosting and ongoing support. Ask which usage costs come from model providers, messaging platforms or other external services, and how you will see those costs. A provider account, quota or free allowance is an external dependency; it should not be presented as an unlimited production plan. Define what happens during provider outages and who can approve a model change. Compare proposals against the same expected traffic and conversation scope instead of the lowest headline figure. A clear first release with explicit exclusions is easier to assess than a promise to automate every department.
Agree ownership and responsibilities before the build
Establish who owns the source code, domain, hosting account, integration accounts, knowledge content and resulting business records. Ask for access and an export or handover approach appropriate to each system. Identify who maintains the approved answers, reviews unanswered questions and handles failed lead submissions. The delivery plan should cover configuration guidance, an operating runbook and the process for changing providers or ending support. Data retention, deletion, access controls and provider data use need decisions suited to your business; a technology name alone does not establish compliance. Where formal regulatory requirements apply, have the relevant specialists review those requirements as part of the project.
Use acceptance evidence to make the final decision
Write down the conditions under which you would accept the release before comparing final proposals. Examples include accurate answers to approved service questions, validated contact fields, a lead appearing in the correct test destination, an understandable recovery path after a save failure and a usable mobile conversation. Require evidence for consequential actions and have your team review response quality. Ask who signs off the test results and how regressions are checked after content or model changes. EidenTech can use this brief to scope chatbot development alongside website development and business integrations. The useful outcome of discovery is a shared release plan with testable responsibilities.
Your project checklist
- Send the same audience, use case, channels and first-release requirements to every candidate.
- Define approved knowledge sources, permitted actions and when the assistant hands over to a person.
- Use anonymised examples from your business in the demonstration, including incomplete and contradictory inputs.
- Verify a test lead in its actual destination; identify any simulated connection.
- Compare external usage costs, provider limits, maintenance scope and support responsibilities.
- Agree source-code ownership, account access, record exports and handover documentation.
- Set acceptance conditions for answer quality, successful records, failure recovery and mobile use.
- Name the business owner who approves content, evaluates results and authorises future changes.
Share what you know, highlight the open questions, and agree the next decisions with your development team.
Discuss your project brief ↗Relevant EidenTech services
Explore the working EidenTech website lead chatbot →