All posts

Not everything is a ticket

November 22, 2022 |

Most customer support systems have a great functionality called Tickets. Tickets are the general term used in customer support software for managing communication between customers and the company.  It’s a pretty decent way of managing the enquiries from the customers. And, most businesses are accustomed to the way ticketing works. When choosing a supporting tool for handling enquiries, it’s often important to look for more than a ticketing feature. Things get harder when a business or startup starts thinking of every query as a ticket. People using your product often expect a reply from a person or team in the company in an interactive way.

Choosing your swiss army knife

For budding entrepreneurs and small/medium size businesses, it’s common for an employee to wear more than one hat. They could be involved in building the system, managing support & handling customer enquiries. It’s literally hard to reply to a sales pitch and product support. Would you? If you consider a sale or a new customer as a ticket, there is a very high chance of losing a potential buyer. Tickets are designed to suit very well for supporting product queries. A plain old inbox style of email reply is what is used for responding to a new client. Take indie developers as an example. There could be 2-3 team members handling all the work from building/marketing/sales. Switching contexts with different applications could be tedious. HelloKea could rescue you from that.

Tickets & Classic inbox layouts for email accounts

We are building an inbox layout that suits multiple email accounts. The key thing about the design is the behaviour of the email accounts. When you select an email account to answer sales or other queries which don’t fall under the ticketing genre, the UI behaves automatically to a classic inbox design that you are familiar with.

Scribbling UI design

As you can see in the above image, a classic inbox style is shown on page one and the ticketing style is shown on page 2. You could see the list of email accounts created. The accounts shown are based on the permission of the team members. The User Interface (UI) changes dynamically based on the type of account selected. If the selected account is a team account, the ticketing option UI is automatically shown. Based on the selected permission, one can provide perform certain operations. Eg: Customer support emails could be shared among the team to answer their requests.

On the other hand, email accounts like  [email protected] or [email protected] are generally used for querying about the products or the company. For these accounts, a classic email style would give us most of the functionality of an email client. Though we haven’t decided whether these accounts could be converted to a team account in the future, we are brainstorming.

Final thoughts

In our first introduction post, I mentioned the support for social networks and scheduling posts. I am investing most of the time in whether to integrate social network communication in the same UI. But for now, we have finalized releasing the first version with full support for email accounts and shared inbox functionality. Also, with the diagram, you could see that we are in the early stages of deciding on our UX. Things can change over a period of time. This post is to share our journey on product updates and development.