Your Dolibarr catalog, answering at any hour.
Peaking answers on whichever channel they wrote from, with your own technical judgment. What gets sold is written into your Dolibarr, with no re-keying.
Today every request goes through the person who knows the catalog: they find the part number, check what is on the shelf, build the quote and key it in.
While that happens, the customer is waiting. Sometimes, asking somewhere else.
What changes at the counter.
Every answer goes out with that customer price list and with what is on the shelf today.
When the customer confirms, the sale is already in your Dolibarr. Nobody types it again.
Your customer knows when what they bought arrives, without calling your team.
Your specialists stop searching and keying, and spend the day closing.
From the customer message to the order written.
Your customer is recognized with their history, without repeating who they are.
The option you actually have, not the one that ran out.
On that customer price list, with no keying errors.
The sale written into your Dolibarr without anyone typing it.
Your customer knows when their order arrives.
It turns on when you say so.
Nothing gets connected without your sign off, and Peaking is already operating on its own catalog before that.
Reviewed in the discovery session and turned on when you authorize it, not before.
Read first, write second. Each stage turns on once the previous one is producing a result.
Every customer runs in its own environment, and your data is yours.
Peaking answers and quotes from the first day, before touching Dolibarr.
What the front office asks first.
What changes for the person quoting today?
They stop searching and stop keying things in. They come in on work already done, review what needs reviewing and close. Their judgment is still the one that decides.
Do we have to change how we work in Dolibarr?
No. Dolibarr stays exactly as it is, with your price lists, your warehouses and your terms. Peaking works with that, not on top of it.
What if our catalog is incomplete or badly named?
That is normal and it is part of the implementation work. The catalog ends up organized with your own house judgment, and that stays yours.
How long before it is running?
Peaking answers from day one on its own catalog. The connection to Dolibarr turns on in stages, and each stage turns on once the previous one is producing a result.
Can we start before connecting Dolibarr?
Yes, and that is the recommended way. You see the result before you ask anything of your systems team.
Other systems it works with.
Peaking works with the ERPs industrial distribution runs on.
What your systems team will ask.
Verified against the Dolibarr project documentation.
The Dolibarr REST API module exposes products, third parties, proposals, orders, shipments and warehouses for read, create and status change, and the Webhook module sends events to an external URL.
A per-user key generated on the Dolibarr user record and sent in the DOLAPIKEY header; it can also be obtained through /login. The user permissions in each module limit what can be read and written.
Cloud or your own server. Peaking works the same either way, and the connection route is decided in the discovery session.
Dolibarr with the REST API, Products, Proposals, Orders and Stock modules enabled. An integration user with a DOLAPIKEY generated on their record. User permissions over third parties, products, proposals, orders and shipments. The Webhook module enabled to receive change notifications (Dolibarr 17 or later).
Industrial distributors already running this way.
You've got this.
Peaking shows up to the session already running on your catalog, so you watch one of your own requests land in your Dolibarr.