Every other system asks you to change how you work. We change the system instead.
salesq is a sales operations system that already runs: revenue, accounts, invoices, receivables, stock, orders. Every implementation starts from that base and is then built out to your processes, your rules and your integrations, and it keeps being built out for as long as you use it.
It fits on the day you sign, and never again after that.
The implementation takes quarters
Months of mapping your way of working onto someone else's model. The parts that will not fit become a spreadsheet next to the system, and that is where the real work quietly moves.
Every change is a ticket and a quote
The software is finished when the vendor says it is. Your process keeps moving; the system stays where it was. What you wanted becomes a feature request behind a thousand other feature requests.
And then you replace it
A few years on, the same evaluation, the same migration, the same budget. Everything your people learned about the old system goes in the bin with it.
There is a third option between a template you have to bend to and a project that starts at nothing. Start from a system that already runs, and have the rest written for you.
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.
Three jobs it takes off your desk.
Supplier invoices that book themselves, and go out when you say so
An invoice arrives in the mailbox and a model reads the PDF: line items, totals, VAT number, order reference. It is matched to the account and the lines are booked against the open order. Nothing is matched on a guess: when the match is not certain the invoice waits in a review queue for a person, and sending to the customer is always a deliberate click.
Switch between a clean invoice and a doubtful one to see where a person is needed.
Who owes you what, sorted by who needs a call today
Outstanding balance, aging, credit use and DSO per account, kept current from the daily bank and ledger import. The order of the list is the point: the account that needs attention floats to the top by itself instead of being found by whoever happens to look. Every call, promise and escalation is logged against the account.
Re-sort the list. Risk weighs credit use against how long the money has been overdue.
| Account | Outstanding | Used | 31–60 | 60+ | DSO |
|---|
| Article | On hand | Allocated | Free | Inbound |
|---|
What can ship today, and what is waiting on a container
Stock per warehouse, what is already promised to an order, what is genuinely free, and which inbound shipment covers the gap. Who gets the last units when two orders want them is a commercial decision, not a technical one, so that rule is written to match how you actually decide instead of being fixed for you.
Allocate an order. One of the three cannot be filled from stock; the shortfall says so instead of hiding it.
The base is the same for everyone. Everything above it is written for one company.
The base does not have opinions about the decisions that make your company yours, because those are the ones no two companies make the same way. That layer is written, not configured around. This is the sort of thing that lands in it.
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 process changes, and that changing it is not a new negotiation every time.
Implementation on your processes
A one-time fee. We read how your office actually works, then build the base out to it. Weeks, not quarters, because the base is already running.
Development inside the subscription
New reports, new integrations, a new step in the workflow. 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 processes 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. It is a question that cannot be answered from a brochure, which is why we ask what your office actually does before saying anything about it.