“My order is late, and I want to speak to a person.” Who receives that message in the new support system? Does the employee know what the customer said before handover? Does the request stay open after an automated answer? A list of channel names or the phrase “AI-powered” cannot answer these operational questions.
In a fictional furniture store, a team starts by choosing a platform to combine messages. During planning, it discovers that complaint categories, handover rules and approved response content have not been defined. A subscription provides tools. Turning them into an appropriate service requires configuration, decisions and testing with a separate scope.
Question one: what are we buying from the platform?
Identify the product, plan, channels, roles and capabilities actually required. Check their availability in the proposed plan when purchasing. Pricing may depend on seats, usage or add-ons. Do not treat implementation fees as the complete platform bill, or assume a capability in a presentation is included in every subscription.
Review what you already have. A suitable existing ticketing system may need better rules and order-system integration rather than replacement. Ask why a platform is proposed and how migration affects conversations and roles, without making a tool change the project's objective.
Question two: what will the implementation company do?
Zendesk's documentation explains rules as conditions linked to actions. The platform supplies the mechanism, but someone must choose suitable conditions, configure their order and test the results. Classifying a message as a complaint can change its team or send a notification. A wrong decision affects daily work even when the platform is technically operational.
Complete a scope worksheet with the provider. For each item, record the deliverable, its owner and the evidence used at acceptance:
- Channels: What will actually be connected, who owns the accounts, and which inputs or external approvals are needed?
- Classification and assignment: Request types, teams, rules and exceptions to configure.
- Knowledge: Approved content, its preparation and the owner of publication and updates.
- Human handover: When it occurs, which context arrives and what customers see while waiting.
- Data and integration: What is read from the order system, what can change and each role's permissions.
- Operation: Training, monitoring, reporting, support and the work your team retains.
These items differ in effort, and all do not need implementation immediately. Exclusions should be deliberate and have an alternative workflow. If order integration is outside phase one, staff need a manual lookup process instead of waiting for information that will never arrive.
Question three: who prepares the answer content?
A large collection of files is not automatically publishable knowledge. Separate approved customer policies from internal instructions and outdated material. Request a sample: a delivery-time question, the source authorizing an answer and what happens when the time depends on the product.
Intercom's documentation shows that source types have different compatibility with knowledge tools, AI and self-service. Do not assume that uploading a file makes it available identically to every channel or user. Request the sources, visibility and update behavior of the chosen solution instead of a broad promise that it “learns from everything”.
In the fictional furniture store, internal compensation instructions should not become a customer promise of a refund. Define what can be explained automatically and what requires an authorized employee. If no approved answer exists, make acknowledgement and handover an explicit path rather than encouraging a guessed response.
Question four: did the complete service journey work?
Test the late-order message. First inspect its classification and routing. Then review the answer and its information boundaries. Finally request a person and confirm that appropriate context and available conversation history arrive, allowing the employee to continue without asking the customer to repeat everything.
Repeat outside agreed working hours, with a question missing from the knowledge base and when order status cannot be read. Write the expected result before testing and the actual result afterward. A fast answer or “resolved” message does not prove resolution: a ticket may close while the customer still needs action.
Agree measures that describe the service: correctly routed requests, cases returning after closure and handover waiting time with a clear definition. Ask how they are calculated and inspect a sample. A sales presentation's cost-saving or staffing-reduction percentage is not an established result for your operation.
Who owns changes after launch?
A new complaint type will appear or a delivery policy will change. Identify who updates content, approves a rule and tests its effect before publication. At the end of implementation, your team should know which accounts, settings and materials it received and what requires an additional service.
For sales opportunities rather than support tickets, read the CRM implementation scope guide. When buying customer-service automation, start with the worksheet and handover journey. Treat subscription, configuration and ongoing management as understandable, accountable items instead of one amount hiding who does the work.
Research record
Zendesk's explanation of triggers and Intercom's knowledge-source documentation were opened on 3 November 2026. They explain tool boundaries rather than recommend a platform or establish a capability in a particular plan. The worksheet and example are original editorial proposals. The text was prepared with AI assistance and review of its content and sources.
