Embarking on Market Research.

[cjoulain]

Following up on request in #27.

We'd like to do market-research to:

• define who Support's competitors would be
• discover their paint points and how this product solves (or avoids) them
• discover what competitors do well and how we can emulate that (or similar behavior) in our use case

I'm more familiar with Zendesk and I think that CMS is ideal for large-scale Customer Support services that require strict SLAs and that would make use of their various customizations. But, if an org is small and technical support oriented, those customizations are extraneous. I also didn't like the 10MB attachment limit since gifs that show what the user is experiencing is critical to technical support.

One strength of Zendesk would be in allowing all members of a team to have the same ticket access (helpful for reading context from other tickets and to re-assign tickets when colleagues are not available).

@zspencer @maximegalon5 Let me know if this description needs to be revised.

[zspencer]

Hey CJ!

I think this is a great issue! I think the way I'm framing the value proposition for the Support/WGYBT product is that it's a well-integrated suite of customer development and account management tools.

At present, I'm visualizing this repository as helping small businesses accomplish the following jobs-to-be-done:

1. Capture - Collect inbound requests for information, mailing list subscriptions, etc
2. Onboard - This may be more high-touch (using the Scheduling feature), or low-touch (buy a subscription or one-time-purchase for a client(s) product right from their static site)
3. Maintain - This is where the existing "inbox" feature comes into play, the most active inbox is MomentPark and Cohere, who see several messages a day (mostly spam, unfortunately; but that's better than giving out our email and getting spammed that way).
4. Retain/Disengage - How do you ramp down customers in a way that's respectful of their time and expertise?

Building all of that at once would be impossible, so I'm thinking of the two to three starting features:

1. Inboxing - I.e. Messages come in (support or even inquiries) and folks manage the inbox collectively.
2. Scheduling - I.e. We can give out links to folks to
3. Selling - I.e. Someone can toss in a Stripe key and a product SKU and get a landing page that starts taking $$$ from visitors.

From a competitor perspective, I think we want to consider entities that are targeting the above Jobs-To-Be-Done and offering solutions that are in the Inboxing/Scheduling/Selling space.

For example, a Selling competitor would be MoonClerk or GumRoad. A Scheduling Competitor would be Calendly. An Inboxing competitor may be HelpScout or ZenDesk.

I think @maximegalon5 has some insights into what both the inputs into doing Market Research look like and the output we would expect the Market Research to produce; as that's pretty far outside of my wheelhouse.

[zspencer]

@cjoulain - Hey CJ! I took the time to sprout a bit more structures for you to play with regarding this kind of work; and updated the README so that it's discoverable by contributors.

See https://drive.google.com/drive/folders/1S_bH6MxGGXccoD0qwvAnxI5XFOzyOuz5 for the documents and #37.

I'm curious if you and @user512 feel comfortable cribbing off of the work that the folks are doing for Convene as a kind of "monkey-see/monkey-do" approach as we computery-nerds learn how to be better at product research, design and marketing?

[zspencer]

Hey @cjoulain! I haven't heard back from you about whether the comments I left are useful or not, or if there is more you need for this issue to feel complete.

Would you be willing to either A) ask more clarifying questions or B) add some check-boxes to the issue body with small, specific things you want/need so contributors can take on that work or C) close the issue?

You can also feel free to ignore this message and I'll close the ticket out in a couple weeks when I notice it again :).

[cjoulain]

These comments are helpful, as are the documents you've created about Support feature and personas. I've added a small persona profile and will close this issue by end of week, if I don't have any more clarification questions.

[cjoulain]

@zspencer Thanks for bumping this! Looked at the test instance you set up for me and had a few more questions. I sent myself a message using the public-facing inbox URL for CJ Trial.

As an owner who has an inbox, do I also have access to a UI interface where I can log in and see emails? Or is the service intended for me (an owner) to send a message through email-only (no UI login)?

