Contact & Customer Setup FAQ
This page is the central contact and orientation path for customers. It explains where each request belongs, which information is useful, and which documentation matters before setup, review, or support.
Contact path
For setup, technical questions, and documentation reviews, communication currently runs centrally through GramGrow. This keeps requirements, security questions, provider details, and next steps in one traceable thread.
Email: admin@gramgrow.io
Subject: GramGrow customer setup
Suggested content:
- workspace name and your role
- affected area or provider
- setup goal or issue
- test/sandbox/live context
- relevant timestamp or anonymized example
- preferred next stepDo not send secrets by email
| Request | Typical examples | Relevant areas |
|---|---|---|
| Workspace & team | Invites, roles, access, settings, plan, or general onboarding. | /settings, /team, /plan |
| Telegram CRM | Inbox, contacts, tags, pipelines, broadcasts, automations, or tracking. | /inbox, /contacts, /broadcasts, /automations, /tracking-links |
| Payment & access | Stripe, Digistore24, PayPal, Gumroad, Purchase Checker, membership, or access decisions. | /docs/stripe-payments, /docs/digistore24, /docs/paypal, /docs/gumroad |
| Trust, privacy & security | DPA, subprocessors, Telegram data flow, retention, export, deletion request, or security questions. | /trust, /privacy, /security, /dpa, /subprocessors |
| UID, broker & partner data | UID Checker, partner reports, broker attribution, PU Prime, or read-only reporting scope. | /uid-checker, /docs/pu-prime |
What you should send
A good request describes the goal, affected area, and current state. This lets GramGrow route the right documentation, next setup step, or technical check directly.
- Workspace name, role, and affected product area
- Provider or module: Telegram, Stripe, Digistore24, PayPal, Gumroad, tracking, automations, UID/broker, or trust
- Whether it is about setup, re-check, Purchase Checker, webhook/IPN, data flow, roles, or privacy
- Test, sandbox, demo, or live context with timestamp and observed result
- Anonymized sample payloads or screenshots without visible secrets
Customer checklist before setup
1. Identify the workspace
Share the workspace name, your role, and the affected product area. For team access, the affected email is enough; do not send passwords or session data.
2. Describe the setup goal
State whether you are setting up Telegram inbox, broadcasts, automations, tracking, a payment integration, Purchase Checker, membership sync, or UID/broker validation.
3. Separate environments
Clearly mark test, sandbox, demo, staging, or live. Do not mix live credentials with test data, and do not send secret values by email.
4. Send evidence without secrets
Useful evidence includes screenshots without visible tokens, error messages, timestamps, provider names, customer email, or anonymized sample payloads.
5. Check the relevant docs
Review the matching integration page and Trust Center first. This keeps the exchange short and makes the next action clear.
What GramGrow provides
| Area | What you can expect |
|---|---|
| Clear setup paths | Guides for Telegram, payment providers, Purchase Checker, tracking, UID/broker, and trust topics. |
| Security boundaries | Guidance on read-only scopes, roles, encrypted provider secrets, and what should not be shared by email. |
| Verification steps | Re-checks, Purchase Checker tests, webhook/IPN expectations, and clear success criteria per integration. |
| Product boundaries | Transparent separation between the GramGrow workspace, Telegram, payment providers, broker/partner data, and legal documents. |
FAQ
Which documentation should a new customer read first?
Start with the matching provider integration page, the Trust Center, and the Telegram data flow page. For operations teams, inbox, contacts, broadcasts, automations, and tracking are the most important product areas in the workspace.
Should I send real customer or payment data?
No. Send anonymized examples or describe the case. Real customer data, payment data, and secrets belong in the intended systems, not in email, chat, or screenshots.
How does GramGrow separate test, sandbox, and live?
Setup requests should always name the environment explicitly. Test or sandbox credentials must not be mixed with live payments or live webhooks. Live steps need deliberate approval and clear success criteria.
Which teams should review the documentation?
Depending on the setup: workspace owner or admin, operations, support, payment/finance owner, privacy/security, and for UID or broker topics the relevant partner or integration team.
What is the fastest way to resolve an integration issue?
Send provider, environment, goal, timestamp, observed result, and the documentation page already checked. For payments, also state whether re-check, Purchase Checker, webhook, or IPN is affected.