Vercano Partners / Services
AI receptionist for contractors
An AI receptionist configured for your industry and company can collect basic information and explain the next step. It must not promise availability, diagnose a problem or replace judgment on unusual requests.
Define the assistant’s permitted role
An AI receptionist should collect information, explain approved service facts and route the next step. It is not a licensed technician, a claims decision-maker or an office manager. Define what it can say and what must go to a person. The approved boundaries matter more than a convincing speaking style.
Decide where contacts, requests, appointments and jobs are owned before building automations. Your custom CRM can support the intake and follow-up process configured by Vercano, while an existing operational tool may remain responsible for dispatch or job management. A claimed integration is not proof that the exact handoff will work. Identify which status changes should move between systems and what happens if a connection fails. The office should understand the boundaries before relying on the workflow.
For approved knowledge and boundaries, define the information required, the person responsible and the event that completes the step. Review a realistic request and an exception with the team. If the customer replies or changes plans, the record and message must reflect the current situation. A normal-path demonstration is not enough when real work includes missing details, repeated requests and decisions that need a qualified person. Confirm the responsibility before launch rather than assuming somebody will notice the next task.
Build from current business facts
Use the services, coverage, contact details and booking rules the company confirms. Do not feed the assistant invented credentials, office locations or customer outcomes. Assign a person to update the information when operations change. An answer that was correct at launch may become misleading after a service area or schedule changes.
Use stages that represent an actual customer decision or team action. New inquiry, appointment arranged and proposal sent are useful only if staff know what belongs in each stage. Record an owner and next action alongside the status. Avoid moving a request to booked merely because an automated acknowledgment was sent. The pipeline should tell the team what has happened and what remains, not turn unfinished work into an optimistic label.
For intake questions, define the information required, the person responsible and the event that completes the step. Review a realistic request and an exception with the team. If the customer replies or changes plans, the record and message must reflect the current situation. A normal-path demonstration is not enough when real work includes missing details, repeated requests and decisions that need a qualified person. Confirm the responsibility before launch rather than assuming somebody will notice the next task.
Ask useful intake questions
Collect the service needed, location, contact preference and enough context for the office. Do not gather unnecessary sensitive details. Questions should fit the trade: equipment symptoms differ from a remodel’s budget discussion. A request should reach the team with the original concern intact, not a confident but inaccurate summary of a diagnosis.
An instant message can say that a request arrived and ask for basic details. It must not imply that someone reviewed the problem, approved the price or confirmed availability. Replies should reach an assigned person. Missed-call text-back needs routing, duplicate checks and a policy for existing customers as well as new leads. A customer who answers the automated message should not be left in another unattended channel.
For calendar rules, define the information required, the person responsible and the event that completes the step. Review a realistic request and an exception with the team. If the customer replies or changes plans, the record and message must reflect the current situation. A normal-path demonstration is not enough when real work includes missing details, repeated requests and decisions that need a qualified person. Confirm the responsibility before launch rather than assuming somebody will notice the next task.
Availability needs a real source
A calendar request should use actual confirmed booking rules. If the office must approve a job, the assistant should say the time is requested, not confirmed. Check time zones, canceled appointments and conflicting tools. Do not let the assistant infer service capacity from a blank calendar or promise an arrival window it cannot verify.
A requested appointment and a confirmed appointment are different states. Decide which requests can use a calendar and which require office review. Reminders should match the confirmed details and stop when a booking changes or is canceled. Test time-zone handling, replies and missing information. If your operational software owns scheduling, review the connection instead of adding a second calendar whose availability can disagree with the first.
For human escalation, define the information required, the person responsible and the event that completes the step. Review a realistic request and an exception with the team. If the customer replies or changes plans, the record and message must reflect the current situation. A normal-path demonstration is not enough when real work includes missing details, repeated requests and decisions that need a qualified person. Confirm the responsibility before launch rather than assuming somebody will notice the next task.
Safety-sensitive questions go to qualified staff
Electrical faults, pest treatment concerns and unstable doors require boundaries. The assistant should not offer hazardous troubleshooting or unsupported safety claims. Define escalation for emergency descriptions and unusual situations using the company’s real policy. If there is no emergency dispatch service, do not advertise one through automated language.
Record the estimate version, customer questions, decision timing and contact preferences. A follow-up message should invite clarification rather than pressure. When a customer replies about scope or price, a person needs to take over and generic reminders should pause. Close inactive opportunities according to the company’s process and respect a decline or opt-out. Repeated messages cannot compensate for an unclear proposal or a conversation nobody owns.
For conversation review, define the information required, the person responsible and the event that completes the step. Review a realistic request and an exception with the team. If the customer replies or changes plans, the record and message must reflect the current situation. A normal-path demonstration is not enough when real work includes missing details, repeated requests and decisions that need a qualified person. Confirm the responsibility before launch rather than assuming somebody will notice the next task.
Customer concerns need a human route
A complaint, disputed scope or pricing exception is not a normal intake question. Give the customer a reliable route to a person and assign ownership internally. Repeating the same automated answer is not resolution. Staff need to see what was already said so the human reply can correct uncertainty rather than starting from scratch.
Use a consistent completion trigger and invite honest feedback from real customers. Do not ask only customers expected to leave a positive rating, offer rewards for favorable reviews or direct unhappy customers away from public feedback. Check the review link, recipient and duplicate prevention. A direct route for service concerns can sit alongside the public review invitation, but it must not become a gate that selects which customers may review.
For approved knowledge and boundaries, define the information required, the person responsible and the event that completes the step. Review a realistic request and an exception with the team. If the customer replies or changes plans, the record and message must reflect the current situation. A normal-path demonstration is not enough when real work includes missing details, repeated requests and decisions that need a qualified person. Confirm the responsibility before launch rather than assuming somebody will notice the next task.
Review representative conversations
Test the questions staff receive in reality, including unclear requests and topics outside the service list. Check whether the assistant admits uncertainty, routes correctly and avoids promises. A smooth example conversation is not enough. Review summaries for missing context and verify the original information remains available to the responsible person.
SMS and calls are billed at cost separately from the CRM package. Give team members the access they need and decide who can change workflows. Document contact preferences and opt-outs. Keep customer notes factual and appropriate to the task. The system is not finished when every switch is on: it needs a person responsible for changes, exceptions and the practical questions that appear once the team starts using it.
For intake questions, define the information required, the person responsible and the event that completes the step. Review a realistic request and an exception with the team. If the customer replies or changes plans, the record and message must reflect the current situation. A normal-path demonstration is not enough when real work includes missing details, repeated requests and decisions that need a qualified person. Confirm the responsibility before launch rather than assuming somebody will notice the next task.
Keep the package scope clear
AI receptionist and chat are listed in the Scale CRM tier. Do not interpret a separate page as a new fixed-price product. The strategy call confirms the intended use and configuration, with usage billed according to the agreed scope. Ongoing changes need an owner who reviews facts and exceptions as the business develops.
Test duplicate inquiries, repeat callers, missing information, canceled appointments and customers who reply. Follow a request until the assigned staff member sees the next step. CRM and automation takes one to two weeks depending on pipeline and workflow structure. A successful demonstration of the normal path is not enough if a changed date sends an irrelevant reminder. Review the system as operations change so its messages remain accurate.
For calendar rules, define the information required, the person responsible and the event that completes the step. Review a realistic request and an exception with the team. If the customer replies or changes plans, the record and message must reflect the current situation. A normal-path demonstration is not enough when real work includes missing details, repeated requests and decisions that need a qualified person. Confirm the responsibility before launch rather than assuming somebody will notice the next task.