Rules to Better Support - 5 Rules

Established projects typically include several layers of documentation, collectively known as a Knowledge Base (KB):

• FAQs (Frequently Asked Questions) - Quick questions and their answers
• Documentation (Docs) - In-depth guidance and references
• Q&A Articles - More detailed question/answer pairs for more specific use cases
• Roadmap - Outlines upcoming goals, features, and milestones to show the project’s direction and priorities

For example, one of the most useful feature on Microsoft website is their knowledge base.

When a problem arises, documentation should be your first port of call as it allows you to help yourself.

Video: Document your findings | Jeoffrey Fischer | CTF (2 min)

Why you need a Knowledge Base

If you’re constantly answering the same customer questions about your product, you’re wasting valuable time without a Knowledge Base/FAQ's. A well-organized KB empowers customers to find answers themselves, meaning they wouldn’t have to contact you in the first place.

Sure, some customers will always reach out directly. But with a KB in place, you can drastically reduce repetitive emails and focus on solving the truly unique problems.

How to respond to support emails

The basic rule is: don't send back the answer in your email - instead send back the link. More specifically:

1. If you can answer a support email then reply to the support email with the Knowledge Base link

   • To: the client
   • Cc: the developer and your manager

2. If you can't answer the question then reply to the support email:

   • To: the client and the developer
   • Cc: your manager
   • Ask the customer if they can get diagnostics to all green ticks.
   • Ask the developer to “Please action?"

See how by just giving them the URL, these emails encourages them to use your documentation in the future. You need to make sure the support staff are aware they should send these types of emails to customers.

What to include in your Knowledge Base

Things are running well when you have support staff adding new KB for:

• Known issues
• Hot tips
• Performance tips KBs also play a very important role in getting a product released. You will never get every feature done or bug fixed - we all know it

Focus on getting a version out. It is usually more important to have a version available than having no version at all. When you are looking down the Project Plan, decide on what the must-haves are. The other features and known bugs will have to remain outstanding. All the longer-term bugs should go into the KB. We also put in the feature requests that we plan on doing.

This way our customers know of our exciting features coming in future versions of our software.

Responding to feature suggestions

Where to host your Knowledge Base

You don't need to be Microsoft to build a KB. A Knowledge Base does not need to be complicated but it needs to be easily accessible.

❌ Don't use a simple knowledge base e.g. pdi-ssw.zendesk.com/hc/en-us.

✅ Make your knowledge easy to find by using a well-designed docs system like TinaDocs

Tips for maintaining a useful Knowledge Base

• Keep articles concise, accurate, and up to date
• Use searchable titles and keywords
• Link related KBs to improve discoverability
• Periodically review and retire outdated content

When offering support to customers using your product, think about whether this problem has occurred before or could happen again. If it has, there should be documentation available. This not only helps customers resolve their issues faster but also reduces the repetitive workload for the support team.

You should never have to answer the same question twice.When you get a new question e.g. "Can I have co-authoring in TinaCMS?" these are the steps you should follow:

1. Check for existing documentation.
2. If it doesn't exist, create the documentation.
3. Reply with a link to the documentation.

Every support message should include a link to the relevant documentation or, if applicable, to a Product Backlog Item (PBI).

Sometimes, you might get questions about bugs, upcoming features, or other things that are not documented. In this case,

After a while, you will build a great library of documentation that customers will use to self-serve their questions. This practice will also get you to read your documentation and improve it more often.

Exceptions to this rule:

• Do not write a documentation page if fixing the bug and releasing a new version solves the problem. In this case, create a PBI (or find an existing one) and reply with the link to it.
• Do not write a documentation page or PBI if the question/answer is irrelevant to your product, e.g., "Next.js - how do I deploy my app?" (This is not relevant to TinaCMS.)

🤖 AI Tip: Consider training a chatbot on your documentation to help answer common questions automatically. Learn more about implementing a chatbot

Just like a car, applications need servicing and tuning every now and then to stay in top condition. They might need alterations to deal with new business problems, or just tuning to increase efficiency.

So you’ve done 10 good Sprints and the software has been delivered (it's ready!) and the team is winding down. It will need maintenance.

Different clients need different levels of support. Offer your clients a few different support offerings.

1. Ongoing Maintenance

1 day per week (or whatever quantity suits), a developer will work on enhancements and bug fixing. This is useful because the client always knows when work will next be done.

2. Support Plan

For a small monthly cost, plus a multiple of the hourly rate, you can guarantee specific response and resolution times. This way your client will be guaranteed that they can get out of a fix quickly when needed.

Learn more on Support Plan

3. Time and Materials or Prepaid

A client can simply call for bug fixing or support as and when needed. However, unless it's a show stopper, this model can involve waiting for developer availability.

4. Fixed Price Warranty

For a fixed price project, a warranty commences after the Sprint Review. The warranty length is half the length of the Sprint and, during this period, any bugs reported will be fixed for free.

---

Warranty on a Fixed Price Contract

Once the Sprint Review is complete, the Product Owner has half the Sprint period again to report any bugs. The conditions are:

• The warranty period pauses when the client reports a bug that stops them testing further. The warranty period resumes when a new version is sent

  For example, the client may report a bug on a Wednesday morning on "Day 4" of the warranty. The bug is fixed on Friday and a new version is sent late in the afternoon. The warranty period resumes on Monday morning, at "Day 4". Therefore Wednesday through Friday was not included in the warranty

• During the warranty period, all feedback from clients should be moved to backlog unless they fall into the bug definition
• There is no warranty on a time & materials contract

If you need more than 20 minutes of work to perform a task, then it's not free, and you need to get approval for it.

Follow this template to reply:

Providing remote customer support is essential for IT administrators and support teams, especially when users are scattered across the globe. However, choosing the right tool can make or break the support experience.

Remote Desktop Support

For supporting end users' workstation machines remotely, consider the following tools in order of preference:

1. Microsoft Teams (Recommended)

• Microsoft Teams allows you to share screens and give remote control access securely
• It integrates seamlessly with the Microsoft ecosystem, making it ideal for organizations already using Microsoft 365

2. AnyDesk

• Lightweight and fast, AnyDesk is excellent for quick remote support sessions
• It supports cross-platform functionality and offers strong encryption for secure connections

3. Splashtop

• A cost-effective alternative to TeamViewer, Splashtop is easy to use and provides robust remote access features
• It is particularly useful for IT teams managing multiple devices

4. TeamViewer

• A popular choice for remote support, TeamViewer offers a wide range of features, including file transfer and multi-monitor support
• However, it can be expensive for commercial use

Remote Server Management

For managing server machines, the following tools are recommended:

1. Windows Remote Desktop (RDP)

• Built into Windows, RDP is a reliable choice for managing servers remotely
• It allows authenticated users to access a dedicated Windows login session without disrupting others

Remote Desktop works for workstations, but it's not recommended due to a security risk if Remote Support isn't disabled. Also, because of the End User License Agreement (EULA), only allows 1 user at a time, if you log in to client's Windows machine, the client will be logged off.

2. VNC-Based Tools

• Tools like TightVNC and UltraVNC are useful when RDP is not an option
• VNC tools share the same session as the logged-in user, making them suitable for collaborative troubleshooting

If you can't use TeamViewer, Teams, or Remote Desktop, you can try VNC. There are a number of VNC servers and clients available. VNC-based sessions typically behave as if you're physically using the computer. This means that it shares the same login session with the user who is currently logged on the machine. VNC software allows you to configure a specific username and password for remote access, which means that you don't have to share Windows usernames and passwords or create a temporary Windows user account. Some clients may also prefer this as they can sit in and watch what is happening.