A customer's unit is somewhere between your bench and the factory. Nobody can say where.
rmaq is a returns and repair system with three ways in: your own staff, the partners who sent the unit, and the person waiting to get it back. One case, one record, three views of it, and none of them is a mailbox.
A unit leaves your customer and disappears into a process nobody can see.
Three people ask the same question
The customer asks the partner, the partner asks your office, your office asks the factory. The answer exists in someone's mailbox, in a thread nobody else can read, and by the time it comes back it is out of date.
What a case costs is a guess
Freight out, freight back, the hour on the bench, the customs value, the credit note. Almost nobody adds those up per case, so nobody knows which product line is quietly expensive to stand behind.
You promise a date you cannot keep
Someone says two weeks because two weeks sounds reasonable, not because anyone can see the queue. The promise is broken quietly, and the next call starts one step angrier.
Repairing the unit is not the hard part; your bench already knows how to do that. The work is answering where it is, over and over, for months.
What already works, before anyone writes a line for you.
The screen at the top of this page is the base. It is not a demo build and not a starter template; it is the working system, and an implementation begins here rather than at nothing. That is why the first version you can actually use is a matter of weeks.
The three screens below are that base at work. What gets written on top of it is the section after them.
One case, seen three ways.
The same case, told correctly to each of the three
Your staff see the whole record: the test result, the shipment it travelled in, the customs value, the internal note. The partner sees the state of their own case and nothing about anyone else's. The end user sees where their unit is and when it comes back, in plain words. It is one record, so the three can never drift apart, and nobody has to retype anything to keep the others informed.
Switch between the three and watch the same case change register.
The queue, sorted by what is stuck rather than what came in
Every open case with how long it has been sitting in its current stage, not just how old it is. A case can be four days old and already stuck, and another can be six weeks old and moving exactly as it should. Sorting on the wrong one of those is how a unit ends up forgotten in a corner for a month.
Re-sort the list. Anything sitting longer than the target for its stage turns red.
| Case | Stage | Days here | Days total |
|---|
The box, the packing list and the customs paperwork as one thing
A unit is put in a box, the box goes in a shipment, and the shipment needs a packing list and a declared value before it crosses a border. Those are three documents that are usually typed three times from the same facts. Here they come out of the box itself, so taking a unit back out of the box takes it off the paperwork too.
Take a unit out and put it back. Weight, value and the documents follow.
The base is the same for everyone. Everything above it is written for one company.
A return is a commercial decision wearing a logistics costume. What you cover, how long you cover it, where the goods go and who pays the freight are your policy, not a setting in someone else's product. That layer is written, in this order.
One implementation, and then it keeps being built.
What separates this from an off-the-shelf licence is not the first version. It is that the system does not stop fitting when your policy changes, and that changing it is not a new negotiation every time.
Implementation on your rules
A one-time fee. We read how your returns actually run, then build the base out to it. Weeks, not quarters, because the base is already running.
Development inside the subscription
A new carrier, a changed warranty term, a report the factory suddenly wants differently. The same people who built it keep building it, and it is already paid for.
No second procurement
You do not grow out of this into a migration project. The system converges on your organisation instead of the other way around.
There are no amounts on this page on purpose. The number follows from your rules and your integrations, and a figure invented to look reassuring would be worse than none. The first conversation settles the scope; the second one carries a price, in writing, before anything is built.
Custom software raises four fears. Here they are.
What if you stop?
Your data is yours and leaves whole, through an export or the API, at any moment and without asking. What happens to the source of your build if we disappear is settled in the contract, before the first line is written, not discussed once it matters.
Who owns what gets built?
The base stays ours and keeps improving for everyone on it, which is why you are not paying for it from scratch. What is written specifically for your organisation is yours.
Where does it run?
On our own infrastructure inside the European Union. Your data sits in your own database and is never pooled with another customer's, never used to train anything, and never shown to anyone else.
Who fixes it on Monday at nine?
The people who built it. There is no first line that takes your description and forwards it to somebody who has to work out what your business does.
See whether this fits your organisation.
Six answers, and we tell you what we think fits and what does not. Returns are one of those processes where the details decide everything, so we ask about yours before saying anything about it.