StackEvidence tested GetResponse inside a controlled account rather than reviewing it from a feature list alone. We imported contacts, built segments, created emails and automation, tested forms and pages, inspected reporting, and exported data. The result is a capable platform with several important limitations — including one policy issue that materially affects StackEvidence's own use case.
Our account testing supports many of the core workflows GetResponse promotes. The more important question is whether those capabilities, plan requirements, billing behavior, policies, and exit options fit your actual business.
GetResponse combines email creation, segmentation, automation, forms, landing pages, reporting, and related campaign functions in one ecosystem. StackEvidence directly exercised many of those workflows rather than relying only on documentation.
GetResponse Compliance told StackEvidence that content advertising competing services directly or indirectly is prohibited and that the multi-vendor review/comparison model we described would not be compliant. That is a material disqualifier for our own newsletter use.
These are controlled observations from the GetResponse account used for StackEvidence research. They should not be treated as universal performance guarantees.
We imported a controlled contact dataset, mapped custom fields, and created native tags. This confirmed that the account could preserve structured contact information during import.
We created a segment using multiple conditions — including source and buyer status — and confirmed that the expected controlled contact matched.
We tested personalization, desktop and mobile preview, and a controlled Gmail test send. Links worked in the received message. A small inbox test is not evidence of overall deliverability.
We built and published a workflow using a wait period and a link-click condition. The YES branch applied the expected tag and executed the follow-up email.
We created and saved an unpublished inline form with name, email, consent copy, success messaging, and embed options.
We built an unpublished landing page with content, a form, and a thank-you state. Free and custom-domain publishing options were visible, but public publishing was intentionally stopped.
We inspected controlled automation-message reporting and observed report-export options. A CSV report package was downloaded. The sample size was intentionally too small for broad performance claims.
Contact export preserved tags, custom fields, and consent-related fields. A direct export of the segment definition itself was not found.
These findings are narrower than a generic pros-and-cons list because they are tied to specific documented or directly observed behavior.
GetResponse supported the controlled welcome workflow we built, including a wait and click-based branch. The YES path executed successfully. The NO-side action triggered, although the controlled Outlook follow-up was not received, so we do not present the entire branch test as perfectly matched evidence.
Workflow edit, duplicate, and export controls were observed. We did not find version history in the tested workflow. A workflow file download could not be completed in the original cloud-browser environment, so reusable workflow portability remains less certain than contact export.
Both an inline form and a landing page could be created without publishing them publicly. The tested form supported consent copy and success messaging, while the landing-page workflow included a thank-you state and domain publishing choices.
Contact export was one of the stronger portability findings: tags, custom fields, and consent-related fields appeared in the exported contact data. That does not prove that automations, page designs, segment logic, and every reporting asset can be reconstructed automatically on another platform.
Software can be technically capable and still be unsuitable for a business when its account rules conflict with the way that business operates.
StackEvidence asked GetResponse directly about an independent editorial newsletter that reviews and compares competing software. GetResponse Compliance subsequently told us that content advertising competing services, directly or indirectly, is prohibited.
For the specific model we described — independent software reviews and comparisons involving multiple brands — GetResponse said that content would not be compliant.
This conclusion applies to GetResponse's suitability for our production email use case. It does not mean the software is unsuitable for every business, and it does not erase the useful capabilities observed during product testing.
A transparent review should show what was not fully tested as clearly as what was.
It deserves consideration when your requirements include email, segmentation, automation, forms, landing pages, reporting, and related campaign tools — and when its current account policies fit the content you intend to send.
Multi-vendor comparison publishers should examine policy fit before migrating a real audience. Likewise, businesses needing specific automation depth, simpler workflows, or stronger portability should compare the exact plan and alternatives rather than assuming broad feature coverage settles the decision.
StackEvidence separates primary documentation, direct observation, human vendor guidance, and unresolved limitations. Direct testing supports what happened in our controlled account; it does not create guarantees for every user, plan, region, or future product version.
StackEvidence can publish useful product research before an affiliate relationship exists. If a future commercial relationship is established, it does not remove the limitations, policy findings, or reasons another product may be a better fit.