Blog Inside Sneeze It · Inside the Hub · Part 4
We read 99 old requests and rebuilt every form to ask what we used to chase
Our request desk now asks for the deadline, the other locations and the files up front, files every request on the location it is about, and stays in sync with the Jira desks our team already works in. Here is what is live, and the one part we have not proven yet.
Most of the work an agency does for a multi-location brand starts as a request. New artwork for a grand opening. Pause the summer offer. A new manager needs access. Holiday hours on the Business Profile. The work itself is usually quick. The slow part is everything around it: the email back asking when it is due, which other locations it applies to, and where the files are.
We wanted to know how much of that back-and-forth was built into the way requests reached us. So before we redesigned the request desk on the Hub, we read 99 of our past help-desk requests from the previous six months and noted, for each one, what we had to go back and ask for.
What 99 requests told us
The same handful of questions showed up again and again, and none of them were hard. When is it due. Does it apply to other locations too. Where are the files. Is this related to something already in flight. Each one is a single sentence for the person asking and a whole round of waiting if it is missing, because the answer arrives on the next round of email.
So every form on the desk now asks for those things up front: a deadline, the other locations it applies to, a link to the files, and a related ticket. Nothing clever. We simply stopped making the first reply a question.
Source: Sneeze It request desk records; completed count from the live hub.sneeze.it homepage, October 10, 2026
Seventeen forms behind one button
Every location page has a "+ Ticket" button. The first thing it asks is what you need: web, creative, a campaign, an offer, a club opening, TV and streaming, billing, account access, a new location, join-page and promo changes, a report, or something else. That choice rewrites the rest of the form. The questions change, the instructions change, and so do the approval line and the cost line, so a request that will need sign-off says so before it is sent rather than after.
The request lives on the location it is about. A franchise's corporate team, a multi-unit owner and a single owner each see the requests for the locations they hold, moving from new, to in progress, to done. When we are waiting on the client, our "waiting on them" reads as "waiting on you" on their side, and a reply from them moves it back to in progress on its own. Nobody has to send a chaser to find out where something stands.
A request by email
An email to whoever you know at the agency. The first reply asks for the deadline. The second asks which locations. The files are in a different thread. Status is whatever the last email said.
A request on the location
A form chosen by request type, with the deadline, other locations, files and related ticket asked up front. The request sits on the location page with its status in the open, and a reply moves it forward without a chaser.
Who can read this ticket, and why
Requests in a franchise system are not all for everyone. Each ticket has one of three audience levels: everyone on the location, everyone except the outside agency, or named people only. The middle one exists for money and vendor matters, which is why an outside agency working on the same location never sees those conversations. The ticket page names everyone who can read it and why, so nobody has to guess. A ticket you cannot see does not appear as "forbidden." It simply is not there for you.
We stopped making the first reply a question.
We kept Jira, and made the Hub the front door
Our team already works in Jira help desks, and moving them would have cost the team time with no benefit to a client. So instead of a migration we built a two-way link. Every ticket opened in the Hub also exists in Jira on the right desk, with the right request type and department. Comments and status changes flow both ways. A request emailed straight to a Jira desk comes into the Hub and finds its client by sender, contact address, club name or club id. If it cannot tell, the request waits in a "Which client is this?" queue for a person to pick, and the queue can remember the sender's domain for next time.
- 1Location page"+ Ticket" on the location the request is about
- 2FormQuestions, approval and cost lines set by the request type
- 3Hub ticketAudience set, owner assigned by department
- 4Jira deskSame ticket, same status, comments both ways
- 5DoneVisible to the client on their location
No AI decides where a request goes. Routing is plain rules, so the same request always lands the same way. Every department has a default owner, and anything without an owner for more than a day is listed for our staff. No ticket fails silently either: if one does not reach Jira, it is retried every 10 minutes, and the team gets one Slack alert per distinct problem rather than a flood.
What is live, and what is not proven yet
We would rather tell you exactly where this stands than round it up.
The desk is one part of the location record we describe in We rebuilt our portal around the location. The Slack side of it, where our team files a request without leaving the conversation, is in One in Slack updates the record.
