Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Toggle for the table of contents

...

Info

This document is a glossary, not a book.

...

Please do not see this lengthy document as required reading.

...

Other - People that we want to track comms with but aren’t sales Contacts. These are investors, media & publishing partners, vendors, etc.

Sources

...

❗Original Source

This is maybe one of the most important fields. The fields are rather self explanatory and auto-populated in most cases, so this is just a reference.

...

This helps us differentiate which business unit the Contact came in from. 🚧 This name might be a little confusing with Original, but we’ll leave it for now.

⚠️ Adoptions

Note

...

Under construction. We have fields for “Annual Adoptions” that is single line text and “Yearly Adoptions” that’s a drop-down select for form intake. Adoptions aren’t conducted by a person but rather via their organization (Company) or the estimate for their contract (Deal).

...

⚠️ Currently, we have fields for “Annual Adoptions” that is single line text and “Yearly Adoptions” that’s a drop-down select for form intake. Adoptions aren’t conducted by a person but rather as a function of their organization (Company) or the estimate for their contract (Deal), and I think we should shy away from relying on user-submitted text in either of these fields for the source of truth for adoptions.

Hubspot Score

Note

...

Under construction until we have better understanding of what factors influence lead quality.

...

Contact Type

This field denotes how the contact engages with us.

...

Type - Same format as Contact Type

Animal Shelter Software - What shelter management software are they currently using?

...

Deals are records that roll up all communications with attached Contacts and Companies specific to the transitory engagement of a contract. Deals have start and end dates and contain fields that apply to all associated Contacts and Companies but may not be permanent or intrinsic traits.

Pipelines

Note

...

Under construction: We have too many pipelines doing too many things with too many stages. Need to simplify before we can build.

...

Overarching principles:

  • While pipelines are displayed in a Kanban-style, they’re not Kanban boards. In an isolated environment, this is fine. As we grow, it requires that we violate a key principle

  • CRMs sing when each field is dedicated to a single variable. “Deal Stage” as a variable works best when it exclusively points to the progress of a lead. Using pipelines for post-sales activity will…

    • Overwrite a Contact & Company’s Lifecycle Stage field, which is a top-5 field and super important for post-sale nurturing and re-engagement of churned customers.

    • Impact pipeline and forecasting, as many default Hubspot reports look at how much revenue is in the funnel. To retain this functionality, we’d have to do a lot of additional workflows and documentation that could get messy as we grow.

...

  • Process - Features - The Deal closed because of the features we offered.

  • Process - Ease of Use - The Deal closed because of our user experience and how smooth our product or experience is.

  • Process - Service - The Deal closed because they loved our service & support or their relationship with the salesperson or customer success manager.

  • Financial - Pricing - The Deal closed based on how our pricing compared to competitors or in-house solutions.

  • Financial - Donations & Revenue - The Deal closed based on the donations or revenue generated by their use of shelter management software.

  • Financial - Budget - The Deal closed because of their budget timelines and ability to spend.

  • Social - Organization - The Deal closed due to affinity or social pressure from how the Deal Contacts relate to us via a professional or social organization.

  • Social - Other - The Deal closed because of how the prospect feels about our position in the industry, our values, and what working with us means for issues the prospect cares about.

Note

...

Note: Reasons might need supplementary notes. Like, if a person buys based on Features, what specific features do they like? Better to keep Reason as general but then document the specifics somewhere.

...

Contract Start Date / Launch Date

...

  1. People who requested a demo but haven’t been worked by a rep since the CRM migration: Demo request date is: known, Contact owner is: unassigned. Note that this demo request date field is very outdated.

🦝 RC Changelog

Notes

Pipelines

Consolidating pipelines is the first step to getting some clarity in the model

Current pipelines:

  1. Sales Pipeline

    1. Keep this, rename to ShelterBuddy Sales, reduce stages, standardize fields.

  2. Adopets Sales Pipeline

    1. Keep this, just reduce the number of stages and standardize fields.

  3. Customer Success

  4. Adopets BFAS Leads Pipeline [List, delete]

  5. Adopets Customer Success [Export, delete]

  6. New Customer Onboarding [This should be ChurnZero or automated, not a pipeline]

  7. Partner Pipeline [Only to track vendors and integrators. Delete it.]

  8. Adopets Onboarding Flow [This should be automated, not a pipeline]

  9. Adopets Partner Opportunities [This is a Contacts or Companies static list, not a pipeline]

  10. Client Offboarding [This is a checklist, not a pipeline]

