IVP CRM: Prototype Scope

What they have today

One spreadsheet, labelled CRM, created this spring. Bethany: It's a new spreadsheet, and it's labeled CRM, so it is the CRM. Eight years into the business, it is their first attempt at a central customer list.

~600 active accounts, where active means anyone who purchased in 2026.
A year-over-year up/down flag per account, hand-built by their data analyst in Excel.
A pipeline tab that is empty, created this month, never populated.
No connection to actual customer data. No activity log, no notes, no touchpoint history.
Rep-per-account is not filled in. Alex named himself the bottleneck on this.

The real problem is not the spreadsheet. It is that IVP cannot predict sales. Bethany: in addition to growing sales, a thing we really do need to tighten up is just our ability to predict sales and to predict who will buy. Anything the prototype does should be judged against that, not against feature count.

The one hard idea: two views of the same data

This is the spine of the build and the thing a generic CRM does badly. IVP think in accounts but publish in books, and they need to move in both directions.

Account view

Who they are, what they have bought, how warm they are, when we last touched them, are they up or down year over year. Bethany: 95% of the time about accounts, not the books themselves.

Book view

Start from a title and work outward: which accounts should buy it, which did, what activity drove the sales. ~120 new books a year. Bethany's post-mortem case: we thought this book was going to be right for this account, but it's actually not.

The prototype has to demonstrate the pivot between them convincingly, because that is the capability they cannot get off the shelf.

Account descriptors: the matching layer

The mechanism behind book-to-account matching. Alex and Bethany both described tagging accounts by character: denomination, theological leaning, homeschool and classical Christian education, academic, digital, and so on.

Bethany's use case is at proposal stage, before a book exists: this book would be great for this kind of person, are we currently talking to that kind of person? If yes, the sale is half done. If no, that is a named gap.

Prototype should show: pick a forthcoming title, filter accounts by descriptor, get a ranked target list with warmth and last-contact. That single interaction carries most of the value in the room.

Pipelines: plural, and they roll up

Alex asked for lead warmth and estimated value so they get as accurate as we can, projection of what's coming. Bethany confirmed the shape: with the multiple pipelines, you can, we can roll the whole thing up, right, into reports.

Pipeline	Behaves like	Why separate
Trade / retail	Standard opportunity pipeline	Alex's range: everything from Christian book … all the way down to my grandmother's small group who wants to buy 12 Bible groups.
Academic: libraries	Standard pipeline	Direct orders, sales attach cleanly. Alex: fold into the general pipeline.
Academic: professors	Activity tracker that can convert to an opportunity	Both happen. Most adoptions are indirect via Follett, campus stores and e-book platforms with no attributable order (Alex: not in a direct and measurable way 99% of the time) but direct classroom orders do occur. He still needs the cadence either way: am I hitting them too much?

The actual mechanic, per Ryan: outreach to professors is direct (IVP contacts them) but the resulting orders arrive through Follett. So the two halves of the same sale land in different places and nothing joins them today. The valuable feature is the bridge: let a rep tie direct outreach to the Follett volume that follows, by title and campus, so the question "did contacting this professor do anything?" finally has an answer. That is the academic equivalent of the book-level post-mortem Bethany asked for, and it is worth prototyping even in fake data.

Professors are activity-first, opportunity-when-real. Corrected by Ryan after the first draft of this scope, and Alex's own 99% of the time supports it: the default record is outreach and desk-copy activity, with the ability to raise a direct opportunity on the occasions a professor actually places a classroom order. What must not happen is every professor contact being born as a forecastable opportunity. That inflates the pipeline with revenue that mostly arrives, if at all, through a distributor nobody attributed. Report indirect adoption separately and aggregate distributor sales beside it.

Workflow mode

Carried over from the Thank You Writer, which is what got IVP into the room. One record at a time, one big button, no spreadsheet, no data entry by the rep: the system captures the activity as a by-product of doing the work. Use it for high-volume outreach: professor mailings, segmented email sends, call-downs.

Longleaf Services: the biggest time sink

Their third-party distributor. Alex on the current process: it's a very manual process that we did not realize would be as manual when we moved to Longleaf … it takes up a ton of time. He learns of orders from a daily report, chases status by email, and Longleaf's replies arrive as new threads outside the chain.

Bethany confirmed the feed: what we actually get every night is a list of transactions, and account numbers are on the transaction data, which is the join key to their account list.

Prototype should show: order status (placed, pending, paid, shipped) sitting on the account page, so a rep answers a customer without leaving the tool. Ryan's framing: it strengthens the IVP relationship when IVP answers instead of redirecting to Longleaf. She also said they are not limited in what data Longleaf can give them, so scope this on what is useful rather than on what is currently emailed.

Explicitly out of the prototype

