Connecting StretchForms and Support Intake

What support intake does

Support intake is the bridge between the forms on your sites and your ticket board. When someone fills out a support form — a "Contact support" page, a help request, a bug report — that submission surfaces in StretchSupport as an intake candidate: a request you can review and convert into a proper ticket. It's how requests get into the system without anyone re-typing them.

How a submission becomes an intake candidate

StretchSupport looks for form submissions whose type is tagged as support (any form type that includes "support"). Those submissions appear under Support intake, newest first. Each candidate shows:

• Brand and site — where it came from.
• Form type — which form was submitted.
• Source page — the page the customer was on.
• Status and pipeline stage — where the submission sits.
• Submitted at — when it arrived.

The dashboard also shows a support intake candidates count so you always know how many submissions are waiting to be turned into tickets.

Converting a candidate into a ticket

1. Open Support intake from the rail.
2. Review the newest candidates. Read the source page and form type to understand the context.
3. Convert a candidate into a ticket — carrying over the subject and message.
4. Keep the ticket linked to the originating submission so the form data stays attached (the ticket stores the linked submission and form key).
5. Triage the new ticket as usual: set priority, severity, category, and route it to a queue.

Note: A ticket created from intake keeps a reference to the submission it came from. That link is what lets you trace a ticket back to the exact form and page that generated it — useful when a specific page's form is producing a spike of requests.

Keeping intake clear

Treat the intake list like an inbox:

• Convert promptly. A submission that never becomes a ticket is a customer waiting with no ticket on the board and no SLA clock running.
• Watch for patterns. If one source page or form type is generating a burst of candidates, that page or feature likely has a problem worth a knowledge-base article — or a fix.
• Zero it out daily. Use the dashboard's intake-candidate count as a daily target to hit zero.

A realistic example

Overnight, three submissions arrive from your Contact support form. In Support intake you see all three, each showing the brand, site, and source page. Two are password questions from the account page and one is a billing dispute from the pricing page. You convert all three into tickets, keeping each linked to its submission. You route the two access questions to Account & Access (High) and the billing dispute to Client Success, then send first-response macros. Because the two access tickets came from the same page, you note it and later publish a self-serve reset article to cut the volume.

Tips

• Check Support intake at the same cadence you check the board — it's where forms-based requests hide until you convert them.
• Always preserve the linked submission on conversion; it's your audit trail back to the original form data.
• Use the source page field to find hotspots — a page generating many support forms usually signals a UX or content gap.
• Convert first, triage second: get the ticket onto the board (and its SLA clock running) before refining fields.

FAQ

Which submissions show up as intake candidates? Any form submission whose type is tagged as support. They appear newest-first under Support intake.

Does converting a submission delete the original? No. The ticket keeps a link back to the submission, so both records exist and stay connected.

Can I see how many are waiting? Yes — the dashboard shows a live support intake candidates count.

Do intake tickets get an SLA timer? Yes — once converted, they're ordinary tickets with a priority and an SLA target like any other.