Are Adopets and Shelterbuddy products in the new system, or are they entirely different sales processes? How often do people buy just one versus buying both?

Sales Process

Right now, salespeople are expected to manually enter

  1. Deal Notes

  2. Priority (3% compliance)

  3. Decision Makers Engaged (0% compliance)

  4. Add Associated Contacts to Deal (100% compliance)

  5. Shelter Focus Areas (0% compliance)

  6. Close Date (7% compliance)

  7. Deal Amount (92% compliance)

  8. Product Subscriptions (0% Compliance)

  9. Product Needs (2% compliance)

  10. Go-Live goal (0% compliance)

  11. Shelter Software (0% compliance)

It’s important for a salesperson to know all of this, but with all of these manual entry fields, it’s going to be very difficult to ensure 90%+ compliance on these.

It’s better to automate some of these (Close Date, Decision Makers Engaged, Deal Notes, Shelter Software), push some of these to later in the sale (when Contract Sent, update Deal Amount and Go Live Date), and simply surrender some of these (Product Subscriptions and Goals are synonymous with Closed Reason).

Overall defining notes for all objects:

  1. Properties are static information that is meant to be searched, parsed, filtered, and reported on. In many cases, we’re using them as sticky notes to document something about a Contact. In our current state, this is only a hygienic issue, but it’s important to have an understanding of how these fields work to empower our team members to use the CRM versus treat it as a complicated spreadsheet.

  2. Understanding the difference between Contact and Company objects. We have a lot of fields under Contacts that aren’t specific to that person, but rather to their Company. This creates a ton of redundant data entry, inconsistent things (what if there’s conflicting info?), missed opportunities (what if we’re emailing sub-500 shelters and the POC was manually created and the field is blank, and the person who filled out the form who is no longer there has the info? The POC won’t get the email). Likewise, understanding objects gives a layer of understanding to team members to feel empowered by the CRM.

Sales & Deals

Defining Deal Characteristics:

  1. Each funnel is speaking a different language.

  2. Many funnels are being used incorrectly because our non-technical team members like the visual, kanban-style display of these Deals.

  • [x] Consolidate Pipelines: Customer Success, Sales. One each, then one per business unit.

  • [ ] The Priority Deal field seems like something that should be dynamic based on Deal properties, not something we manually set.

  • [x] Customer Commitment also feels like something that’s not a good use of manual data entry. This should probably be captured in the Deal Notes on the discovery call or by gauging sentiment from a form field.

  • [x] Go Live Goal field should probably be the anticipated Close Date, right? Or maybe “Contract Start Date” (new field)?

  • [x] Go Live Goal and Go Live Date are the same thing. (note: Go Live is Adopets Launch, Go Live for ShelterBuddy is Contract Start Date)

  • [x] Decision Makers Engaged is too dynamic to be kept up in a busy sales environment. If I’m a salesperson with 30 active deals in my funnel, I am bouncing emails and conducting calls everyday that would change this field. My recommendation would be to lean on the salespeople to accurately add the correct Contacts to the Deal and then infer the roles based on tight compliance in the Contacts section.

  • [ ] Customer Health Score is a good thing to track, but again, should be automated. What conditions make them at-risk? Plug those in as filter into an active list and then send notifications to the Company owner when a customer is auto-added to the list

  • [x] Shelter Software should be a drop-down, not open text (There’s a drop down - keep that one and delete this one)

  • [x] Product Needs is too general to be a field; just toss this into templated Deal Notes (to add later)

  • [x] Consider adding an Associated Contact Engage Date when we get inbound marketing set up.

  • [x] Audit the default fields, try to reduce them or break them into sections to reduce the emotional burden of them.

  • [x] Is Close Date the same as Contract Start Date? Or can we have a Contract Start and Contract End Date field that removes the need for the Customer Success Pipeline?

  • [ ] “Contract Sent to Andre” is a foul play in fields. They should be as general as possible, definitely don’t entrench a proper noun or person’s name into a field. Also, “Contract Sent” is a Deal Stage, not a field.

  • [ ] “Contract Info” as a Yes/No field doesn’t make sense to me. Does it mean that it’s been sent? This is a deal stage.

