Key takeaways
- Planned for a later release. Nothing about it is available today.
- Import is meant for an existing pipeline: deals, companies and contacts kept in a spreadsheet or another tool.
- Export follows your permissions: you get only the records you are allowed to see.
- The columns, file limits and matching rules will be set with design partners before it is built.
Planned feature: not in Delsivo yet, and details may change before it ships.
What is CSV import and export for?
Most lean funds already keep a pipeline somewhere: a shared spreadsheet, a form tool's response sheet or a CRM. Moving to Delsivo shouldn't mean retyping it, and leaving shouldn't mean losing it. A CSV file is the plainest way to move rows between tools, which is why it is the first data connection on the roadmap rather than a sync with any single product.
The product facts are short on this point: CRM import and export is a later release, and Delsivo isn't a CRM replacement at first. Here is what the import and export are meant to do and what is still open, so you can plan around it honestly.
How do records get into Delsivo before CSV import and export ships?
The pilot has three ways in, all described in the PRD's intake requirement:
- Founders apply on your branded application portal. Submitting creates the deal, the submission and the deck version in one step, and a retried submit still gives one deal and one receipt.
- Private referral links let someone you trust send a founder to the same form, with the referral kept on the record.
- Analysts create a record by hand and upload a deck on the deal. The deck then goes through the same scan, extraction and slide citations as an applicant's.
Design partner pilots also start with historical deals, used to calibrate extraction and your rubric before live intake. How those older decks are loaded is agreed with each fund during set-up.
What an import is expected to handle
None of this is final. It is the shape we expect from the PRD's data model (companies, deals, submissions, contacts) and its rules on duplicates and history.
| Area | Expected behaviour | Status |
|---|---|---|
| Companies and deals | One row per deal, with company name, domain, stage and source | Columns not yet decided |
| Contacts | Founders and referrers linked to the deal they belong to | Not yet decided |
| Duplicates | Rows matching an existing company domain or founder become a suggestion an analyst confirms, never a silent merge | Follows the pilot duplicate rules |
| Stages | Mapped to your stages, with Passed and Revisit kept as their own states | Mapping screen not yet designed |
| Re-running a file | Importing the same file twice should not create a second copy of each deal | Required by the PRD for every integration |
Duplicate handling would reuse the pilot's duplicate detection: company domain and founder identity, with a person confirming each merge.
What an export would contain, and what it would leave out
The PRD's reporting rule already applies: an export contains only records the person asking can access. An analyst who sees only assigned deals would export only those. Guest experts and founders can't export the fund's pipeline at all.
Internal notes, ratings and decision rationale are the fund's working record. Whether they belong in a CSV, or only in a fuller export a fund admin requests, is one of the open questions. Exports would be logged in the deal audit trail like any other access to founder data.
What stays your decision
- Which records you import, and whether you clean them first.
- Whether imported deals are screened against your rubric. Re-screening old deals would create new assessment runs and keep any earlier ones.
- Who on your team may export, set through roles.
- What happens to founder data you export. The fund is the controller of founder data; Delsivo processes it on your behalf.