Bring one reproducible observation
A web-shop introduction is stronger when the caller can describe something concrete the business can check. A broken public booking link is a different reason to call from an unsupported claim that the whole website is losing sales. Record what you observed, when you checked it and the page involved. Do not invent revenue loss or present a sales call as a security warning.
Research happens outside DialBreeze. The product is the calling workflow, not a crawler, performance tester or vulnerability scanner. A prospect may explain that the apparent problem is intentional; leave room for that answer rather than forcing every observation into a redesign pitch.
Scope the first conversation around ownership
Ask who manages the site and whether the business wants to discuss the observation. The person answering may run operations but not control the domain, hosting or budget. A useful discovery next step identifies the relevant decision maker without pretending the receptionist authorized a project.
Keep passwords, hosting access and private analytics out of calling notes. If the business wants an assessment, use your approved intake and permission process. Do not log into a system on the strength of an ambiguous phone reply or request access before the scope is understood.
Separate repairs from rebuilds
A small broken form does not automatically justify a complete replacement. Capture the requested outcome first: restore bookings, clarify a service page or assess a migration. Let the delivery team decide what investigation and estimate are required. The dialer cannot validate a technical solution or promise a launch date.
Choose the closest built-in disposition and add a task describing the agreed next conversation. Detailed scope, acceptance criteria and estimates belong in your project or proposal tool. There is no native two-way project-board integration; test a signed-webhook handoff if your team uses one.
Make renewal calls about the actual agreement
An existing maintenance customer needs a different agenda from a new prospect. Review the current agreement in your own system and ask about unresolved requests. Do not imply that a renewal automatically includes a redesign, extra hosting capacity or a new service unless the agreement says so.
A former client may no longer own the business or manage its website. Confirm the relationship before discussing the previous engagement, and honor requests to stop further contact. The calling record should distinguish a proposed discovery meeting from a support issue requiring a separate ticket.
Hand delivery a question it can answer
Before passing the conversation on, identify the public observation, the customer’s stated goal, a known constraint and the next participant. An engineer can prepare for a form-repair discussion; a note saying only needs a better website creates avoidable requalification.
Pilot this with fictional records covering a broken public link, a maintenance review and a prospect declining help. Confirm that no credentials enter the notes and that the accepted action reaches the correct human owner. Evaluate your own discovery quality, not an invented web-agency close rate.