Startup application management, from form to onboarding

Collecting applications is the easy part. Any form tool does it. The work begins the moment the applications are in.

You need to know which of eighty applications are missing a document, and which document. You need to know who moved an application to shortlisted, and when. You need to ask an applicant to correct a section without resetting the whole submission. And next year, you need to run the same program again without rebuilding the form from scratch.

That is the difference between a form and application management.

Application forms are assembled from eight question types, drawing on a reusable question bank. The twenty questions you ask on every program are written once and reused, and the handful that are specific to a particular scheme are added on top.

This matters more than it sounds. Most incubators rebuild substantially the same form for every cohort, which is both slow and the reason data from different cohorts cannot be compared.

An application is not either open or closed. It is new, reviewed, under evaluation, evaluated, verified and onboarded - or rejected at any of those points, for a reason someone will ask about later.

It moves one phase at a time, and every move is recorded with the person who made it and the timestamp. What the startup still owes - a change, a document - is shown beside the phase rather than replacing it, so an application can be under evaluation and still owe a certificate, and a list can tell 'waiting on them' from 'waiting on us'. That record is the difference between knowing where an application is and remembering roughly where it was.

Two loops consume most of the administrative time in an application cycle: asking for a document that was not attached, and asking an applicant to correct something they filled in wrongly.

Both are first-class here. A document request is a tracked object with a state, so the outstanding list is a query rather than a search through your sent folder. A change request asks the applicant to revise a specific part of their submission, and carries its own approve, reject and re-request states - so a correction does not mean starting the application again.

Requests can also be issued in bulk, which is what you want when a whole cohort is missing the same certificate.

The same loop reaches startups that never applied - one brought in from your records, or one whose founder confirmed a link. They are asked on their company profile, answer there, and you approve the file or ask for a new one with a reason. A document matrix shows which startup has sent which kind of document, and all the files of one kind download together.

A programme's Registrations tab also opens as a sheet: one row per application, with its status, who the next step is waiting on, what the startup still owes, and when it was submitted.

Beside each row your team keeps a note, a follow-up date and who is handling it, plus any columns of your own. Status is not typed into a cell - it changes on the application, where its rules run and the founder is told. Save tabs such as 'waiting on your team', and export any of them to Excel for a committee.

The point of managing applications properly is that nothing has to be re-entered afterwards.

An accepted application becomes a startup in a batch. Its evaluation record, documents and history stay attached. From there the same profile carries funding requests and disbursements, task boards, office allocation, facility bookings, mentorship associations and data collection responses.

Because the startup is also a profile on the ecosystem network, an applicant you accept is already visible to mentors and investors rather than being a row in your database.