Before your next customer conversation, which detail would you check—and where would you find it?
The account summary may be in your customer system, the latest detail in a document, and a promise in a chat thread. Finding each piece still leaves a question: what can you rely on for your next step?
That is the question behind my SalesWiki research. I am exploring a shared knowledge base for sales and marketing: linked account context, different access for different roles, and answers that show their sources and gaps. The aim is to spend less effort rebuilding context so people have more room to think through the decision.
In Part 4, I looked at what must change before a demo uses real customer data. This final part follows one example through a check, then asks when connecting another tool would help. No technical background is needed.
Before contacting Atlas Foods
Atlas Foods is an invented account in the demo, not a customer case. Its account summary was last reviewed on August 12. A call note is dated August 18, and an audit source August 21. Both are newer than the summary.
The audit source says the team wants to reduce manual evidence gathering during each audit cycle. That could matter when preparing the conversation: ask which part of the audit takes the most effort, rather than starting with a general product pitch. It still does not tell us the customer's current evaluation date.
Current demo, cropped to the check and its dated sources. All account data is synthetic.
An old summary is not a reason to drop the account. A newer document is not automatically the full answer either. I would compare them, keep the useful history, and ask the account owner for the missing date before deciding how to follow up.
For marketing, the question might be different: which approved detail can support a useful message? The same account can help both teams, but each needs the facts relevant to its task and permitted for its role.
Getting an answer is different from changing the record
This is the distinction I want SalesWiki to make clear. Someone asking a question needs an answer they can check. Someone correcting the shared account context needs a review path.
The intended workflow in plain language. A proposed change is reviewed before it is applied; reading a source does not update a card.
The knowledge base holds the team's current understanding and links back to the evidence. It does not need to become another copy of every document, recording and customer system. Original sources stay intact. Account summaries and working conclusions can change through review, with a history of what changed and why.
The assistant's role is to bring the relevant, permitted context together and make gaps visible. It should not quietly fill in a missing date or decide that an account is no longer worth attention. The person makes that judgment.
A useful check can end with “we still don't know”
For this demonstration, I opened the audit source, then recorded “Could not verify” and “Ask for missing context.” The source explains a need, but it does not settle the current evaluation date. I left the effect on the next decision as “Cannot assess yet.”
An illustrative result I recorded in the synthetic demo. It records a next step, not a confirmed customer finding or an updated account card.
This gives the check an outcome: ask for the missing context, then return to the decision. Recording a result does not make the old account summary current. In the browser demo, these personal checks reset on reload and do not send reminders. A correction to the shared card has a separate approval path.
We also do not know why the account review fell behind. Perhaps a source changed, perhaps a review was missed; the dates alone cannot tell us. A later private pilot would need enough history to investigate recurring gaps without guessing their cause. The Government Data Quality Framework is a useful reference for tracking quality issues over time and addressing their causes. That is guidance for the research, not a claim that the demo diagnoses them automatically.
When would another connection earn its place?
Now the integration question is easier to answer. What missing fact would the connection supply, or where would it help someone use the answer?
For a sales follow-up, a connection to the customer system could supply an agreed next step and its date. For a campaign, a document connection could supply approved evidence for a message. A chat interface could bring the cited answer to a place where the team already works. These are examples to test, not live connections shipped by the demo.
I would start with one decision and one narrow connection. First read the needed information. If anything should change in the shared record, propose the exact change for review. Access rules still apply, and the original source remains available to check.
If the only benefit is “we can search more material,” I would first ask whether the team's existing search tools already do enough. A connection also brings work: permissions, failed updates, source checks and maintenance. That effort belongs in the evaluation.
Five lessons I am taking forward
Across the series, the idea has become more concrete:
- Keep account understanding connected. People should be able to follow an account, a conversation and the evidence behind a conclusion without rebuilding the story each time.
- Separate access from relevance. A role defines what someone may see; their task defines which of those facts help them decide.
- Keep dates and gaps visible. Old information can matter. Missing information should lead to a check, not a confident guess.
- Make corrections traceable. Preserve original evidence, review changes, and record the result.
- Connect tools for a reason. Supply a needed fact or bring an answer to the person who needs it. Count the ongoing effort as well as the benefit.
The demo shows how these steps can work together with invented data. It does not yet show that a real team will make better decisions or spend less time searching.
My next useful test would be one repeated decision alongside the team's current process: did the answer change the next step for a defensible reason? Did someone catch a missing fact before acting? Was the effort of checking and keeping the knowledge current worth it?
That is where I want the research to go. I hope to automate some of the work of finding and checking context, while leaving more space for the part that needs a person's judgment. The next version should follow what people find useful—even if that means a simpler tool is enough.
Try it or follow the series
Open the synthetic demo. Choose Atlas Foods, open “Check account context,” and inspect a source. Then ask: what would I need to know before taking the next step?
If you want to explore the implementation, the public repository and local setup guide are available. The demo is a research prototype; real customer use needs a separate private setup with real identity, access and review controls.
Continue the series
This five-part series explores how shared sales and marketing context can support decisions people can check.
- Why I built a sales and marketing knowledge base that refuses to guess
- How I keep shared sales knowledge safe for different roles
- What should a sales knowledge base help someone decide?
- What must change before a sales demo uses real data?
- When does an integration help a sales decision? — this part
Previous: Part 4
Which missing detail most often makes you stop and check before a customer conversation?
Top comments (0)