Providing support is expensive and does not scale. Furthermore, a high number of support requests is indicative of problems with the product itself or a lack of accessible and helpful documentation, which must be addressed.

The best kind of support is the kind that is never needed

In order to reduce the amount of support requests, we should strive to design the best possible product, rigorously test the product to ensure quality, and back the product with comprehensive documentation that empowers people to help themselves.

The table below shows prioritized courses of action that will help us minimize the number of support requests, improve the user experience, minimize long-term cost, and be the most scalable.

Course of Action Upfront Cost Ongoing Cost Scalable?
First, design the best possible product High None Yes
Second, rigorously test the product to ensure quality High None Yes
Third, back the product with comprehensive documentation Medium None Yes
Fourth, as a last resort, provide support None Medium No

Providing support

Whenever we do need to provide support, here are some guidelines in how to do so.

Gather information

Before responding to someone, gather as much information about them ahead of time so that the interaction plays out efficiently. You should always check past conversation history to see if we have already communicated with the person or if we are currently in conversation with them on another channel. Places you might check include Intercom, the forum, social media, GitHub, and email. It may also be worth asking other team members if they have been in private communications with the person.

Additionally, you may consider looking up their order history. Are they a customer? If so, did they get a full kit from us? What version? Have they potentially upgraded/modded their bot?

Watch out for inconclusive information

Keep in mind that an attempt to look up order details or other information may not be conclusive. For example, you may look up to see if a teacher has placed an order with us, but if the FarmBot they are using was purchased by the school principal, then the search results will not be conclusive.

Don’t assume anything

When interacting with someone, do not assume anything. Assuming things can lead to misunderstanding, frustration, and a poor and inefficient support experience for both sides. You may also accidentally offend someone or become offended.

Don’t assume prior knowledge

  • Don’t assume the person has read (and comprehended) the docs or other available information.
  • Don’t assume they know anything about or have experience with software, hardware, growing stuff, etc.

Don’t assume anything about the situation

  • Don’t assume the person is a customer. Likewise, don’t assume that they are not a customer either (see above).
  • Don’t assume they already tried to help themselves by searching the docs, shop, forum, help center, etc.
  • Don’t assume they have their bot up and running or installed in any particular way (ie: on a raised bed).
  • Don’t assume they are using my.farm.bot or have the latest version of FarmBot OS installed.
  • Don’t assume they have access to our resources or a reliable internet connection. For example, a person in China may not be able to view our YouTube videos.
  • Don’t assume they have a stock kit; they may have modded it with their own parts or those purchased from 3rd parties.

Don’t assume traits about the person

  • Don’t assume the person’s gender identity when communicating with them or when communicating about them with the team. Avoid gendered pronouns such as “hers” or “he”; instead use gender neutral pronouns such as “they”, “theirs”, or “the person’s”.
  • Don’t assume English is a primary language for the person.
  • Don’t assume the person is fully abled; they may be a wheelchair user, for example.
  • Don’t assume they have certain growing preferences (organic, for example).

Identifying and describing someone

Many support cases will require a team effort where we must internally refer to the person needing support. For cases that do not require other team members to know who exactly is being discussed, generic terms such as “user” or “person” should suffice. For cases that do require other team members to know who exactly is being discussed, use a name/identifier that the person needing support has chosen for themselves, such as an email address, a username, a first/last name, etc.

Oftentimes a generic term or a precise name/identifier does not provide enough context about the situation, or is not enough to jog a team member’s memory about a past issue. In such cases, it is usually better to describe the person’s situation, rather than their traits. For example, “the person in Japan” precisely describes geographic location and nothing more. It is presumably based on some hard evidence that we have such as a photo’s geotag. Meanwhile, “the Japanese person” possibly describes nationality, a spoken language, and/or geographic location. It may also be based on an assumption from the way someone looks - an assumption that may not be true, or held by other team members.

Describing a person’s traits may help in identifying them, but will usually have no impact on our ability to help them. It should be used as little as possible.

Exceptions to the rule

Contrary to what was just stated above, some situations will greatly benefit from describing a person’s traits. For example, a person’s specific type of disability may be crucial information for developing an accessibility feature.

However, extra caution and care should be exercised when describing a person’s traits. Only do so when it seems necessary and when the description is based on solid evidence - such as things the person has said about themselves. Unnecessary or inconsiderate trait descriptions can offend someone, and stoke our tendency to stereotype and make incorrect assumptions or judgements.