Start with the next person
An integration may look up a contact, write a note, create a task or change an opportunity. These are different capabilities. Follow one inquiry through the proposed workflow and name the person who must act after the conversation.
Write down what that person needs: the request, relevant service or property, missing details and follow-up channel. Separate caller statements from facts verified against business records. A useful handoff preserves that distinction.
Name the record owner and permitted actions
Your CRM may own contact identity while a calendar owns availability. A different value supplied on one call should not silently overwrite a verified record. Missing information should remain identifiable.
Ask for a written list of permitted reads and writes, the account performing them and the records it can access. Reading availability does not authorize booking; writing a note does not authorize changing an opportunity. API access, field structure and business rules determine what can be connected. Evaluate the specific implementation rather than an integration logo.
Test repeat callers and uncertain writes
A person can call twice, and the same event can arrive twice. Ask how the system recognizes an existing contact, preserves a genuinely new inquiry and avoids repeating an action when an event is replayed. Shared phone numbers and incomplete identities must not silently merge unrelated people.
A timeout does not prove a write failed. A CRM might create a task and lose the response. Blindly creating it again can produce a duplicate. The workflow needs to check the result or hold it for reconciliation before retrying.
Check what the destination received
Use the same acceptance scenarios for every provider. Inspect both the destination record and what the caller was told.
| Scenario | What to demonstrate |
|---|---|
| New inquiry | Correct record, required fields and a receiving owner. |
| Existing customer calls again | Correct match with verified values and prior context preserved. |
| Same event replayed | No additional contact, task or booking for that action. |
| Write times out | Result checked or held for reconciliation. |
| Transfer unanswered | Truthful explanation, retained request and follow-up owner. |
| Appointment requested | Calendar acceptance before describing it as booked. |
| Request outside scope | A defined escalation without an invented answer or unauthorized action. |
Assign fallback and maintenance responsibility
If a destination is unavailable, decide where the request is retained, who investigates and how staff learn it needs attention. A draft, submission, receipt and completed staff action are different states.
Phone, email and web can have different consent, identity and response rules. Demonstrate each agreed path and the context it shares. Urgent or sensitive requests need an appropriate business-specific escalation route. Name who maintains mappings, permissions and rules as tools or staff change.
Scope the implementation and evaluate the effort
Bring inquiry types, existing tools, receiving staff and permission-cleared examples to a scoping conversation. Separate available actions, configuration, custom work and exclusions. Ask who maps fields, tests handoffs and owns later changes; record support hours and included maintenance.
A useful pilot demonstrates one complete handoff before adding more actions. To evaluate staff effort, time comparable inquiries before and after, including corrections, duplicate cleanup, escalation and recurring administration. Check quality alongside speed. Model response time alone is not staff time saved.