Cómo escribir un artículo perfecto para una base de conocimientos

Reading time: 7 minutes

Written by

Does your company need a knowledge base? Yes.

Is this the right time to set up a knowledge base? Yes, it always is.

Does your knowledge base have the ability to give your customers everything they need? Maybe not.

Can you do something about it? Absolutely.

A knowledge base is the only thing that can be immediately useful for both support agents and clients alike.

No matter how big or small your company, no matter what industry you are in, you can not go wrong with a knowledge base (see Quizup or Google). After all, searching for answers online is automatic for most of your customers.

But what can go wrong is your site. According to a Forrester report, self-service has a better satisfaction rating than interaction with a virtual agent, but clients often feel that “content does not meet customer expectations.”

There are no pre-defined rules for writing a perfect engagement article. He is wrong, he learns and repeats himself. Here at Freshdesk, we have written hundreds of articles for our base and is used by over 40,000 customers. We have experimented a little with our articles, and we constantly try to improve them.

Here’s a look at what has worked for us (and a bit of what not):

Frequently Asked Questions

-Add users

-Understand your users weaknesses

-Write to the average user

-It serves different types of students

-Deleting the bias

-Tips for writing articles

-Gather articles

-Vincular articles

Where to start?

When creating your knowledge base, for the first time, you will have a lot of writing topics. One of the following (or perhaps both) techniques should help you get started with your knowledge base:

Answer Frequently Asked Questions

Without much thought, what do most customers ask?

If you are not sure, check your support tickets from last month (or weeks, if your volume is huge). If that does not give you too much information, find out what your customers are looking for by looking at the search terms in Google Analytics.

Tip: Connect the support portal to Google Analytics and get ideas and information.

Make a list and start adding articles to your base by answering these questions.

Address users

List the top 10 activities your customers should be doing to see the value of your product. Should you invite your team to use it? Should they import data from their previous system?

Write supporting articles for all these steps and organize them based on functionality so that customers who visit your support portal can find them easily.

Although answers to frequently asked questions will help your agents immediately, writing articles that address new users will help you in the long run. We started by writing basic FAQs and now we write articles for each new feature that launches and link it to the main product post.


Before writing an article:

Most of the work to write an article from the knowledge base is done before you write it. You have to make sure you understand what you are writing, find weak points and put a structure around your entire article.


Understand weaknesses (of users)

Before writing a tutorial, try the whole procedure for yourself (and with more people if you can) step by step. Write down where it got stuck, what step was confusing, what you expected and any other mistakes that might come along the way.

If you have a lot of tickets on your help desk, you can also review them and find out where users have a problem. In this way, anticipate user weaknesses and questions, and eliminate them in the article.

A great example of anticipating the questions, on the Udemy blog.
A great example of anticipating the questions, on the Udemy blog.

Write for the average user

You are not writing your knowledge base articles for a single type of customer. What is easy for an advanced user can be too complicated for an average user. If you feel you need to give more explanation to a newbie (or more information an advanced user wants), break it down into multiple articles and link them to the original. In this way, the article written for the average user does not have too much information.

For example, when explaining the social card in Freshdesk, instead of telling users “You can search Twitter using the social label”, we wrote a separate article on how to search Twitter (which an advanced user would not need) and link it to the original.

Attends to different types of students

Different people learn differently. Some like to learn by using pictures and videos, while some like to try things out step by step. That does not mean you can soak the article with screenshots. Calculate the minimum amount of catches that will explain the process and whether that particular article deserves a video.

Of course, if you have the resources, it makes sense to add a video at the end of each article.

Take, for example, the Wistia FAQ section. Although they are a video hosting company, they do not fill the entire page with videos. They found that people have difficulty understanding the idea of bandwidth and have created an explanation video for that.

(Note: We experimented with GIF presentations and files as a medium, but we found that people did not wait to see the different steps in the animation)

Remove bias writer

You should not let the exposure you have to the customer’s problems affect the item in a negative way. If you actively support customers, you are likely to remember all the problems customers have with the feature they are writing about. And if you’re a tech-writer, you’re likely to remember the step-by-step demonstration you received from the product manager.

Your article about a feature should not be a detailed explanation of the user interface or a mini FAQ.

It should be a mixture of both so that users can understand everything when reading it and find solutions to specific problems.


As you write the article

Now that you have figured out what you should be writing, and what messages you should send, it is time to actually write the articles. Here, you should make sure that you keep some basics and follow your plans.


1) Speaking as users . Do not use big words or technical jargon in your articles. Find out how customers call the function you are describing (using GA search terms or by reading entries) and using those words in the article and its title.

2) Be simple . Your articles should be easy to explore and understandable in a single read. The title and subtitles should cover what you are trying to say. If you are interested in making things look good, personalize the design, not the content (follow the Amazon example).


3) Feature trumps benefit s. When writing for the support portal, make sure you do not use marketing language. A solution article is written to help, not to convince. So unlike marketing content, they emphasize the features and not the benefits.

4) Treat each article as a mini-boarding process . Start by explaining the function in simple words. Then use an example to show what the customer can do once you follow their instructions. In this way, even if the installation process is complex, users will adhere to it until the end.

5) The cartoons and graphics are best friends . Clearly the format of solution articles is extremely important. Differentiate your titles and subtitles. Divide different sections using a horizontal line. Bold action elements in each step.

6) Always indicate the prerequisites . Again, this is not a marketing document. Do not make it difficult for users to find what a feature can not do. If your application does not run in IE, say so. If this function is only in the highest plan, say so.

7) Nothing is “too obvious” . Do not leave out even the smallest of details assuming it is obvious. Use a table or create commented pictures when you want to explain many little things without making the article too long.

8) Do not sell . The sale in the support article is like selling on a support ticket (also bad).


After writing the article:

You have finally finished writing your article. All the work was done and you can move on to the next and forget about it, right? Do not.

You have not finished writing a supporting article once it has been published. You need to make sure it’s useful, up to date and organized.


Link articles

Check the article you just wrote once more and find out if you can link any other solution article. Then check other related articles and provide links to the new article.

For example, if your new article is about plans and billing, you can link it to information about payment options. This helps readers navigate easily (even if they land there by mistake) and increases the chances of finding the article in the search engines.

Actively listen to feedback and improve

A few days after your article was published, you can find out if you are really helping your agents and clients. Have you reduced the number of questions about this feature? Are there other agents who use this article to support their responses? But because?

The Freshdesk knowledge base has a small survey at the end of each article. And each negative vote is converted into entries in the help desk in which the author is added as an observer. In this way, the author can quickly update the article based on the votes.



An article from the knowledge base can not be perfect from the beginning. It improves over time by updating it based on the feedback it receives from readers and support agents.


A perfect article differs from one company to another. You can follow this article to get the first articles … but once your base is shot, you can experiment and try to figure out what fits your customer base. Even if you can not see the effects of the article on your users immediately, it will be useful to your agents from the first day. It’s also a great way for new agents to catch up with your product / service.

Subscribe for blog updates

Thank you for subscribing! Please check your e-mail to confirm.