The context given to the engine
Before it even understands the request, the engine receives context specific to the role: what's useful to a technician on a job site isn't what's useful to a call handler.
The interpretation engine behind SpeakDo is the same for everyone. What changes is the business profile: it defines the context that's passed in, the actions that are relevant, the vocabulary that's understood — and just as important, the actions that must never be offered to a given role.
What each profile can see and do today:
A business profile isn't cosmetic. It acts before the engine even answers — on what it receives, what it can propose, and what it isn't allowed to propose at all.
Before it even understands the request, the engine receives context specific to the role: what's useful to a technician on a job site isn't what's useful to a call handler.
Each profile only exposes the actions that make sense for its role. A project manager sees tasks and deadlines, not field-intervention operations.
A profile also restricts which objects it actually touches in Dolibarr — tickets, interventions, tasks, contacts — to what the role genuinely needs, and nothing more.
The words used change with the role: an "intervention" for a technician, a "case" for a project manager, a "call" for a receptionist.
Some chains of actions only make sense for a given profile. Preparing an intervention isn't a useful gesture for a front-desk role.
A profile deliberately removes certain actions from the realm of what's possible. It isn't a checkbox on the user's side — those actions simply are never proposed.
More profiles are planned over time. SpeakDo's architecture is designed to eventually support dedicated pages for each business profile.
SpeakDo's original field profile: intervention reports, time tracking, tasks and client lookup, straight from the phone while on the job.
A deliberately restricted profile, built for public-facing interactions: identify a caller or a company, create a follow-up ticket. Invoices and full customer records are never exposed to this profile, including when the caller hasn't been verified.
Tracking tasks, deadlines, and client or project follow-up — without the field-intervention actions or operations that don't belong to this role.
A profile intended for warehouse use cases — still in an exploratory phase. Its exact scope will be defined as it develops, rather than announced in advance.
Restricting what's offered isn't just about ergonomics. It's an additional layer of security, on top of the permissions already enforced by the ERP — never in place of them.
SpeakDo's general operation is covered in detail on the Dolibarr and Security pages.
No. The permissions defined in Dolibarr remain the final authority on what can be executed. The business profile acts upstream: it restricts what is offered, not what the ERP allows.
Get in touch at hello@speakdo.fr to discuss it. Defining a new profile takes work on the context, vocabulary and relevant actions specific to your business — we can't commit to a timeline in advance.
Yes. The same profile mechanism applies to both: what changes is the channel the intent arrives through, not how it's filtered.
No, never. This is a deliberate design choice: this profile is built for potentially unverified interactions, so it never exposes financial data or full customer records.
See how a business profile applies in practice depending on the channel used.