Project contacts - SLAtech Vantage

Two years into a project there are dozens of people in it, and nobody typed a single one of them anywhere. One wrote once, another decides everything, a third left the company long ago. The question "who is this, actually" gets asked at exactly the moment when there is no time to look.

Contacts accumulate from the work, they are not typed in

Nobody maintains a list of people here. They appear on their own: from the requesters of opened tickets, from incoming mail, from loaded conversations. You can also import a staff file, and you can add a person by hand.

Every record keeps its origin: born from tickets, arrived by import, detected automatically during sync, or entered manually. This is not decoration: when someone asks "where did they even come from", that is the answer.

One person, several addresses

A person has several identities: mail addresses, phone numbers, spellings of the name in Hebrew and in Latin script, their id in the ticket system. They belong to the person rather than the other way round, so a new address does not create a new person. The card shows a primary address and a primary phone, with everything else beneath.

Orders of magnitude from one live project, as an example of scale and not as a promise: 525 mail addresses, 329 phone numbers and 252 name variants, spread across the people.

Duplicates are proposed for merging; the decision is yours

The system proposes merge candidates and names the reason, such as an identical name. It does not merge on its own. A person confirms, and the identities move to the record that stays.

Un-merging afterwards does not exist today. What does exist: removing a single identity from a person, as long as it is not their last one. We would rather write it this way than promise it.

Who is a person, who is a department mailbox, and who is a robot

Not every address is a human being. There are department mailboxes, automatic senders, and addresses about which nothing can be said. The separation runs on explicit signals: the auto-submitted header, a local part typical of a robot, a name that reads as a job title rather than a person.

Then comes the separation between your people and suppliers. You name your domains once, and from there the participants sort themselves out. Until the domains are named, nobody is marked at all: not "supplier" but "undetermined". The comparison is against the full domain or a subdomain of it, so not-example.com will not become yours. And the domains are taken from the project's customer, because "ours" here means "an employee of the company the project is about".

Orders of magnitude from the same project: 345 employees, 198 suppliers, 19 system addresses and one robot.

What is known about a person without asking anyone

Numbers accumulate for each person out of the work itself: how much they wrote, how many wrote to them directly, in how many they were only copied in (a different signal, so the two are never summed), how many tasks they took part in, how many messages they wrote in conversations, how many times they are mentioned in the journal.

Alongside them: the first and the last contact, how long the relationship has run, how long since the last time, the rhythm of contact, the primary channel, recurring topics and departments.

And every number has sources. They can be opened to see which tickets, messages and records it was built from. A number without a source is an opinion, not data.

Why this is not an address book

Into an address book you type, and then forget to update. Here you type nothing, and what is known keeps updating because the work keeps going. A book answers "what is their number"; this answers "who they are, when we last spoke, and about what".

What the customer sees of it

Nothing. The dossier and the layers built on it are not part of what the customer can reach, and their search runs on a whitelist of material kinds: anything not on the list is invisible by default, including kinds written later. The rule is "closed until stated otherwise", not "open until blocked".

Frequently asked questions

Do we have to type in the contacts?

No. People appear by themselves from the work: from whoever opened tickets, from incoming email and from loaded conversations. You can also import a staff file and add a person by hand. Each record keeps its origin, so you can tell whether it came from a ticket, an import, automatic detection during sync or manual entry. A new address or phone number joins an existing person rather than creating a new one.

How does the system tell our employees from suppliers?

By the domains you name once. An address on your domain or on a subdomain of it is classed as an employee, and any other address as a supplier. Until the domains are named, nobody is marked, and the classification is "undetermined". Separately, the system recognizes department mailboxes and automatic senders by explicit signals, such as an auto-submitted header or a name that reads as a job title rather than a person.

Does the system merge duplicates on its own?

No. It proposes merge candidates and gives the reason, for example an identical name, and a person confirms. After confirmation, all the identities, that is addresses, phone numbers and spellings of the name, move to the record that stays. Undoing a merge does not exist today, so confirm with care. What you can do is remove a single identity from a person, as long as it is not their last one.

Do the client or the AI model see the information about people?

The client does not see the people dossier at all: it is not on the allow list of data kinds open to them, and any new kind is closed by default. When text is sent to an external model, for example to analyse a conversation, it is masked first: names, ID numbers, phone numbers and email addresses are replaced with labels, and the names come back only in the display on your side.

Know who you are working with on every project