Next Win
An internal CRM for Next Win, with permissions in the database
Next Win is the agency CRM Force builds custom software with. For their own acquisition there was nothing: leads in spreadsheets, conversations in people's heads, and external callers working with personal data. It became an internal CRM where those parties work alongside each other without seeing each other's leads.
About Next Win
Next Win builds websites, webshops and business applications. CRM Force works with them structurally: they sit deep in the build side, we sit in Salesforce and in the design of the CRM process. For clients that means one team instead of two suppliers.
For its own acquisition, Next Win works with external call agencies. They call cold, book appointments and hand them over. We work in this system every day ourselves, so we are the first to notice where it chafes.
The challenge
Personal data of cold prospects sat in lists that went round by email. An external party working in those lists sees everything the file contains, and that cannot be undone once it has been sent.
It also had to work in practice. Two callers must not pick up the same lead at once, a colleague must be able to step in during illness without typing over someone else's conversation, and nobody from outside should be able to reach the agency's figures.
Why it did not become Salesforce
Salesforce was the obvious candidate. Leads, conversations and follow-up are exactly what Sales Cloud is built for, and the expertise was in house.
The number of users decided it. A small internal team plus a changing set of external callers, each with a licence per month, and configuration on top of that. For acquisition that still has to earn itself back, that is a fixed cost in the wrong place.
Something else played a part. The difference between who owns a lead and who may access it hangs on the agency here, not on the person. That can be rebuilt in a package with roles and sharing rules, but in a data model of your own it is two columns.
Read how we weigh that upThe approach
The boundary is the design, not a layer on top of it. A user's role and agency sit in the login token; the database policies read them there and decide per row what is visible.
Visibility hangs on the agency rather than on the person, so a second caller can step in without typing over a colleague's conversation.
What was built?
The parts that carry the system:
Leads and call status
Who was called, what came out of it and when to call back. It all sits with the lead, so a conversation does not stay stuck in somebody's calendar.
Chamber of Commerce check before calling
A link to the Dutch business register checks whether a number belongs to a legal entity. Cold calling private numbers is blocked before it happens rather than noticed afterwards.
Free leads you pick up
A lead without an owner is visible to everyone and is yours the moment you pick it up. If two callers click at once, the second is told somebody beat them to it. That is handled inside the database operation itself, not by a check beforehand.
Appointments and follow-up
Scheduled conversations, who is attending and what the outcome was. A new request automatically notifies the people involved.
Projects and invoices
Clients, projects and invoices, with who brought a project in and who built it. That makes it possible to trace afterwards how a lead landed.
Permissions in the database
Anyone not entitled to the figures does not get them, not even by addressing the API directly. That is not arranged in the screens but in the policies, and it was verified with a simulated user.
The result
What changed in practice:
- Prospect data no longer sits in files that go round by email
- An external caller only sees what belongs to their own agency
- Two callers cannot pick up the same lead
- Calling private numbers is blocked up front
- What came out of a conversation sits with the lead instead of in someone's head
- The agency's figures are shielded, including from anyone who knows the API
Why CRM Force
Where this case shows how we work:
- Permissions that can be verified, because they sit in the database
- Concurrency solved inside the operation itself, not with a check beforehand
- Privacy as a design question at the start, not as an afterthought
- A data model that follows the real relationships instead of the other way round
- We work in it every day ourselves, so we are the first to notice where it chafes
Also running a system that outside parties work in?
When parties from outside work in your data, the question is not whether the screen hides it but whether the database stops it. We are glad to think that through with you.