The AI answered. Now write the handoff.

A useful first version does not need permission to handle everything.

It may be allowed to:

• Confirm business hours.
• Explain the service area.
• Collect a name and preferred contact method.
• Ask what kind of help the customer needs.
• Answer a short list of approved questions.
• Share a scheduling link.
• Let the customer know when someone will respond.

These jobs are frequent and predictable. A person can easily check whether the system handled them correctly.

That is enough to save real time.

Complaints, negotiations, unusual pricing, refunds, emergencies, and decisions with real consequences are different work.

Do not hide the handoff rules inside a giant prompt nobody will read again.

Write them in plain language.

For example:

Send the conversation to a person when the customer is upset, mentions safety, disputes a charge, requests a refund, asks for a firm price, or asks something outside the approved information.

The exact rules depend on the business.

A plumber may need rules for active leaks and gas concerns.

An automotive shop may need rules for safety complaints, warranty disputes, and vehicle-specific pricing.

A dental office may need stricter boundaries around symptoms, treatment, insurance, and personal information.

You do not need to predict every sentence a customer might type.

You need to identify the decisions the software is not authorized to make. For more on where automation should stay out, see when not to automate.

A customer should not have to type "representative" six times.

Direct requests should work:

• I want to talk to someone.
• Can a person call me?
• This is not answering my question.
• I am upset.
• Quiero hablar con una persona.

There should also be a visible path to a person before the conversation goes bad.

That path might:

• Transfer the conversation during business hours.
• Collect a callback request.
• Send a note to the owner or office.
• Provide the correct phone number.
• Explain when someone will reply.

"Someone will contact you soon" is weak.

"Someone from the office will call you by the next business day" is useful, as long as the business can consistently keep that promise.

The system should also tell the customer that it is software. It should never pretend to be an employee.

A bad transfer makes the customer start over.

A useful transfer gives the person:

• The customer's name
• Their contact information
• What they need
• The relevant location, service, or vehicle
• What the system already told them
• Why the conversation was handed off
• Any deadline or urgency the customer mentioned

The person receiving the handoff should understand the situation before calling or replying.

Otherwise the customer has completed two intake processes instead of one.

That is not automation. That is duplicate work.

Customers will type information you did not expect.

An address. An account number. A medical concern. A payment dispute. Insurance information. Something private about their family.

Before the system goes live, decide:

• What information does it actually need?
• What should it never request in chat?
• Where are conversations stored?
• Who can review them?
• How long are they kept?
• Which outside tools receive the information?
• What does the privacy policy promise?

Do not claim that information is private, deleted, or never used for training until the actual tools and settings support that statement.

Collect what the workflow needs. Leave the rest alone.

Most demos test this:

"What time do you open?"

"We open at 8."

That proves the system can retrieve business hours.

It does not prove the workflow is ready for customers.

Test these instead:

• "Your technician damaged my property."
• "You charged me twice."
• "Tell me exactly what this repair will cost."
• "I need to cancel and get my money back."
• "Can you diagnose this from a photo?"
• "Do not have anyone call me."
• "No entiendo. ¿Me puede explicar en español?"
• "That is not what your employee told me."

The right result is not always a better paragraph.

Sometimes the correct result is to stop, collect one missing detail, and involve a person.

After launch, review the real handoffs:

• Which conversations were transferred?
• Which should have been transferred but were not?
• Which answers did a person correct?
• Which questions keep appearing?
• Did the team meet the response time it promised?
• Did the system collect information it did not need?

A spreadsheet and thirty minutes a month may be enough.

The habit matters more than the tool.

Before an AI system talks to customers, the business should be able to complete these lines:

• 1. The AI may handle:
• 2. The AI may never decide:
• 3. It must involve a person when:
• 4. The customer can request a person by:
• 5. The person receiving the handoff gets:
• 6. The customer is told to expect:
• 7. We review mistakes and handoffs every:

If those answers are unclear, the workflow is not ready.

Start with a small set of approved questions and actions. Watch what happens. Fix the weak spots. Give the system more responsibility only after it handles the current job reliably.

Software can handle the repeatable front line.

People keep the relationships and the exceptions.