A CRM helpdesk should preserve the customer’s request, its current owner and the next action through every reply and escalation. Define the ticket states, access boundaries and handoff evidence before adding automation. Test a complete issue from receipt to closure, including a team transfer and a ticket with no matching service target.
A customer relationship record explains context; a ticket organises a specific piece of support work. Keep the two linked without forcing the customer to repeat information already available. The support team should be able to identify the problem, the latest customer reply and the person responsible for moving it forward.
This guide’s original escalation relay card uses a fictional issue to evaluate those responsibilities. Frappe Helpdesk’s ticket and customer-portal documentation provide concrete examples of ticket creation, assignment and visibility. The exercise checks the workflow rather than claiming a particular support response time.
What should become a ticket?
Frappe Helpdesk documents ticket creation through the customer portal or a configured email address. Record which routes the proposed setup enables and how an incoming request is associated with the correct contact and organisation. Use a dedicated test destination and fictional content during evaluation; do not send test traffic into a real customer queue without an agreed test arrangement.
Frappe Helpdesk tickets take a subject and description from the user. The ticket guide provides the basic record structure. In the brief, add the context needed for the actual task: the affected service, relevant reference and requested outcome. Keep required fields purposeful so customers are not asked for detail that the support team will not use.
Frappe’s documented customer portal lives at the help path on the site. The customer portal shows the same records used by the agent portal. The portal guide makes the relationship between customer and agent views explicit. Inspect both views for the same fictional ticket. A successful internal creation test alone does not establish that the customer can find the issue or follow the conversation.
The portal disables ticket creation until all attachment uploads finish. Include a harmless attachment in the test. Check the visible upload state and the resulting ticket before reporting receipt. An unfinished upload should not be mistaken for a submitted issue, and the customer should understand what remains to be done.
Who owns the issue during escalation?
An agent can assign a ticket to another agent or escalate it to another team. Define what acceptance by the receiving person means in your process. A changed assignment is useful evidence, but the team also needs enough context to continue. Preserve the customer’s problem, work attempted, findings and the specific decision needed from the next team.
Agents can use comments to document investigation findings. Inspect where those findings appear and which viewers can see them in the proposed configuration. Keep customer-facing replies and investigation records deliberate. Do not assume a field is private simply because an agent entered it rather than a customer.
Write the escalation rule around an unresolved task. “Needs technical investigation” should identify what needs investigating and who takes it. Avoid a relay in which the original owner assumes the transfer is accepted while the receiving queue assumes someone else is still answering the customer.
| Relay-card field | What to record | Acceptance question |
|---|---|---|
| Ticket identity | Stable reference and correct customer | Are both teams discussing the same issue? |
| Current problem | Customer’s description and intended outcome | Can the next agent explain the request? |
| Investigation | Checks performed and relevant findings | What should not need repeating? |
| Next action | Specific task and responsible person or team | Who acts now? |
| Customer communication | Latest reply and agreed next update | Does the new owner know what was said? |
| Closure | Resolution evidence and final state | Is the customer journey complete as intended? |
What does a service target actually mean?
A ticket matching no SLA policy has no response or resolution target. This documented exception is essential when evaluating a dashboard or customer timeline. A missing target is not evidence that the issue is overdue, fulfilled or subject to an invented response promise. Identify whether a policy applies before interpreting the displayed state.
For an applicable target, retain the policy and its configured conditions in the test record. Ask the demonstrator to explain the first-response and resolution indicators separately. They describe different milestones; an initial acknowledgement should not be mistaken for resolution of the customer’s underlying request.
Keep business commitments under the responsible owner’s control. The exercise can test whether a target is shown and whether state transitions are explainable without inventing a deadline. If no policy matches a class of request, record whether that is intentional and who owns the policy decision.
How should customer access and closure be checked?
A customer manager can see tickets from the Customers they manage. Include organisation roles in the access brief. Test the intended customer contact, customer manager and an unrelated fictional organisation separately. Record what each can see and where the ticket appears. The assigned agent’s visibility is not a substitute for a customer-boundary test.
The portal documentation says a closed or rated ticket cannot receive further customer replies. Use this documented portal behaviour when designing the final step. Distinguish resolution from final closure in the customer journey, and decide what route someone should use for a later issue. Preserve the original ticket reference in any proposed new-request process rather than assuming every interface permits replying to a closed ticket.
Review current portal behaviour in the selected installation before approving the workflow. The acceptance record should describe actual states and actions with the tested version, especially where an older ticket description and a newer portal interface use different wording about continued conversations.
Original escalation relay card
Consider a hypothetical customer who cannot open a report. The first agent confirms the affected report and captures a harmless screenshot; a second team needs to investigate the access configuration. These are fictional exercise conditions, with no live account or service change implied.
Receipt leg: Create the issue through the proposed portal route with the screenshot. Record the ticket reference and customer association. Open the same ticket as an agent and customer and compare the request. Check that the upload has completed and the attachment appears in the intended view.
Investigation leg: Record the first agent’s findings and a precise question for the second team. Ask another reviewer to explain what has already been checked. If they need to ask the fictional customer the same basic question again, improve the handoff content before continuing.
Transfer leg: Assign or escalate through the demonstrated workflow in the test copy. Record the resulting owner, next action and evidence that the receiving team can find the ticket. Send no real external message as part of this worksheet; inspect proposed communication using the agreed test setup.
Policy leg: Run one case with an applicable test policy and one without a match. Record what the customer and agent see in each. Keep the policy-free case explicit so a later dashboard interpretation cannot silently invent a response target.
Closure leg: Apply the agreed resolution and closure sequence in the test environment. Inspect the customer’s available actions afterwards and the proposed route for a new issue. Retain the original request, findings and final evidence so the next colleague can understand how the case ended.
For broader context, see business systems and business email. To discuss a helpdesk workflow, get started with the escalation relay card and the ownership gaps your support process needs to close.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.