Requests: asking us for something
What belongs here rather than with your operator, how to write a request that gets built quickly, and what happens after you send one.
Requests is the one screen that reaches us rather than your operator. It is how you ask Gary Club to build, change or look at something.
What belongs here
| Ask here | Ask your operator instead |
|---|---|
| A capability that does not exist yet | Anything it can already do |
| A connection to a tool not on the list | Connecting a tool that is on the list |
| Something is broken or looks wrong | What did you do yesterday |
| Adding or removing a team member | What are you allowed to do |
| Moving a job up the ladder, if you are not an owner | Teaching it something |
The promise on your onboarding call was that asking for something built is always one click away. This is that click. For two days this item was rendered off the right edge of the header where nobody could reach it, which rather defeated the point, so if you ever cannot find it, tell us.
Writing a request that gets built quickly
Say the outcome you want, not the feature you imagined
I want the transcript to reach it within five minutes of the call ending lets us pick the right mechanism. Add a Zapier button may point at the wrong one.
Say who it is for and how often
Something one person does daily and something the whole team does monthly are different builds.
Include a real example
One actual case beats a general description. Name the customer, the call, the tool.
Say what you do today
The manual process you are replacing tells us what good looks like, and it is usually the fastest way for us to understand the request.
What happens next
We read every one. Small things are often done the same day; larger ones come back with a scope and a question or two. If something is a bad idea we will say so and explain why, rather than building it quietly and letting you discover the problem.
If something is broken, say what you expected and what happened instead, and include the time it happened. That single detail usually turns a day of investigation into ten minutes, because everything on your box is timestamped.
Not a formal one. In practice, broken things are looked at immediately and new work is scoped within a few days.
Yes. Anyone who can sign in can raise one.
Either reaches us. Requests keeps it attached to your account, which means the next person to look does not have to reconstruct the context from a thread.
Two requests, one good and one that will come back with questions
| This will get built quickly | This will come back with questions |
|---|---|
| When a call ends, I want the transcript with our operator inside five minutes so it can write the follow up. Today Franzi copies it into a doc and writes the email herself, usually the next morning. Example: yesterday's call with John Whitfield, ended 11:47. | Can you add Zapier? |
| Says the outcome, who does it today, how often, and gives a real case | Names a tool, which may or may not be the right mechanism for the actual problem |
Describe the job you want done rather than the feature you pictured. You know your business better than we do; we know which of our mechanisms fits, and there are usually three and they are not equally good.
Reporting something broken
Four things turn a day of investigation into ten minutes, because everything on your box is timestamped.
What you expected
In one sentence.
What happened instead
Including the exact wording if there was a message.
When
The time, roughly, and the timezone you are in.
Who or what it involved
The customer, the call, the automation. A name lets us find the record.
If something is actively going wrong, say so plainly at the top rather than burying it in the third paragraph. We read every request, but the ones that say this is live and wrong get looked at first.
What happens after you send one
| Kind | Typical response |
|---|---|
| Something broken | Looked at immediately. |
| A small change | Often the same day. |
| A new capability | Comes back within a few days with a scope and usually a question or two. |
| Something we think is a bad idea | We say so and explain why, rather than building it quietly and letting you find the problem. |
If we build something for you that is generally useful, it usually ships to every operator rather than only yours. That is not us taking your idea: it is why the product keeps getting better for everyone without anyone paying twice.
What not to send here
Anything your operator can already answer. What did you do yesterday, what are you allowed to do, and what do you know about this customer are all faster in Talk, and the answer is more specific than we could give you.
Was this page helpful?