Skip to main content

Contact and support · Begin with context

Tell us where you stopped, and we will begin from the same point

Whether you are comparing before subscription, setting up a first store, or clarifying an external provider requirement, send a clear description and store link when one exists. The request form stays consistent, and only configured direct support contacts appear beside it.

Pre-sale questionsSetup helpCatalog migrationProvider activation

Route the request early

The question type tells us what the answer needs

Selecting a topic does not place you in an automated loop. It helps the team distinguish a commercial question from an operational or credential-related request that needs careful handling.

Plan and inclusions

Ask about the annual plan, an optional add-on, or the boundary between Shop Tek and external provider charges.

Product or customer migration

Name the platform or file format and complex fields. Do not include sensitive records in the first message.

Payment, messaging, or invoice setup

Name the provider and account state. Never send a password, API key, or secret through a support form.

Issue in an existing store

Include the store link, steps you took, and expected result. Avoid entering full customer details.

One request with useful information

Send a request to the Shop Tek team

Required fields help us associate the question correctly. We will use email for the reply, while phone is optional if the issue needs a follow-up explanation.

Is the issue stopping orders now?

Write “order intake unavailable” in the first line, then include the store URL, approximate time, and last action that worked. Avoid repeated live-store changes that may widen the impact.

Include steps, expected result, and any error message. Do not enter passwords, provider secrets, or payment data.

We use this information for support and do not automatically add you to marketing messages. Review support-request privacy terms

Before sending

Small details can remove an entire round of questions

For an in-store behavior, include the page, steps in order, and the device or browser used. A screenshot may help later, but do not send one when it reveals a customer phone, address, payment code, or login secret.

For a provider request, include provider name, country, and account state: new, under review, or active. That is enough at first. API keys and secrets do not belong in a public form; the team can define a secure channel if activation needs one.

Access, correction, or deletion requests need a way to verify the requester relationship with the store. That does not mean sending sensitive documents immediately. State the request and account email, and the team will explain an appropriate verification step.