Pipeline-Specific Recommendations

  • [ ] The Customer Success Pipeline is a list of customers denominated by when they joined. This could be a Deal Filter with contract dates or perfect Launch Date, where offboarding checklist includes putting in their end date in the contract.

  • [x] It appears that the Adopets customer success pipeline is merely a check-in schedule. I’m massively in favor of this (proactive success versus reactive check-in), but I’d contend that we can isolate this by Contract Start/End Date, CS Check-In Schedule (new field), and Last Contacted Date.

  • [x] Demo Complete Stage and Qualified to Buy are the same. If they complete the demo and aren’t qualified, just lose the deal.

  • [ ] If sending a quote is the automatic next stage after a buyer is qualified, then this is also unnecessary. “Demo Complete” implies the quote is sent. Better to automatically create a Task when a Deal is moved into Demo Complete and stay accountable to being on top of tasks.

  • [x] Is “Awaiting Contract Award” the same as Contract Sent?

  • [x] Verbal Win is the same thing as decision maker bought in. Delete this.

  • [ ] Closed Won is the same thing as Send to Onboarding. That’s what you do when you win a new customer. (onboarding often takes place pre-contracting; these are likely separate activities all placed into one pipeline)

  • [x] Bad Timing is just a Lost Reason, not a Deal Stage. Lose the Deal, create a Task to follow up, and quarterly review Lost Deals by Reason and see if there’s value in there.

  • [x] SBI Lost and Closed Lost are the same thing.

  • [x] Pushed Deal Amount into Yearly Adoptions. This paves the way to get Deal Amount back to being a Deal Amount.

Contacts

  • [ ] I’m guessing “Annual Intake” is referencing animal intake. This is a single line text field (not number) and is honestly a Company field. People don’t take in animals, organizations do.

  • [x] Annual Adoptions, same. It’s totally possible that it would be hard to put this number in the Company from a Contact Form, but we should look into it. Also it has to be a number field and not single line text. Migrated to Company input but not deleted as a Contact field yet.

  • [ ] Attended reception is a Note, a List, or a “Zoom Meeting Attended” auto-populated field and shouldn’t be manually maintained in a Contact record.

  • [ ] BFAS Adopets Interest should probably be a Source for a form they filled out or a static list that’s maintained by a salesperson, not an intrinsic quality of the Contact.

  • [ ] Demo Request Date shouldn’t be single line text and should be automatically stored by their Form data.

  • [ ] Event Attendance, same as “Attended reception” and “Demo Request Date” - their activity is automatically logged so this isn’t a static field.

    • [ ] There are 2 redundant Event Attendance fields

  • [ ] All of the Areas of Need aren’t good uses of fields

  • [ ] I generally don’t like personas in small companies. Once we have a full-time sales manager and CRM admin, worth revisiting.

  • [x] What’s Origin? Origin Form, and contains form data that was lost in the migration or in the Hubspot script not being connected. It shall live.

  • [x] Market Segment is just a filter on top of info we already have (number of adoptions); which should probably be a Company field 🙂

  • [x] Lost / Churn Shelter Software probably isn’t a good Contact field, but I need context. Only has 2 records, so archived.

  • [ ] Shelter Software is OK as Contact, but probably should be a Company field.

  • [x] Identify if incoming leads are from the Adopets or ShelterBuddy. Figure out how to capture this as overall, most recent, etc.

  • [ ] Persona Other is actually a great field, but it should not be single-line text.

  • [ ] Job Position feels like it should be contained in Job Title, unless we foresee campaigns where we specifically target people based on degrees of responsibility. This might be OK to keep, but feels too error-prone to rely on.

  • [x] Organization Logo got toasted.

  • [x] Merge Organization Name and Create name - they’re the same thing

Company

The main issue here is that we don’t use Companies, and that’s not that bad.

  • [ ] How much does Industry vary with us? Can we create our own items for this or just remove it from the default view?

  • [ ] We ask the Contact to tell us what country they’re in, but that’s really a Company field. I don’t think City, State, or Postal Code is an appropriate default

  • [x] Remove location info from Company default properties, added Country (as that’s part of the lead form)

...

This is retained in Notion, but is too lengthy for this document.