Zendesk’s new-request form is the most common place this is installed, so here it is end to end. The same shape applies to Freshdesk, Front and Jira Service Management — only the selectors change.

​
Where the script goes

Admin Center → Channels → Guide → Customize design → Edit code, then open new_request_page.hbs. Inside <div id="main-content" class="form">, put the script immediately before <div id="new-request-form"></div>:
Everything below is configured on the deflector in the dashboard, not in the template — which is the point: Zendesk theme edits need a publish, and your form’s markup will change again.

​
The selectors

Zendesk’s markup differs between the classic theme and the current Copenhagen one, and again on any theme your team has customised. Start with the attribute selectors — they survive a theme change that renames ids: Anchoring after the description field rather than at the button puts the notice where the reader is already looking — they have just finished typing into it — and keeps the strip clear of whatever your theme has stacked around the submit control. onClick because the Copenhagen theme’s submit is a real <button> with a click handler. On an older theme it is an <input type="submit"> and onSubmit is right; the deflector writes value on an input and textContent on a button either way, so only the event differs.
If your form is customised past recognition, open it and copy the selectors from the elements themselves. The four that matter are the description field, the submit control, somewhere to anchor, and — if you want attribution — the email input.

​
Extra fields worth sending

The subject and the product dropdown, as labelled context: A Zendesk custom field’s id is the numeric field id from Admin → Fields. The dropdown sends its visible label, so “Product area: Billing” reaches the model rather than “Product area: 360001”.

​
Copy

​
Hand-off into a hidden field

Create a custom field in Zendesk (Admin → Fields → Add field, type Multi-line), and set its permission to Agents can edit so it never renders for the requester. Then: Now every ticket that arrives despite an answer carries the question, the answer and the sources — so the agent starts from “that page didn’t cover your case”.

​
The rich-text case

If your Guide theme uses Zendesk’s rich-text description editor, the field is a contenteditable, not a textarea. Set Question field is a rich-text editor on and point the question field at the editor’s own element — the deflector converts the markup to text before sending it. Do not point the hand-off target at that field: a rich-text editor can rewrite its own value at submission time and drop what was written into it. Use the hidden custom field above.

​
Signed-in vs anonymous

The anonymous requester email field exists only for signed-out requesters. On a Guide that requires sign-in there is no email field to read, and the deflection stays anonymous under the browser id — which is fine, and is what user tracking documents.

​
Test it

  1. Open the request form signed out, in a private window, with data-debug-mode="true" on the tag.
  2. Type a real question of at least 25 characters into the description.
  3. Press submit. The modal should open with an answer and its sources.
  4. Press Continue to submit ticket. The ticket is created, with the transcript in the hidden field.
  5. Check Activity on the deflector — the interception should appear under Filed anyway.
Step 5 is the one people skip, and it is the one that proves the numbers are honest.

​
Not the same as the Zendesk connector

Two different features, often confused:
  • This page — the deflector, on the form, before a ticket exists.
  • Zendesk as a source — indexing your solved tickets so they can be answered from.
  • Helpdesk automation — answering tickets that were filed anyway, from inside Zendesk.
They compose. Index the tickets, deflect on the form, automate what gets through.