Key takeaways
- Requests start from a deal, a claim or a checklist, and go out with a message a person has approved.
- Pilot forms: text, number, select and file questions, with required fields and reusable templates.
- First release adds currency, dates, URLs, repeating rows, conditional logic, preview, per-section assignees and delegation.
- Seven tracked states, from Draft to Complete or Expired; reminders go only for outstanding items.
- Publishing a revised template never changes the questions in a request already sent.
Planned feature: not in Delsivo yet, and details may change before it ships.
What a founder information request replaces
After a first look, most funds email founders a list of questions and a request for files. Answers come back in replies, attachments and a shared folder, and someone copies them into a spreadsheet. Founders get asked for the same figure twice because the first answer is buried in a thread.
In Delsivo the request lives on the deal. The founder answers in their workspace on your branded portal, can save a draft, and can explain why an item is missing instead of leaving it blank. Your analyst sees each answer in one place, next to the question it answers.
Templates to start from
Edit any template or build your own. Questions from Unknown criteria in the thesis fit report can be added in one step.
- Revenue quality: recurring revenue, currency, paying accounts, contract start dates.
- Product: roadmap, technical architecture, key dependencies.
- Security: data handled, access controls, past incidents.
- Customers: customer list, references, churn.
- Cap table: current ownership and outstanding instruments.
- Legal: incorporation, IP assignment, material contracts.
- Follow-up: open questions from screening or the interview.
Pilot and first release, field by field
| Capability | Pilot | First release |
|---|---|---|
| Text, number, select and file questions | Yes | Yes |
| Required fields | Yes | Yes |
| Reusable templates | Yes | Yes, versioned |
| Currency, dates and URLs | No | Yes |
| Repeating rows, such as one row per customer | No | Yes |
| Conditional logic | No | Yes, checked on the server too |
| Preview before sending | No | Yes |
| Per-section assignees and delegation | No | Yes |
| Per-item reminders and partial submission | No | Yes |
An example of conditional logic planned for the first release: if a founder says customers prepay annually, the form asks how that revenue is recognised.
Sending a request and tracking it
- 1Start from the deal, from a claim that needs evidence, or from a checklist.
- 2Pick a template or questions, the recipients and a due date.
- 3Write or approve the message. Nothing goes to a founder without a person approving it.
- 4The founder answers in their workspace, saving drafts as they go, and submits.
- 5Your analyst reviews each answer, accepts it or asks for changes on that item.
States: Draft, Sent, In progress, Submitted, Changes requested, Complete and Expired. Reminders go only for items still outstanding, and stop once an item is complete. A revoked link stops working, and retrying a send never sends a duplicate invitation.
How answers feed the deal
An answer that supports or contradicts a claim can be linked to it on the startup claims tracker. File questions go into scoped upload slots, covered on secure file requests. In the first release, approved answers can also be mapped to deal fields, with a review step before anything is overwritten, and a revised answer creates a new version while keeping the original.