Solutions

Survey Programming & Scripting

Scripting, logic, and testing for instruments other people designed — including the ones that arrive as a spreadsheet with tracked changes still in.

What you can expect

  • Logic that holds

    Routing, quotas, and piping tested against every path before launch.

  • Localisation

    Translation handling and per-market variants managed in one instrument.

  • Tested before launch

    Full dummy-data run and a link you can click through yourself.

Detail

What this covers

Survey programming turns a designed questionnaire into an instrument respondents can actually complete correctly — routing that sends people down the right path, quotas that close on time, and piping that carries an answer from one question to the next without dropping it. The scope covers programming in the major survey platforms, complex routing and quota logic, conjoint and MaxDiff setup, localisation across languages, and an accessibility review of the respondent-facing instrument. Scripting is a service in its own right here — you do not have to buy the fieldwork with it, and a questionnaire designed elsewhere is a normal starting point, not an exception.

When you need it

This is the right call when a questionnaire exists but nobody on your side programmes, when the logic is complex enough — nested quotas, a conjoint exercise, extensive piping — that an in-house tool would strain under it, or when a study needs to run identically across many languages and markets at once. It is also worth using on a study you are fielding yourself, purely for a second set of eyes on the routing before real respondents see it — logic errors are cheap to catch in a spec and expensive to catch mid-field.

How an engagement runs

You send the questionnaire in whatever state it is in — a clean document or a spreadsheet with tracked changes still in it. We return a specification document first: every route, quota, and derived variable written out in plain language, before any programming starts, so ambiguities get resolved on paper where they are cheap rather than discovered in a soft launch. Programming proceeds against that signed-off spec, and every path — every routing branch, every quota cell, every language variant — is tested against it before anyone outside the team sees a link. A soft launch against real respondents follows, checking completion times, drop-off points, and open-end quality, with any fixes tracked back against the original spec so the logic stays internally consistent rather than patched ad hoc.

What you get

A tested instrument, a soft-launch report covering completion rates and drop-off by section, and a test link you can click through yourself across every branch before committing to full field. The specification document ships alongside it, so the routing and quota logic remain auditable after the project closes — useful on its own if the study gets revived or adapted for a later wave.

Have a study that needs this?

Tell us the decision you're trying to make. We'll tell you honestly whether this is the right service line for it.