hey!! can you pull a quick list for the Austin event? need it today if possible, should be easy
which accounts? customers or prospects? who's sending, and from where?
oh just whoever's near Austin. and can it go out tomorrow am?
Objective: Invite open-pipeline prospects within 50 mi of Austin to the Nov 19 dinner.
Scope: HubSpot active list, contacts with open deals, 50-mile radius, title Director+.
Out of scope: Customers, the email build, and the send.
Acceptance: Given the list is built, when Dana opens it, then it shows 80–150 contacts with zero customers and zero unsubscribes.
Ready: objective ✓ AC ✓ approver ✓ size ✓
Most intake systems fail because the requester is asked to write the ticket and the builder is asked to guess.
Requesters write wishes, not tickets. Ops re-interviews them in comments, and the real scope shows up halfway through the build.
"Anyone have a solid template for incoming ticket requests? Acceptance criteria, scope, etc?"
Work starts without an outcome, acceptance criteria or a named approver. "Done" gets negotiated after the work is shipped.
Every request is urgent. Seniority and proximity decide the order, and the real P1 waits behind a VP's "quick ask."
Every request interrupts someone building. Research puts the cost at about 23 minutes to fully get back into an interrupted task.
Work in progress grows, so cycle time grows with it. Nobody can give a date, and requesters start DMing to jump the line.
"Rebuild the nurture" is filed like "add a field." A week of work becomes a ticket nobody can finish or close.
Track acknowledgment time, delivery time, SLA hit rate and queue size. Promise only what those numbers support.
| Metric | Weak | Acceptable | Strong | Source |
|---|---|---|---|---|
| Acknowledge a P1 | Over 1 business day | Same day | Within 1 business hour; status in 4 hours | Basedash, 2025 |
| Deliver a P2 | Over 2 weeks | Within 10 business days | Within 5 business days | Basedash, 2025 |
| SLA hit rate, P1 and P2 | Under 75% | 75–90% | Over 90% | Basedash, 2025 |
| Open queue size | Uncapped, 100+ | 50–100 | 30–50 active; rest scheduled or declined | Basedash, 2025 |
| Unplanned buffer each week | 0% (fully booked) | 15–25% | 30–40% held for P1s to start | Basedash, 2025 |
| Items in progress per person | Over 5 | 4–5 | 3–5 as a starting WIP limit | Calade (Little's Law), 2025 |
| Required fields on the form | Everything required | Mostly required | Only fields that route, trigger or report (~9 for marketing) | Cirface, 2025 |
Sources: Basedash intake and triage framework (2025); Calade on Little's Law and WIP limits (2025); Cirface intake form best practices (2025). Interruption cost: Gloria Mark, UC Irvine (2008), about 23 minutes 15 seconds to fully resume an interrupted task; the APA (2006) puts task-switching losses at up to 40% of productive time.
One front door, two artifacts, one ready gate, and a cadence that protects build time.
One form for every request. DMs, emails and hallway asks get a link back.
Requests in DMs are invisible work in progress with no SLA and no history.
Asana Form, a Jira Service Management portal, or a HubSpot form that creates a ticket.
Requesters answer outcome questions, not build questions.
Requesters are good at describing a problem and bad at writing specs. Ask what they know.
Eight required fields, one branch per request type, one optional catch-all.
Ops writes the ticket from the intake answers in a fixed format.
The person who builds it should define it. That's where rework gets prevented.
Seven fields, readable in under 60 seconds.
Observable checks in Given / When / Then form.
"Works correctly" can't be verified, so it can't be closed.
Written before work starts, by whoever will verify it.
Nothing moves to Sprint Ready without objective, acceptance criteria, approver and size.
It stops the comment ping-pong that eats more time than the build.
A rule or validator that bounces incomplete tickets back.
A fixed P1–P4 scale and S–XL sizing, set at triage.
Requesters will all choose High. Take their date and their impact, then decide.
Priority from impact and date. Size in builder hours.
Time to acknowledge and time to deliver, by priority, in business hours.
A published SLA ends "where's my thing?" DMs. A missed one tells you capacity is wrong.
Native SLA features where they exist, rules where they don't.
priority = P1 1h, P2 8h, P3 16h) on a business-hours calendar.Two 30-minute triage sessions a week. One person owns P1s and small items each week.
Batching protects build time. The rotation keeps response fast without everyone being interrupted.
Recurring triage meeting plus an "On-call" field or assignee rule.
3–5 items in progress per person, and an estimate on every ticket before it's committed.
Little's Law: cycle time equals work in progress divided by throughput. Less WIP means faster delivery with the same team.
Column limits on the board and a points or hours field.
Done means shipped, verified by the requester, documented and announced.
Closing without confirmation creates reopened tickets and erodes trust in the queue.
An In Review step, an auto-close rule, and a monthly queue report.
The format matters less than these rules. Teams that skip them are back in DMs within a month.
Each one feels helpful to the requester and costs the ops team a day a week.
Work arrives where nobody else can see it.
Cost: invisible WIP, no SLA, duplicate builds.Requesters rush or abandon the form.
Cost: junk submissions and a form people route around.Nobody can prove it's done.
Cost: rework and arguments at handoff.Everything arrives as P1.
Cost: seniority wins and real P1s wait.Every new request interrupts someone building.
Cost: about 23 minutes to refocus after each interruption.Everything is started; little is finished.
Cost: 32 items at 1.25 a day is a 25.6-day wait.Ops marks it done; the requester disagrees.
Cost: reopened tickets and trust in the queue drops.A full service desk before there's a working process.
Cost: low adoption; a form and a board would have worked.Little's Law does the math: cycle time is work in progress divided by throughput.
Backlog shrinks by 4 tickets a week at this pace.
Triaging as requests arrive costs about 7.7 focus hours a week.
Interruption cost uses 23 minutes per request (Gloria Mark, 2008). Batching triage into two sessions removes most of it.
Paste it into Asana, Jira, Notion or a HubSpot ticket description and adjust the request types to yours.
=== PART 1: INTAKE FORM (requester fills, about 3 minutes) ===
1. Request type* [single-select] Campaign build | List or segment | Workflow or automation |
Data fix | Report or dashboard | New field or property | Integration or tool
2. Outcome you want* [text] The result, not the thing to build. "More demo bookings from webinar attendees."
3. What happens today?* [text] What's broken or missing right now.
4. Who's affected?* [single-select] Just me | My team | Sales | Whole company | Customers
How many records / people? [number]
5. Needed by* [date]
What drives that date?* [text] Launch, event, board meeting, contract...
6. What breaks if we don't do this?* [text]
7. Link to the asset* [url] Campaign, list, workflow, record or report
8. Approver* [person] Who signs off that it's right
9. Anything else? [text, optional]
BRANCH (Campaign build): audience, channels, launch date, assets ready Y/N
BRANCH (Report): question it answers, decision it changes, audience
=== PART 2: TICKET (ops writes at triage, readable in 60 seconds) ===
Title: [Type] Outcome in 8 words
Objective: One sentence. The outcome.
Context: Why now. What's upstream. Link to intake.
Scope: - bullet
- bullet
Out of scope: - what we are NOT doing
Acceptance criteria (Given / When / Then):
AC1 Given ..., when ..., then ...
AC2 Given ..., when ..., then ...
Dependencies: What must be true first, and who owns it
Priority: P1 / P2 / P3 / P4 (set by ops)
Size: S (<30 min) / M (half day) / L (1-3 days) / XL (>1 week = project)
Definition of done: shipped + verified by approver against AC + documented + announced
=== DEFINITION OF READY (all four before Sprint Ready) ===
[ ] Objective [ ] Acceptance criteria [ ] Named approver [ ] Size
=== PRIORITY x SIZE ACTION MATRIX ===
S M L XL
P1 Do now Do today Do today Escalate
P2 Do today Schedule Schedule Plan as project
P3 Self-serve Schedule Plan Defer with date
P4 Self-serve Defer Defer Decline
=== SLAs (business hours) ===
P1 acknowledge 1 h, status update 4 h, deliver same or next day
P2 acknowledge same day, deliver within 5 business days
P3 acknowledge 2 days, scheduled into next sprint
P4 acknowledge 1 week, may be declined or folded into a project
=== BOARD SECTIONS ===
New -> Triage -> Needs info -> Sprint Ready -> In Progress (WIP 3-5 per person) -> In Review -> Done
Rules: Needs info > 3 business days = flag at triage. In Review > 3 business days with no reply = auto-close.
Direct answers to the questions that come up in the first week.
Yes, but use two: an intake form the requester fills in business terms, and a ticket ops writes at triage with objective, scope, out of scope, acceptance criteria, dependencies and definition of done. Both are in the template above.
Whoever will verify the work, before the build starts. In practice ops drafts them at triage and the approver confirms them. If the requester can't agree on how "done" will be checked, the ticket isn't ready.
Asana if marketing already plans there: forms, rules and branching cover most of it. Jira Service Management if you share a queue with IT or engineering and need real SLA clocks. HubSpot tickets if MOps lives in HubSpot and wants requests tied to records, keeping in mind the seat costs.
Reply with the form link every time, politely. If it's truly under 30 minutes and the on-call owner has room, they can log it after doing it so it still counts. Skipping the log is how invisible work comes back.
Sprints if most work is medium or large and stakeholders want a weekly plan. Kanban with WIP limits if most work is small and arrives unpredictably. Many teams run both: a Kanban lane for small and P1 work, sprints for planned work.
Remove the priority field from the form. Ask for the date, what drives it and what breaks without it. Ops sets priority at triage on a published scale, and the matrix makes the trade-offs visible.
Every JayOh task follows one SOP: readable in under 60 seconds, with a clear objective, defined scope and testable acceptance criteria. Asana is the source of truth and one-week sprints are the delivery engine.
We build the intake form, branches and ticket template in your Asana, Jira or HubSpot, and set the board sections and rules.
We run triage with you, groom the existing backlog into keep, defer and close, and point everything that stays.
A consultant owns triage and priorities. Developers ship HubSpot and Salesforce work in weekly sprints against your SLAs.
We engineer growth systems. JayOh builds the RevOps architecture, GTM execution and data infrastructure that turn messy revenue operations into predictable pipeline for B2B SaaS and PE-backed teams.
