English
+ Tickets and support

A request that does not vanish into a shared mailbox.

Customer requests and internal reports with an owner, a visible status and the history on the customer. A ticket can also start from a form or a conversation.

01 · The problem

A shared mailbox is not a process. It is a hope.

Requests arrive at info@, at a personal address, through the contact form and by phone. Whoever has time answers. Two people work the same request, a third is left because everyone assumed somebody else had picked it up. When the same customer calls three weeks later, the reconstruction starts over, because what was discussed last time sits in the mailbox of someone who is not in today.

02 · Under the hood

What turns a request into a case you can follow.

Answering is not the hard part. Keeping sight of everything still open is. These five points provide it.

  • Owner and status, Every ticket has a responsible person and a visible state. No duplicate work, no silent stalling.
  • History per customer, Earlier requests, invoices and contracts sit alongside, instead of in four systems.
  • From forms and chat, A ticket can start from a form submission or a conversation, without retyping.
  • Categories and priority, Sorted by type and urgency, so the important does not queue behind the loud.
  • Analysis by frequency, Knowing which request keeps coming back is the basis for removing it rather than answering it.
03 · What it's worth

The third identical request, seen as a pattern instead of a one-off.

Work it out with your own numbers. At 40 requests a week, experience says five to ten per cent go through twice or not at all when ownership exists only in someone's head. That is two to four cases weekly, each with an irritated customer or an unnecessary repetition at the other end. The bigger lever is the analysis: if the same question arrives 30 times a quarter, the answer is not a faster ticket, it is an article in the wiki or a fix in the product. Without counting, you never see the pattern.

04 · Who it is for

Who tickets and support are built for.

This is built for Swiss companies with roughly five to fifty employees whose customers are still looked after once the sale is done: technical services and software houses, building services and maintenance, machine builders with a service contract, property management, fiduciaries, internal IT. Typically two to five people who answer requests alongside their actual work, and customers who keep coming back over the years.

It pays off most for anyone looking after recurring customers with a contract behind them: maintenance, a service retainer, a subscription. That is where it counts that the same record shows what was last reported, delivered and invoiced. The longer the relationship runs, the more that trail carries.

05 · Switching

The move starts with what is open today.

You begin with the cases in progress, not with the archive. Whatever is sitting in the mailbox right now, you capture once as a ticket, with customer, category and owner. You point the contact form on your website at a form on the platform, so new requests arrive as tickets from the start. Categories and priorities you take as a template, or name them after the cases that actually come up in your business. A default owner per category is enough to begin with.

What follows is deliberately little: no training week, no role matrix that would have to be designed first. In the first week the old mailbox keeps running, and whoever picks up a request from it creates it as a ticket in one step. The only thing you have to bring along is the open cases. Closed correspondence stays where it is, and nobody presses three years of e-mail into a new form.

06 · The platform

Tickets & support is one module — here is the rest.

07 · Frequently asked

What managing directors and service leads ask first.

Our requests arrive through five channels. Do we have to retrain our customers?

No. Whoever calls today keeps calling, whoever writes to the general address keeps writing there. What changes is the first move afterwards: the request becomes a ticket in one step, with customer, category and owner. For the website a form is worth it, because from the start it brings in the details you would otherwise have to ask for.

Who decides who is responsible?

You set a default owner per category, so a new ticket does not sit ownerless in the inbox. It can be reassigned at any time, including to a second person for escalation, and the change is in the audit chain with person and timestamp. When someone goes on holiday, you redistribute their open tickets from the overview instead of collecting them one by one.

Can we use this for internal reports too, not only for customer requests?

Yes, and that is often the first use case: broken equipment, missing access rights, defects from the shop floor, matters for administration. The report comes from an internal form or from a conversation, is given a category and an owner, and appears in the same overview as the customer requests. The two worlds are kept apart through category and visibility.

Our maintenance contracts state response times. Can that be represented?

You set urgency through priority and category, and every ticket shows how long it has been open. The overview can be sorted by that, and the question of what has been lying around longer than agreed you put to the assistant directly. Which deadline applies to which customer you record on the customer record, where the contract sits as well.

Where is the data from the tickets, and what about the revFADP?

Your data is hosted in Switzerland. Before anything is sent to an external AI model, our Sensitive Data Guard masks or blocks personal, contract and financial data, only the released, non-identifying content is forwarded, under no-training agreements. Requests for access and erasure under the revFADP can be evidenced through the audit chain, with person and timestamp.

Does every employee see every ticket?

Not necessarily. Visibility can be set per role: the service team sees its categories, management sees everything, individual categories can be drawn more tightly. A ticket shows the customer history needed to work on it, and not automatically every document that exists for that customer. Every change is in the audit chain, traceable with person and timestamp.

Our technicians are on the road. Does this work on a phone?

Yes. The ticket list, the status and the history look the same on a phone as at the desk. A report back after the job is one sentence, dictated or typed, and it hangs on the right ticket. So what was done is already there in the evening, instead of being entered from memory the next morning.

A support case often turns into paid work for us. What then?

Then the case stays where it is, and the work on it becomes visible: the hours are recorded on the ticket and therefore hang on the same customer. From that comes an offer or a line item on the next invoice, with the same details. Larger cases you carry on as a project, with a budget and tasks. Master data is not typed a second time.

Follow a request from arrival to pattern, in 30 minutes.

We show you a ticket raised from a form, the assignment, the customer history with invoices alongside, and the question of what came up most often this month. No contract, no preparation.