Overview
A support desk is judged on one thing: how long it takes to answer “is this covered?”. Everything expensive happens while that question is open — the engineer who was sent for free, the argument about a warranty that expired in March, the invoice nobody raised because it was easier not to.
Nama’s support desk answers it at intake, because the desk runs on the same database as the invoices.
Two doors into the same work
The complaint is the intake log: who called, about what, and is it covered? Its value is the search built into it — pick the customer, press search, and the screen offers rows from that customer’s committed sales invoices or their service contracts. Choosing the right row fills in the invoice, the product, the serial number, the warranty period, the warranty end date and the address in one action. It is also the only screen here that records a suggestion or a plain remark rather than a fault.
The ticket is the case file: who is fixing it, since when, and where is it now. It carries the customer, the product and serial, the responsible employee, severity and ticket type, the estimated fix period, the running discussion, and — the field everybody looks at first — whether the product is under warranty or covered by contract.
A desk that logs every inbound call keeps both and converts the minority that turn into technical work. A desk that only records faults raises tickets directly.
What happens to a ticket
Work is recorded, not assumed. A ticket execution is the technician’s timesheet against the case: hours worked and completion percentage, one per visit or session, so “how many hours have we spent on this customer” is a question with an answer. A ticket follow-up is the conversation record and the gateway that moves the ticket’s status — parked while a part is on order, reopened when the customer says it is still faulty, closed when it is done.
A ticket can also become an FAQ entry, or a development request when the fault turns out to be something to change in the product rather than something to fix on site.
The contract that is also the invoice
A service contract is a priced, period-bounded agreement that a named customer’s listed products are entitled to support. It is worth understanding one design decision about it: the contract carries its own money — line prices, discounts, taxes, net value, paid and remaining — and committing it is the billing event. It is not a contract that later generates invoices, and nothing raises a recurring one from it. If you sell monthly cover, the monthly billing is planned in accounting rather than expected from this document.
What the contract does do is answer the coverage question at the till of the support desk: a ticket matched to a live contract reads as covered, and the contract lists the tickets that were served under it.
What it does not do
Severity, expected date and estimated fix period are recorded and are not read by anything: no queue sorts by them, no clock is watched, nothing warns on a breach, and there is no escalation state or automatic notification. There is no customer-facing portal — customers cannot see or raise their own tickets — and no ticket consumes spare parts or bills labour by itself; parts are issued with an ordinary stock document.
Where a desk needs alerting or an SLA timer, it is built on the platform’s notification engine and entity flows, which watch business events across the whole system. That is a deliberate division: the support module keeps the record, and the platform does the automation, so both can be relied on to behave the way they are described.
The complaint, ticket, execution, follow-up and contract screens are documented in the support section.
