A lead-generation system for a tutoring platform

A CMS for a marketing team that never stops launching pages

The client gave me page designs and told me which content was dynamic. Every structural decision after that was mine: which content gets its own reference collection, how collections link to each other, and which fields stay plain text and which need rich text. The site mixes static pages with 30 collections, grouped by purpose:

• Pages: paid landings, blog, forms
• Locations: main French cities plus a second tier of cities
• Grades and subjects
• Data: counselors, teachers, reviews and city maps, which mainly feed other pages as references

ikando.com/fr

Paid landings matter most, because every campaign needs its own page. Nobody fills these collections item by item. I set up a workflow where the team prepares content in a Google Sheet, exports it as CSV and imports it into Webflow, and I taught them to run it. They now launch new pages in existing collections without me.

A form that starts before the form

Most pages carry an entry point that already answers step one (I’m a parent / I’m a student), so users land on the form one step in. The flow then goes:

• Grade level, with a separate set of levels for higher education
• Subjects
• Postal code
• Personal details: gender, name, email and phone, all validated before submission

Zapier sends every submission to Google Sheets. On TSS the same form adds a “time to call” step with its own scheduling logic.

Postal codes as business logic

Postal codes decide whether Ikando can serve a lead at all, so free text wasn’t good enough. The first version of the form used Google Places autocomplete. As the form logic changed, I replaced it with a custom dropdown that suggests and validates entries against the client’s own list of postal codes, each flagged for whether a tutor is available there. This removed inaccurate addresses and made routing depend on data the client controls.

ikando.com/fr

Areas with no tutor send the user to a dedicated “no match yet” page instead of the standard thank-you page.

ikando.com/fr

Plan calculators connected to Salesforce

For Allakando, Ikando’s parent company, and another of its businesses, I built calculators for subscription and fixed-cost plans. They have two modes, both driven by URL parameters:

• View: a customer opens a link with their current plan preselected, adjusts the settings and sees how the price would change
• Evaluation: a prospect receives a proposed plan and can accept it or change it, then submits either way

Each submission sends both the proposed values and the changed ones, so the team sees exactly what changed. Zapier then registers the update in Salesforce.

Attribution that survives to the submission

Campaign data was being lost as visitors moved between pages or were redirected before reaching the form. I wrote a global script that captures the GCLID, GA client ID, GA source and medium, Meta FBC, VWO campaign ID and landing page URL, and keeps them in localStorage. It also has fallbacks, such as reading cookies and retrying after a delay, for values that aren’t ready on page load. Hidden form fields then attach everything to each submission.

Experiments, consent and routing

• Experiments: I build alternate versions of sections, such as two hero variants, with classes the marketing team targets in VWO
• Consent: CookieYes, set up through GTM
• Routing: the site is French-only but lives under /fr, served through Webflow Localization