Building an investor follow up system

The call ended at 2:40, and by 2:41 the system had logged it, moved the contact to the stage the call earned, scheduled the next message for the following Tuesday, and attached the version of the summary document that had been sent that morning. None of that required me. That is the point of a follow up system, and this article describes how one is put together at the level of architecture rather than at the level of any product. I built the one I use on a commercial platform with custom configuration, and the design below is what I would build again on anything.

Two boundaries before the design. This system is not a solicitation tool, and nothing in it decides whom to contact based on what kind of investor someone is. It runs after a conversation has happened, for people who have already engaged, and its job is to make sure nothing that was promised is forgotten. And it does not replace judgment about what to say. It replaces the memory of what was said.

The contact store and its schema

At the base is a store of contacts, and its schema, fixed on day one, decides which questions the system will ever be able to answer. The minimum I insist on: identity fields, the source of the contact, the stage, the date the stage last changed, the owner on our side, and a free text log. Beyond the minimum, a small number of structured fields that the later questions will need, such as the date of the last conversation and the next action due.

The mistake in one direction is a schema so thin that the only way to know what happened is to read the log. The mistake in the other direction is a schema with so many fields that people stop filling them in truthfully. I have made both. The rule I settled on is that a field earns its place when someone can name the report that will use it.

Stages defined by actions

A pipeline stage is a claim about where a relationship is, and the claim has to be checkable by someone who was not on the call. So every stage in the system is tied to something the other party did: asked for the document, opened the data room, sent a question in writing, returned a signed form. If a stage rests on the mood of a call instead, nobody else can review it, nothing can be automated against it, and it drifts upward as optimism does.

The stage engine is small. It holds the list of stages, the action that moves a contact into each one, and the follow up policy for each stage: what goes out, when, and what stops it. When an action is recorded, the engine moves the stage and schedules the policy. When a person on our side overrides it, the override is logged with a reason.

The sequencing layer

The sequencer sends messages on a schedule set by stage. A sequence is a list of messages with intervals, and each message is written to stand on its own, because most recipients will not read all of them. The sequence is paused by any reply and by any recorded action, so that a person who has just written to us does not receive an automated message that ignores what they said. Resumption is a human decision.

Two design rules matter here. Every message in a sequence is consistent with the documents the person has received, because a message is a statement the firm has made. And every send is logged with the message version, so that the question of what a given person was told has an answer.

The calling layer

Calls are placed and received through a layer that logs each one against the contact: time, duration, outcome, and a note. What limits an outreach effort is seldom how many calls get placed. It is what happens in the sixty seconds after somebody answers, so the calling layer’s real job is to make the post call actions fast. A call ends, the outcome is chosen from a short list, the stage moves if the outcome earns it, and the next action is scheduled. If that takes more than a minute, people stop doing it, and the record decays.

Recording of calls, where used, follows the consent rules of every jurisdiction involved, and the policy is written down before the first call is placed.

The document and version record

This is the part most systems lack and the part I consider mandatory. Every document sent to a contact is logged with its version identifier, the date, and the channel. When a document is revised, the new version gets a new identifier, and the log makes it possible to answer, for any person, which version they saw and when. In private capital the operative question about a document is rarely what it says today. It is what it said when a particular reader read it.

The implementation is not complicated. A document register with versions, a link from each send event to a version, and a report that lists versions by contact. What is hard is the discipline of never sending a document outside the system.

What a contact sees from the other side

It helps to design the system from the recipient’s chair. A person who had one conversation with the firm and asked for a summary document should receive that document, once, in the version current that day, with a short message that reads as if a person wrote it, because a person did. If they reply, the automated sequence stops and a human answers. If they do not reply, they receive a small number of further messages, spaced to the pace of the decision rather than to the impatience of the sender, and each one makes sense on its own for a reader who did not see the others. At any point a request to stop is honored immediately and recorded. Nothing in that experience is a pitch, nothing asks for a commitment, and nothing depends on what kind of investor the person is. The system exists so that the firm keeps its side of a conversation it already had. When I review the sequences, the test I apply is whether I would be comfortable receiving each message myself, from a firm I had spoken to once.

Reporting and review

The system produces a weekly review: stage counts, movements in and out of each stage, actions overdue, sequences paused awaiting a human, and calls logged with no outcome. The last two are the health checks. A growing count of paused sequences means people are replying and nobody is answering. A growing count of calls without outcomes means the post call step has become too slow.

The automation boundary

The boundary between what the system does and what a person does falls where a step stops carrying judgment. Logging, scheduling, sending a message that was written in advance, moving a stage on a recorded action: those are mechanical. Deciding what to say to a specific question, deciding whether a relationship is stalled or merely slow, deciding to override a stage: those are not, and the system routes them to a person. Most automation disappointments I have seen were boundary errors rather than tool errors, and the boundary moves as the process matures, so it is redrawn deliberately.

The honest limit

The first thing a system like this returns is clarity, and speed comes second. To build it the process had to be written down precisely enough for software to run it, and that writing exposed steps nobody had agreed on. The ongoing cost is maintenance. Software you wrote yourself, or configured yourself, is software you have to keep, and an internal tool has no outside users to notice when it drifts. I accept that cost because the alternative is a process that lives in one person’s memory, and memory is the thing this whole system exists to replace.

Educational content only. Not legal, tax, or investment advice, and not an offer to sell or a solicitation of an offer to buy any security.