Contact

The contact page is designed for businesses to communicate their use cases to the Zentor team. The page combines personal consultation, a demo and direct written contact. The most useful inquiry describes the intended processes rather than simply stating "I would like information".

The message can mention the desired channels, the approximate number of users, the type of knowledge sources, required integrations and any need for multiple tenants. WhatsApp, SMS, telephone bot/SIP, n8n automation or an on-premises request should also be mentioned. This allows the Starter configuration to be correctly distinguished from an Individual (Individuell) configuration and from add-ons that require manual activation.

The contact form should never include passwords, API keys, widget tokens, payment details or unnecessary customer data. When reporting an existing technical issue, the tenant name, time of occurrence, affected function and reproduction steps are sufficient. Confidential information in screenshots should be redacted.

The personal consultation form collects name, email, company, phone number and inquiry. Submission is not possible without the required fields and privacy consent. Submitting the form does not automatically create a tenant and does not constitute a binding offer. Individual (Individuell) configurations are reviewed manually.

The on-premises option is not self-service and is currently in preparation for use. Package upgrades and add-on purchases are also not fully self-service through the dashboard. Contacting the team therefore serves to clarify configuration and activation steps.

The phrase "typically one business day" mentioned on the page, while present in the current content, should not be presented as a binding service-level commitment. Workload and the scope of the request can affect response time. The confirmation shown after submission should be kept, and a reachable business email address should be used. The purpose of the contact page is not to create sales pressure, but to correctly classify the actual use case technically and commercially.

Before submitting, the purpose of the message can be summarized briefly: new setup, integration, pricing or technical issue. This classification makes internal routing easier. Instead of submitting several forms in a row for the same topic, the same email address and company name as the first inquiry should be used; a follow-up message can reference the previous inquiry if needed.

If a form validation error occurs, the entered text is preserved and only the affected field is marked. After successful submission, the user should see a clear confirmation. The page should describe the next contact step without giving the impression of an automatic contract or instant activation.

The contact request can include a preferred language and a reachable time window. This information does not change the technical content but helps plan the response more efficiently. Optional fields may be left blank; fabricated information should not be entered.