BuildCaster.

Guide · BUILDCASTER

Move the useful history. Leave the spreadsheet mess behind.

A spreadsheet can store customer requests for a long time. The difficult part of moving it is deciding which rows are ideas, which are evidence, and which contain information that should never become public.

Preserve the original export, test a small sample, and review imported ideas before publication. Importing data is not permission to email people.

Keep an original before cleaning anything

Save the complete source export in a location your team controls. Record where it came from and when you exported it. Do not make your only copy the cleaned CSV you are about to import.

List the information the new system can and cannot represent. A rows-only import is different from migrating comments, identities, decision events, relationships, old URLs, and notification preferences. If you are switching products, check those gaps before cancelling the old service.

Separate the public idea from the private evidence

Make a concise title and summary for each actual need. Remove personal information and account-specific material from text intended for customers. Keep original messages and customer identifiers in your private source record instead of copying them into the public description.

Split a row containing several unrelated requests. Compare repeated rows before merging: different customers may describe the same outcome, or they may mean different things by “better exports.” Use the duplicate checklist when it is ambiguous.

Map fields deliberately

BuildCaster’s owner import workflow provides CSV mapping and a preview. Imported ideas enter Inbox for review and send no customer email. It is not a full-fidelity importer for another feedback platform.

Source informationHow to treat it
Title and descriptionRewrite as a specific problem and desired outcome. Check length and required fields in the importer preview.
StatusTranslate the meaning, not just the label. A legacy “open” row is not necessarily committed work.
Support countKeep it labeled as historical/imported support. Do not create fictional verified voters.
Emails and notification listsPreserve privately as needed. Do not treat their presence in a CSV as a follow or new notification consent.
Source IDs and linksRetain them in your source archive or supported provenance fields so the team can trace the migration.

Test the awkward rows first

Keep a reconciliation sheet: source row identifier, imported destination, review outcome, and any intentional omission. That small record makes it easier to investigate a missing request later.

  1. Select a small sample with quoted commas, line breaks, non-English text, missing values, and a long description.
  2. Preview the mapping. Check that a multiline description has not become several ideas.
  3. Import the sample and inspect its title, summary, support labeling, and private source handling.
  4. Verify that it is still unpublished and that no customer message was queued.
  5. Review the sample before importing the rest. Track which source rows you already imported; do not assume re-importing is an update operation.

Publish a usable board, not an archive dump

Approve the ideas that belong in the current conversation. Record Not planned or Cancelled outcomes where appropriate, and archive older material intentionally rather than letting it overwhelm the default view.

Test an owner export after the move. BuildCaster offers an ideas CSV for operational reporting and a fuller JSON export for relationships and source data. Keep the original source backup alongside it until you have checked the migration.

Then follow the portal launch checklist. Tell customers where future feedback belongs and explain the new workflow; do not automatically enroll the imported contact list in announcements.

FROM FEEDBACK TO FINISHED

Keep the conversation connected.

A customer portal, a roadmap, and release updates. One record from the first idea to the announcement.