# Spectech CRM The point of a CRM is to keep track of a large number of people. Effectively it’s a system for defeating [[Dunbar’s Number]]. It’s helpful when achieving a goal depends on interacting with an unbounded number of people in a non-deterministic process. Professionally, the classic example is sales, but also includes hiring and fundraising. At Spectech, that also extends to program design — you need to talk to a lot of people to find potential performers, specific problem statements, potential customers. CRM tools are not magic: they encode a process and ideally make it more efficient. They also always require a lot of work no matter how good they are, ==need to expand on this== so they need to be addressing a core part of your role. (This is why most people fail at personal CRMs or CRMs for dating). Let’s start with what a process might look like if you had infinite time and could only use paper. You’d probably have a folder for each person that you would go through each day and decide whether or not you needed to take any action on that person that day. These folders would probably have a piece of paper that tells you relatively static things about a person — how to get in touch with them, where they are physically so you can have in-person meetings, what organization they work for. You would probably update the folder with a date and notes every time you interacted with that person and update any other information that needed to be updated. That’s about it. However, going through every person every day to decide who to act on would probably not leave any time for actually interacting with people. What are some straightforward things you could do to make your job easier? One straightforward thing would be to group folders in different ways: One straightforward thing would be to group folders by which organization someone works for. There are several reasons for this: you want to compare notes between people at the same organization, you don’t want to say redundant or contradictory things to people at the same org (they probably talk to each other), only certain people at an organization can make a decision on its behalf, and to some extent, we sign contracts with organizations, not individuals. Another way to group folders is by specific agreements you’re driving towards. The reason for this is that these are the ultimate goal of the CRM so it’s important to keep them front of mind. Not everybody at an organization is going to be involved in every deal with that organization and you could potentially have multiple deals per organization. In both organizations and deals, you might want to keep notes about the entities *themselves.* Maybe you’d create a filing cabinet specifically for organizations or deals that has folders that then have the people folders in them along with other pieces of paper. This quickly become problematic because you then must decide — do you put people into an organization filing cabinet or a deal filing cabinet? What about people who you want to keep track of but don’t have an organization or deal associated with them? One solution to this would be to create separate person, organization, and deal filing cabinets and just put a piece of paper with the persons name in appropriate organizations and deals. You could also put pieces of paper with the organization and deals a person is involved with in their folder. You still need to make sure you update all the references when something changes, but this system with three separate entities helps you quickly know what the relevant other entities are depending on your priorities for the day. Want to know why a deal has stalled? Look and see who you should reach out to. Want to know something about a person? Look at the other people in their organization. Etc. There are many other ways that you might want to group entities to make your life easier. We could use this same reference system of filing cabinets with folders that have pieces of papers that reference an entity to create other groups. One important grouping might be what action you need to take next. This should probably refer to people, that way you can go and say “ok who are all the people I need to email?” And just do it. Another important grouping is related to how to interact with both people and organizations. You generally want one pipeline per type of ask. The tricky thing is that people could go into multiples. Entities can be in different stages based on what has happened in the past. It’s probably a good idea to have moving between stages correspond to some kind of change in the relationship. This raises a couple of questions: * Does there need to be a 1:1 correspondence between state and next action? * I suspect the answer is no — * Pipelines imply that people should only ever move to a state farther down the pipeline. Is this the case? * I suspect the answer is also no — as long as a state change corresponds to an update in how you think about the relationship. ## Spectech Specific Things ### Thinking about pipelines * There’s a pipeline of recruiting for the org — the question is whether there’s a separate pipeline for performers. On the one hand, performers are often great PMs and vice versa. On the other hand, it’s a very different *end* state, so probably. * Pipeline of performers. * Pipeline of technology end consumers. * There’s a pipeline of funding for the org. ### Funding Pipeline On the people front I chose to keep married couples as the same entry #### Funding stages for people * No contact * Reached out * Conversation set * Connecting (this is the stage where someone is on board but isn’t a decision maker) * Qualified (for people who can actually make a decision) * Keep Warm * Closed What are the different “states” that I find *people* in? * A situation where I still need to talk to the person * Actions: * Find email address * Get warm intro * Send email * A situation where I have talked to the person * Situation where you have sent material or an ask and are waiting for an action. #### Funding stages for orgs * No contact * Reached out * Conversation set * Qualified * Proposal sent * Negotiating * Keep Warm * Note the next action (How do you deal with “no for now” people/orgs #### Funding stages for deals * Conversation * Proposal sent * Closed #### Categories of Funding Organizations * Consortium members * Foundation * Donors family offices * Investor family offices #### Categories of Funding Individuals * HNWI without org * HNWI with org * HNWI investor * Works at potential consortium members * Donor at big foundation * Donor at family office * Investor at family office * Connector ### End consumer pipeline #### Categories * Potential technology “customers” but are too small to be consortium members ### Recruiting Pipeline #### Stages 1. Potential 2. Expressed interest 3. In conversation 4. Hired 5. Keep warm 6. Rejected 7. Dropped off ### Things you want to keep track of * When there is a person you need to find an email or warm intro to * Whether a person is a decision maker or not * Check sizes * Streak seems awkward — have to do a lot of bookeeping * Mostly just want to have a way for people to have visibility into who has contacted whom * [[Martin Permin]] says he uses close.io — it’s 7/10