I see my test message also sent over the client's email. Is the expected behavior for an owner that I manually enter an email though a different email client and respond to the message there? Is there a character limit to the message a client sends in the public-facing inbox?

Do you know where no-reply@wegotyourback.today goes to? I just wonder if someone continually replies to that address if it could be spammed or impact the owner's ability to get emails.

(I'm not sure if I'm using terminology correctly but by owner I mean person who manages the customized inbox and client is the user who is sending a message to the owner.)

[zspencer]

Re: UI - Not at present; the current ux goal is to explore interop with peoples existing work-flows; as opposed to building out a full "app" interface. This may change; but we believe by focusing on the core interaction experience using open standards and protocols (i.e. Email). I can imagine augmenting that at a future time with a :real-ui:

Re: Where does the owner reply - The expectation is the owner replies through their mail client. Ideally, this would be sent back to the support app; so that the owners email address is not exposed.

Re: Character limit - Hmm, good question! There is not an explicit one but there could be one hiding at the database level!

Re: no-reply - no-reply@wegotyourback.today is a dead drop; and the expectation is that the only person who sees that email address is the owner of the support inbox. I would hope that we would replace that with a unique conversation level email address; and ditch no-reply entirely.

Re: terminology - the terminology is yet to be defined; and ultimately we'll want to land on terminology that resonates with the people paying for and using Support.

[cjoulain]

Thanks, @zspencer. I think my initial questions have been answered.

Would it be OK for me to do informational interviews with folks who fit into our current personas? My sense is that this sort of tool might especially appeal to smaller companies with no (or few) Support staff rather than larger Customer Experience teams but I'd like data to back that up. Would that require closing this ticket and starting up a new ticket?

What's required in order to pick up a test-related ticket? Would it just be checking in with maintainers to gauge priority? Or, as long as it doesn't have an assignee, it's OK to pick up?

[zspencer]

Re: Informational interviews - Of course! If you'd like support on that, reach out to @maximegalon5! And I agree with you re: target market.

Re: Picking up a ticket - Pick up the work you think is most valuable, do as much of it as you feel comfortable in a single work session; then submit a patch or leave an update with what you did. We want to make space for people to take their own initiative, which means we're granting unlimited enthusiastic consent for contributors to submit work; and it's up to the maintainers to decide whether it's worth merging or not. I believe @maximegalon5 and I are working from the assumption that this project board is intended to communicate state of work: https://github.com/orgs/zinc-collective/projects/2

One thing that's kind of different about how the size and shape of work at ZC is shaping up is that our tickets are going to be big; and they're going to be so big that any one person is unlikely to be able to complete them in a single work session. This means that so long as we're always submitting patches or updates at the end of a work session in the ticket we're working on, it'll be easy for people to pick up where we left off, or find small places to support each other.

That said, it's going to feel a lot different from most companies; where the expectation is that you have "your" tickets and then you do them. Hopefully we'll be able to make it feel safe and fun and collaborative like a jazz band or improv group!

[maximegalon5]

Yes, the current state of work is the project board referenced above. @cjoulain let me know how I can help wrt Informational Interviews. We've been able to set up a play book of sorts with Convene, and I'd be happy to either point you to the relevant templates or walk you through them over a video-chat, if you prefer.

[cjoulain]

Thank you for the context, @zspencer and @maximegalon5.

@maximegalon5 would be interested in seeing the Convene playbook as a template! Should I go to the Convene repo or is that info stored elsewhere?

In terms of timelines, this week isn't great but I could start commenting on possible Support playbooks and chatting about info interviews the week of July 20.

[maximegalon5]

@cjoulain Convene's Research Folder <- I'd be happy to spend 15-30 mins broadly describing the approach if you think that'll be valuable. If so, grab a slot here?

[cjoulain]

Thanks, @maximegalon5. I booked a meeting and will chat with you soon!

I'll close this issue for now, as I feel all questions have been answered. And will re-open (or create another issue) if there are lingering questions in the future.