Tickets and Feature Requests: dialogue as part of the product

There are two opposite experiences, when something in a piece of software stops working. The first: you open a ticket, receive an automated email, then silence, then — after five days — a vague reply asking you to "restart your browser". The second: you open a ticket, get a human answer within a couple of days, the problem is taken seriously, and sometimes actually solved. The difference between the two experiences isn't technical: it's a matter of culture.

Narraya is a young project, small, built by few hands. We can't afford the first experience. And honestly, we don't want to.

The Ticket channel, for when something goes wrong

Tickets, in Narraya, are for two things: reporting a bug (something not working as it should) and asking for help (something you don't understand or can't do). You open them from a button available in almost every page of the application, under the "Help" menu. The reply arrives via email, with the internal ticket log always accessible from your account.

No chatbot trained to bounce you around. No FAQs to scroll through before reaching the form. The first contact is human — at least as long as the project's size allows, and we're working to make sure it allows for it as long as possible.

How to open a ticket that gets a useful reply

1. Describe what you were doing.

   "I was writing a chapter" isn't enough. "I was exporting chapter three to DOCX" is better. One sentence about the context.

2. Tell us what happened.

   The observed behavior: exact error message, step that didn't happen, feature responding strangely. What you saw, not what you inferred.

3. Say what you expected instead.

   Simply: "I expected the DOCX file to download, I got an error page". It helps us understand whether it's a bug or a misunderstanding.

4. If you can, attach a screenshot.

   Worth a thousand words. The attachment button is in the ticket form. Files up to 10 MB.

5. Check your email.

   The reply arrives there, and may ask you for further details. Reply from the same email: the thread stays tidy.

Feature Requests: the authors' voice

There's another channel, distinct and important: Feature Requests. They are public proposals for new features — or improvements to existing ones — that any user can open. Each feature request is visible to all Narraya users and votable: a "+1" if the idea serves you, a comment if you want to add your perspective.

It isn't direct democracy — in the end we choose what to develop, balancing priorities, effort, product coherence. But it isn't theatre either: we read every request, votes really count, and many features shipped in recent months were born right there.

Three kinds of feedback that really help us

What is NOT a useful feature request

Let's be clear: "do what [other software] does" isn't a feature request. Every product has a philosophy, and Narraya has its own. If something is missing for you, we want to know why it's missing — the real problem you'd solve — not a generic reference to a competing tool. The same feature, conceived inside a different philosophy, can become an entirely different thing.

And another clarification: requests that contradict our foundational philosophy — for example "I want the AI to write the chapter for me" — we read with respect but won't implement. Not out of stubbornness: because Narraya has taken an explicit stance on what it wants and doesn't want to be, and betraying that stance to please isolated requests would betray those who chose us precisely for that stance.

Dialogue as part of the product

We receive tickets and requests every day. Some make us smile (in a good way), some make us think, some point to problems we'd never have understood existed without the user who lived them. This exchange isn't an "extra" to the product: it's part of the product. Without you, Narraya would be a less good piece of software.

To open a ticket or propose a feature, enter Narraya and look for the "Help" menu bottom-left. The first reply comes by hand — in every sense.