Connect a specific customer route with a clear purpose

02 · Enquiries & Appointments

What the implementation supports and what must be verified

This matrix records repository scope, not a promise that your accounts are connected. Each external route still needs its actual configuration and health check. A provider can require approval or permissions beyond the code itself; a changed account or expired access can affect the next message. Use the setup discussion to confirm the specific route you need, rather than activating every listed channel.

04 · Enquiries & Appointments

Test the route the customer will actually use

For a messaging connection, test an incoming fictional question, a response, an unknown question and an unsupported attachment where relevant. For booking, check a valid slot, a conflict and the configured calendar behavior. Inspect the stored conversation or appointment as well as the visible response. Keep test traffic outside customer performance figures and use approved test identities; the public visual cannot prove external delivery.

Agree who owns reconnecting, changed permissions and provider notices. The business should retain control over its accounts and installation. Initial service enquiries need a description of your tools and intended process, not passwords or access tokens. If a new route cannot be verified, continue through the established website and human process rather than treating a directory listing as a working replacement.

Check incoming persistence and outgoing delivery separately. A stored customer question is not proof that a reply reached them, and an attempted response is not a delivered response. When the provider reports a failure, inspect the unresolved conversation and decide the appropriate alternative. Avoid asking the customer to send the same enquiry repeatedly just to make a connection appear healthy; the team should understand which part needs attention.