Growceanu Customer.io implementation | Regulated EU crowdfunding
Maciej Turek personally advised on Growceanu’s initial Customer.io implementation, then took over delivery: he audited the inherited workspace, rebuilt the flows, and launched the journeys. Growceanu is a regulated EU crowdfunding platform (ECSPR). Constraints were an already-sending half-built account, relationship data, and compliance review on copy. Launch results: 1.5% email conversion from cold lead to KYC-verified client, and a >55% email opening rate.
1. Context
Growceanu is a regulated EU crowdfunding platform operating under Regulation (EU) 2020/1503 (ECSPR), with Romanian and English language cohorts. The engagement was a Customer.io implementation on an account that was already sending, not a migration from another ESP.
2. Starting problem
The Customer.io workspace was inherited and already live. The data model was only half right. Several live onboarding branches still had messages set to Queue Draft (draft-only sending behaviour), so profiles advanced while messages piled up in Drafts for months. KYC attributes existed in the schema but were not syncing to profiles. Object tokens could name the wrong company. Staging URLs had shipped in live emails. Locale and language segments were wrong. List and IP reputation risk was real on inherited cohorts.
3. Maciej’s role
Independent consultant. Phase 1: advised on the initial implementation until the first pre-launch campaigns were built. Phase 2: took over delivery: owned the inherited-account audit, rebuilt the flows, and built the launch campaigns. First-person ownership of the audit findings and the rebuild described here.
4. Existing stack
Customer.io was already in use, including the classic drag-and-drop editor. People related to relationship objects for fundraising opportunities. Sending ran from a subdomain that needed correct Apple Private Relay registration. This was inherited-account remediation inside Customer.io, not replatforming from another ESP.
5. Data architecture
Person attributes and relationship attributes on fundraising objects had to be distinguished. Timestamps that lived on the relationship object returned nothing when queried as person attributes. KYC fields were defined in the schema but empty on every profile because they were not syncing. Language preference was not reliably populated, which made negative language segments unsafe.
6. Events and attributes
Field and event categories used in this engagement (exact names withheld):
- A discrete “investment started” style event as the journey trigger after relationship-attribute triggers proved too late
- A start timestamp stored on the fundraising relationship object, not on the person
- KYC / verification attributes intended for targeting; empty when sync was broken
- Language preference used (incorrectly, when negated) for language audiences
- Company name on the relationship object for post-investment personalisation; indexed object tokens vs trigger-scoped tokens
7. Migration / implementation approach
Not a migration from another platform. Approach: inventory every live flow and each step’s true sending behaviour → verify every attribute’s location and population on live profiles → find silent breakage (staging URLs, locale gaps) → write findings with severity and get sign-off before new build → fix data location and population → rebuild journeys → run a silent-failure QA checklist → launch. Relationship modelling and compliance review on every template dominated the timeline versus a greenfield event-only setup.
8. Lifecycle journeys
Onboarding branches that had been stuck in Queue Draft; post-investment email that could name the wrong company via indexed object tokens; a referral send; an old-database reminder that bounced heavily; and the launch campaigns Maciej built after taking over delivery.
9. Deliverability
An old-database reminder bounced at 9.5%; the Romanian cohort ran about 7–8%. Thirty-three Apple Private Relay addresses bounced until the sending subdomain was registered correctly. The sending IP had a prior SpamCop listing; causation from the same list is not claimed from the logs. A single flight of 225 bounces at 9.5% shaped Maciej’s steady-state rule: investigate at 3% bounce and hard-pause before the next send. That is his operating threshold, not a vendor standard.
10. QA / governance
Silent-failure checklist used on this account (and kept as ongoing practice): no draft-only steps on live flows; no staging/localhost URLs; segments spot-checked for correct members; attributes exist and are populated; equality checks paired with existence checks; locale routing covers values present in data (including partial locale codes alongside full ones); tokens tested on multi-record profiles; frequency caps and global suppression apply; authentication passes from the exact sending domain.
Four of those failures hit at once on this account: draft-only sending on live onboarding, staging URLs in nine live emails, locale matching only one full locale form, and conditions on unsynced attributes. After a referral send went out to 136 recipients with a compliance wording error (corrected copy existed but never propagated), mandatory two-person sign-off was introduced. The English-language cohort was around 384 delivered, too small to report a language split as a finding.
11. Engineering collaboration
What happened in practice: KYC and related attributes were not syncing onto profiles; in the classic editor at that time, message bodies could not be updated through the API (subject, preheader, and name were available); some running actions refused edits; cloning a locked campaign produced a locked draft. Those constraints shaped how template and journey work was planned. No named engineering team size or ticket volume is published here.
12. Constraints
Inherited half-built account already sending; relationship objects for fundraising opportunities; every template needed legal/compliance sign-off. ECSPR and national rules required the regulator’s authorization statement verbatim on every send. Controlled terminology from the client’s compliance function: “crowdfunding services” rather than “investment services”; avoid words implying screening or endorsement such as “vetted” or “curated”; “companies” rather than “startups”. Those were that client’s instructions in their jurisdiction, not EU-wide marketing copy rules.
13. Outcome
Launch results:
- 1.5% email conversion measured as cold lead → KYC-verified client
- >55% email opening rate, reported with an explicit caveat: Apple Mail Privacy Protection mixes machine and human opens, so open rate is not treated as a deliverability decision input on this site
- More than 10% click-to-open
Technical outcomes documented in first person: replacing late relationship-attribute triggers with an explicit investment-started event; introducing two-person sign-off after the compliance wording failure. No client quote is published.
14. What changed
Ownership of flow and launch delivery moved to Maciej after the advisory phase. Investment journeys moved to an event trigger. QA and governance (silent-failure checklist and two-person sign-off) were installed. Launch journeys shipped. This page does not claim that every audit finding was fully remediated, only the changes stated above.
15. Lessons / what did not work
- Queue Draft left on in live onboarding for months
- Indexed object tokens that returned a confident wrong company
- Empty KYC / verification attributes making an “unverified” condition match everyone
- A negative language segment (“not language X”) standing in for a local-language audience
- Assuming message bodies were API-editable in that editor
- Using open rate as a deliverability KPI after MPP
- Reporting a language performance split at ~384 English deliveries
Need Customer.io implementation like this?
Most engagements start with a short call to review your workspace and constraints. No pitch, no deck.
Book a Free 30-min Strategy Call →