It does not have to work. Ryan on the call: fake data, real look and feel, let you play with it … poke around and actually give feedback. The purpose is to provoke correction, not to be adopted.
No live Longleaf connection. Show the surface using their transaction-header structure; the integration is a later decision.
No real customer data. See below.
No email sending. Mail-merge and send-throttling were discussed as future capability; showing composition is enough.

Data we need from them

A copy of the CRM spreadsheet, customer data stripped: structure and column names only.
A data dump of Longleaf transaction headers. Bethany offered this unprompted so we can see the real shape.
The account-descriptor vocabulary they actually want, if it exists anywhere yet. If it does not, that is a workshop, and worth naming as one.

Handling rule, non-negotiable. Bethany offered a data dump and Ryan said he would strip customer data. Until it is verified stripped, treat any file they send as containing real customer records: it does not go into the prototype, into a repo, into a chat, or anywhere a link could be shared. The prototype runs on generated data that resembles theirs.

Open questions worth asking before building

Who is the prototype's primary user: Bethany's strategic view, Alex's day-to-day rep view, or the new hire they are recruiting now? They are different first screens.
Does rep-per-account get assigned in the tool, or does it arrive already filled in? Alex called this his current bottleneck; the tool could remove it or inherit it.
Which distributors need aggregating beside Longleaf? Christian Book, Follett and Grand Canyon e-books were all named in passing.
How is "active account" maintained after 2026: rolling twelve months, or a fiscal reset? Their whole list is defined by it.

Addendum: source data received (Aug 26)

Two files arrived from Bethany this afternoon: a structure-only copy of their live CRM spreadsheet, and a month of real transaction data pulled from their Qlik BI system. Together they let us stop guessing at shape and start building against the real thing.

Sales_CRM.xlsx: the CRM, structure only, no data

Six sheets: CRM, Sales Leads, FY27 Account Sales, FY26, FY25, and an empty Dashboard tab. Every row is blank; only the column headers came across.

CRM sheet, 17 columns

LL Account Number, Account, Sales Rep, Workday Cost Center, Category, Contact Name, Phone/Email, Notes, Last Purchase, FY27 YTD, FY26 YTD, Change %, Affiliation - Sub 1, Affiliation - Sub 2, Affiliation - Sub 3, Affiliation - Sub 4, Seasonal Catalog Presentations.

The Sales Leads sheet carries nearly the same account fields plus four additions that turn a row into an opportunity: Strength of Lead, Estimated Revenue, Estimated Date, Type of Sale. This is the pipeline tab Bethany said was created and never populated, now with the columns to populate it.

The FY25, FY26 and FY27 Account Sales sheets are monthly account-by-account sales grids, one column per month plus a YTD Total and a year-over-year comparison column, the hand-built up/down flag Bethany described, now visible as its own structure.

Qlik_Data.xlsx: one month of real transaction line items

27,276 rows by 110 columns, one Sheet1, straight out of their Qlik BI export. Invoice and credit lines keyed by Customer Number, one row per item per document: item ID, description, series and author; quantities ordered, delivered, in-progress, backordered and outstanding; list price and actual sales price; sales amount, cost of goods, sales tax and discount rates; sales rep ID and description with commission percent and amount; document type, line type, source of order, warehouse and stock-on-hand fields; and an item-level hierarchy four levels deep.

Handled as PII, not as sample data. IVP partially scrubbed the export before sending it: delivery address, billing address and email columns came through empty, but the customer-name column is populated on all 27,276 rows, and one delivery-address line still carries text on every row. That means this file contains real customer records. It stays inside our environment, it does not go into a repo, a chat or the prototype, and no name, address or email from it appears on this page or anywhere else outside the source file. Demo data is synthesized to match its shape, not sampled from it.

What it proves. These are the two unjoined halves the scope above describes: the CRM sheet is the outreach half, Qlik is the fulfillment half, and nothing joins them today. The join key exists in both files right now: Customer Number in Qlik matches LL Account Number in the CRM sheet. The bridge this scope calls the most valuable feature in the room is buildable from day one, on real keys, not a future integration.

Ryan's answers, Aug 26: resolved design inputs

Per-rep logins. Ryan: we need the CRM to be able to be used by all their sales people, maybe based on their login is what they see. What a rep sees is scoped to their own book, not the whole account list.
Rep assignment. Ryan: I'm going to guess the tool will both inherit rep assignments and will need to be able to be changed. The tool loads the CRM sheet's existing Sales Rep column and lets a rep or admin reassign an account inside it.
Amazon as a channel. Ryan: Amazon too maybe? Alongside Follett, as another indirect fulfillment channel to aggregate beside direct outreach.
FY sheets are a fiscal reset. Ryan: from the crm, i think its a fiscal reset. YTD rolls forward from July 1 each year rather than a rolling twelve months, which answers the open question above about how "active account" is maintained.

Next step. A working demo is being specced and built now: synthesized data shaped to match these two files, five screens, with the CRM-to-Qlik bridge as the centerpiece.