The contact database behind every app. One record per person, assembled from the bookings, orders and conversations you already hold.
A sixteen-tab contact detail reading from every app in the platform. Eight customer lists computed at query time. A segment builder whose lists stay current. Included with any Interact app.
Every contact. Every interaction. One record.
Contacts
One directory the whole platform reads.
Contact-360
Sixteen tabs reading from every app.
System Lists
Eight lists computed at query time.
Segments
A builder whose lists stay current.
Companies
Company records linked to their contacts.
Data Tools
Import, merge, tags, and saved searches.
Connections
One record assembled from the apps that wrote it.
The contact is the same contact everywhere.
Orbit keeps no contact database of its own. A booking writes a contact, an order writes a contact, a message writes a contact, and Orbit is the lens that shows you all of it at once. The Orders tab reads the orders. The Financial tab reads the money. The Memberships tab reads the memberships. Nothing is copied in, so nothing can be out of date, and there is no reconciliation to run when two numbers disagree, because there are never two numbers.
0
tabs on the contact-360 detail
0
system lists, zero configuration
Zero
data imports to reconcile
Every person your business has worked with. One list.
Name, email, phone, company, tags, stage, the channel they last came in on and the date they were last active. Search across name, email and phone, filter on any column, create a contact or import a file, and open any row into the full record.
| Name | Phone | Company | Tags | Stage | Last Channel | Last Activity | |
|---|---|---|---|---|---|---|---|
| Beatriz Almonte | beatriz@almontelaw.do | +1 809 555 0142 | Almonte Law | Legal, Retainer | VIP | 12 Mar | |
| Kwame Adjei | kwame.adjei@sankofa.gh | +233 24 555 0198 | Sankofa Logistics | Wholesale | Repeat | Phone | 11 Mar |
| Lucía Ferreira | lucia@ferreiraeventos.uy | +598 9 555 0117 | Ferreira Eventos | Events | Customer | SMS | 09 Mar |
| Daniel Osei | no email | +233 20 555 0166 | Osei Motors | Fleet | New | none yet | 08 Mar |
| Renata Villalba | renata@villalbaspa.py | +595 98 555 0173 | Villalba Spa | Wellness, Members | VIP | 06 Mar | |
| Marcos Tavárez | marcos.tavarez@puntaazul.do | +1 829 555 0130 | Punta Azul Resort | Hospitality | Repeat | 04 Mar | |
| Amina Diallo | amina@dialloimports.sn | +221 77 555 0125 | Diallo Imports | Trade | Prospect | none yet | 01 Mar |
The toolbar searches across all three at once, because the way an operator recalls a person is whichever of the three they happen to have. Filters narrow on any column beside it.
New, VIP, Repeat, Customer and Prospect are computed from the contact record itself: how old it is, what loyalty tier it carries and how many orders sit against it. Nobody maintains a stage field, so nobody can leave one stale.
Email, Phone, SMS or Mail, normalised from the contact record rather than logged by hand. A contact nobody has spoken to yet shows nothing, which is the honest answer.
Total contacts, new this month, contacts with an email address and contacts missing one. The last of those is the actionable one: it is the size of the audience you cannot reach.
Clicking a row opens the contact-360, landing on the activity tab. Header actions create a contact directly or open the CSV import.
The directory narrows to the active business unit and the counts above it narrow with it, so a total never disagrees with the rows underneath it.
Everyone you have ever worked with, in one record.
One contact list the whole platform reads. Stage, last channel and last activity sit on the row, so who is cold and who just called is a glance rather than a report.
Open one person and see every app at once.
Open a contact and see their activity, their timeline, an AI summary, the lists they are in, their deals, bookings, orders, messages, email engagement, financial position, memberships, subscriptions, loyalty tier, notes, custom properties and documents. Every tab reads from the part of the business that owns that data. The heading is the app. The number is the number.
Deals, Bookings, Orders, Messages, Email, Memberships, Subscriptions, Documents. Each one is named after the part of the business that owns that data, because that is literally where the tab reads from.
Each tab queries the shared database through the platform data layer, filtered to this contact. There is no connector, no nightly job, no staging table and no last-synced timestamp anywhere in the product.
A tab whose source has nothing for this contact renders empty. It does not fall back to a cached figure from an earlier read, because there is no cache to fall back to.
Opening a contact goes straight to activity, which lists what has been logged against them. Timeline sits beside it and merges their messages, their calls and their meetings into one chronology.
Lists, Notes, Properties and the tags on the record are Orbit data. The other twelve are windows onto data that already existed before Orbit was opened.
The loyalty tab renders tier, points and rewards and is gated on the Circle loyalty flag. It is hidden rather than shown empty when the account is not running loyalty.
The same person, read through five different apps.
These five tabs are Orbit's own screens. The other eleven are the other apps' data rendered in place: the Orders tab reads the orders, the Bookings tab reads the bookings. Nothing was copied here, which is why nothing here can disagree with the app that wrote it.
Every interaction in one column, newest first, with the channel it arrived on. A call, an email, a WhatsApp message and a payment are the same list because they are the same person.
Lists that compute themselves. Segments that stay current.
The lists store criteria rather than membership, so somebody who places a third order is in Repeat Customers on the next load, with nothing scheduled.
The useful lists are there before you configure anything.
Orbit opens with eight customer lists already populated: New Customers, VIP Customers, Repeat Customers, At Risk, Recent Interactions, Birthday This Month, No Email and Unsubscribed. They hold no rows of their own. Each evaluates its criteria against the live contact set every time it is opened.
The eight exist the first time the account opens the lists hub. There is no setup wizard, no rule to write and no segment to save, because the criteria are part of the product rather than part of your configuration.
A system list is not a stored set of contact ids. Each one runs its criteria against the live contact set when it is opened, so the membership you are looking at is the membership as of that moment.
A customer who places their third order is in Repeat Customers on the next load. Nothing schedules that, nothing recalculates overnight, and nobody has to remember to refresh a segment.
Criteria the database can filter on are counted by the database. Criteria it cannot, like a birthday month or an order count, are tested against a bounded scan of the active set. Both paths return the same membership.
The eight are reserved and undeletable. Your own lists sit beside them in the same hub with the same member counts, and a list you built can be dynamic or static.
It requires at least one order and no activity for 90 days, so it is a list of people who bought from you and then stopped, not a list of people who never started. That distinction is the difference between a useful list and a long one.
Build a list from criteria. The membership stays current.
Pick a field, pick an operator, give it a value, and add another. Conditions within a group all have to hold; any group holding is enough. A live count tells you how many contacts match before you save. Save it dynamic and it re-evaluates every time it is read; save it static and the membership is frozen where you left it.
Every condition in a group has to hold. Any group holding is enough. That is the whole logic model, which is why the builder needs no query language and no nesting beyond two levels.
The preview runs the criteria you have built so far and returns the matching count with sample contacts. You find out a segment is empty while you are building it, not after you have pointed a campaign at it.
A dynamic list stores criteria, not contacts. Opening it runs the criteria again, so a contact who qualifies tomorrow is in it tomorrow and a contact who stops qualifying leaves it without anyone removing them.
A static list stores the contact ids themselves. That is the right shape when the list is a decision rather than a query: the fifty people invited to an opening should stay the fifty people invited to an opening.
This is one shared block pointed at the Orbit endpoints. A segment authored here and a Deals smart list are rows in the same table with the same criteria shape, so neither app has to learn the other one.
A condition the contact set cannot answer is dropped from the query rather than silently approximated. A list that returns fewer contacts than you expected is a list you can debug; one that quietly guessed is not.
Lists that answer the question again every time you open them.
A smart list stores the criteria, not the membership. Somebody who places a third order is in Repeat Customers on the next load, and somebody who goes quiet for ninety days appears in the win-back list without anybody moving them.
People are half of it. The other half is who they work for.
Contacts belong to companies. Companies hold the relationship.
A company record groups the people who work there. The detail carries its industry, website, phone and city above a table of its contacts. The list counts every company, how many have contacts attached and the open deals across all of them. Create one directly, or let it resolve from the company column during an import.
| Name | Title | |
|---|---|---|
| Beatriz Almonte | beatriz@almontelaw.do | Managing Partner |
| Rafael Guzmán | rafael@almontelaw.do | Associate |
| Yesenia Pérez | yesenia@almontelaw.do | Office Manager |
| Hector Núñez | hector@almontelaw.do | Paralegal |
It has its own list, its own detail view and its own create, edit and delete. The company on a contact record points at that record rather than repeating its name as free text on every person who works there.
The company detail lists everyone at that company with their email and their title. When one of them leaves and another arrives, the relationship with the company survives the change of contact.
Total companies, companies that actually have contacts attached, and the open deals across all of them. The second is the one that tells you how much of your company list is real.
Name, industry, website, phone and city. Enough to recognise the company and reach it, without a form nobody will finish.
Get the list in, then get the duplicates out.
Import contacts by pasting a CSV or filling in the downloadable template, with a toggle that skips rows whose email is already on file. Merge and Fix clusters duplicates by email, falling back to name, and tells you why each cluster was grouped. Merging unions the tags, moves the static list memberships, and deletes the losers.
| Contact | Duplicates | Suggestion | ||
|---|---|---|---|---|
| Beatriz Almonte | beatriz@almontelaw.do | 2 | Same email address | Merge |
| Kwame Adjei | kwame.adjei@sankofa.gh | 3 | Same email address | Merge |
| Lucía Ferreira | no email | 2 | Same full name, no email on either | Merge |
| Marcos Tavárez | marcos.tavarez@puntaazul.do | 2 | Same email address | Merge |
Every tag on every duplicate moves onto the primary. No tag is lost, because the tag is usually the only record of why somebody filed that contact in the first place.
Any static list holding a duplicate has that id swapped for the primary, deduped. Dynamic and system lists are left alone because they re-evaluate their criteria and will simply find the survivor.
A real delete, not a flag. The contact that survives is the one you chose, and the ones you did not are gone rather than hidden somewhere a later query can find them again.
Contacts are clustered by normalised email address. A contact with no email falls back to a normalised full name. Anything with neither is skipped rather than guessed at.
Each cluster carries the reason it was grouped, so you can tell a genuine duplicate from two different people who happen to share a name before you merge anything.
The action confirms that the duplicate records will be deleted and that their lists and tags move to the primary, and says plainly that it cannot be undone. Then the row leaves the table.
Paste CSV rows of name, email, phone and company, or download the template first and fill it in. One toggle skips rows whose email already exists, so a re-import tops up rather than duplicating.
When nothing matches, the merge screen says your contacts are clean rather than showing an empty table with no explanation. An empty state that explains itself is a feature.
Custom properties, tags and lifecycle stages are configured in one settings screen, and every tag doubles as a filtered view of the contacts carrying it.
Almost nothing on a contact record was written by Orbit. Here is who wrote it.
One record, assembled from the apps that wrote it.
Bookings
Reservation → the Bookings tab
A reservation taken against a person is what puts that person in the directory, and the Bookings tab on their record lists every reservation they hold without a booking ever being copied into a contacts database.
Orderflow
Order → the Orders tab · Repeat Customers
Order history renders on the contact and the same order count decides the stage badge on the directory row. Three orders makes somebody a Repeat Customer, and it does so on the next read rather than after a nightly job.
Deals
Deal → the Deals tab
Open and closed deals attach to the contact by the same id the pipeline card carries, so the sales history and the service history sit on one record instead of in two systems that have to agree with each other.
Voice · Agenda
Call · meeting → the Timeline tab
The Timeline tab gathers the calls placed and received and the meetings booked with somebody into one chronology alongside their messages, so the record of talking to a person sits next to the record of writing to them.
Inbox · Mail
Conversation · email event → Messages · Email
The Messages tab reads the shared conversation store and the Email tab reads the email event log, so what somebody said to you and what you sent them are two tabs on the same record rather than two products.
Ledger · Payments
Payment → the Financial tab
Revenue, payments and the outstanding balance render on the contact in the currency each record was written in. A payment taken moves the number on the record, because it is the number on the record.
Registry · Circle
Membership · tier → Memberships · Loyalty · VIP
Memberships list from the member records and the loyalty tier on the contact is what the VIP Customers list matches on, so a tier awarded in one place is a segment in another with nothing in between.
Depot
File → the Documents tab
Documents filed against a contact are account file store assets tagged to that contact, counted against one storage allowance rather than a second contacts-app attachment store.
Deals
Segment ⟷ the same list store
A segment built here and a segment built in the pipeline are the same saved row, authored by the same builder, so a list does not have to be rebuilt to be used by whoever is selling rather than serving.
Purview
Business unit → every read
The active business unit scopes the directory, the companies, the lists and the counts above them together, so a total on this page never disagrees with the rows beneath it.
Where Orbit touches everything else.
6 of these 15 connections are in your plan today. The rest stay visible so you know the instrument is there before you need it.
The Bookings tab lists the reservations held by this contact, read from the reservations namespace, and a reservation taken against a person is what puts that person in the directory in the first place.
The Deals tab lists the open and closed deals attached to this contact, filtered on the same contact id the pipeline card carries.
The Orders tab reads order history from the orders namespace, and the same order count decides whether a contact is a Customer, a Repeat Customer or neither.
A support ticket is raised against a contact id, so the ticket and its updates land in the activity feed on that contact without being copied into Orbit.
The Memberships tab reads the member records tied to the contact, so a membership taken out in Registry is visible on the contact the moment it exists.
The loyalty tier carried on the contact row is what the VIP Customers system list matches on, and the Loyalty tab renders the tier, points and rewards behind the Circle loyalty flag.
The Messages tab lists the conversations held with this contact by reading the shared conversation store the messaging engines write to.
The Email tab reads the email events sent to this contact, each with its subject, its delivery state and when it went out.
The Financial tab reads the revenue, payments and outstanding balance carried against the contact, in the currency each record was written in.
A payment taken against a contact is what moves the financial summary on their record, without a reconciliation step in between.
The Documents tab lists the files filed against this contact as account file store assets, not a second copy held by the contacts app.
A campaign needs an audience and Orbit is where the thinking about who to reach gets done, so the segment you argued about is defined once and named the same way in both places.
A contact record is what a workflow acts on, and the lists here are how you decide which contacts are worth acting on in the first place.
No setup cost. Pay when you start using.
Contact management for teams that talk to customers.
Recommended for you
Use one app or many. Works well together.
Everything included in Calisto Orbit.
- Every contact in the account in one searchable table
- Name, email, phone, company, tags, stage, last channel and last activity
- Search across name, email and phone at once
- Filter on any column, fifty rows to a page
- Four counts above the table: total, new this month, with email, missing email
- Lifecycle stage derived from the record: New, VIP, Repeat, Customer, Prospect
- Last channel normalised to Email, Phone, SMS or Mail
- Create a contact, or open the CSV import, from the header
- A row opens the contact-360 on its activity tab
- Sixteen curated tabs in one pill-tab chrome
- Activity: what has been logged against the contact, newest first
- Timeline: messages, calls and meetings merged into one chronology
- AI Summary: an intelligence summary of the record
- Lists: every list this contact currently belongs to
- Deals: open and closed deals attached to the contact
- Bookings: reservations held by the contact
- Orders: order history
- Messages: conversations across the messaging channels
- Email: emails sent, with subject, state and date
- Financial: revenue, payments and outstanding balance
- Memberships: active and lapsed memberships
- Subscriptions: plan, status, renewal date and amount
- Loyalty: tier, points and rewards, behind the Circle loyalty flag
- Notes: internal notes with author and date
- Properties: custom fields on the contact
- Documents: files filed against the contact, with type and size
- Eight lists present on the first open, with no configuration
- New Customers: added in the last thirty days
- VIP Customers: gold or platinum loyalty tier
- Repeat Customers: three or more orders
- At Risk: has ordered, then silent for ninety days or more
- Recent Interactions: active in the last seven days
- Birthday This Month: birthday falls in the current month
- No Email: missing an email address
- Unsubscribed: opted out of marketing
- Criteria evaluated on every read, never materialised as rows
- Counted by the database where the criteria allow it
- Tested against the active contact set where they do not
- Reserved and undeletable
- Customer Lists hub: system lists and your own lists in one table
- Member count, type and last update on every list row
- Segment builder with a six-field catalog
- Fields: Name / Email, Stage, Role, Lead Source, Created Date, Last Activity
- Conditions AND within a group, groups OR across
- Live preview count and sample contacts before saving
- Dynamic lists store criteria and re-evaluate on read
- Static lists store contact ids and stay frozen
- Smart Lists: the dynamic segments, listed on their own
- Saved Searches: re-runnable contact searches with their results
- Tags: every tag is a filtered view of the contacts carrying it
- A predicate the contact set cannot express is skipped, never faked
- Company records with their own list, detail and full CRUD
- Profile: name, industry, website, phone and city
- A table of the contacts at that company with email and title
- Three counts: total companies, companies with contacts, active deals
- Companies resolve from the company column during import
- CSV import by paste, with a downloadable template
- Column set: name, email, phone, company
- Skip-duplicates-by-email toggle on the import
- Duplicate detection clustered by normalised email
- Fallback clustering by normalised full name when there is no email
- A stated reason on every cluster
- Merge unions the tags of every duplicate onto the primary
- Merge rewrites static list membership onto the primary, deduped
- Merge deletes the duplicate records outright
- Dynamic and system lists need no rewrite because they re-evaluate
- A confirmation that states the merge cannot be undone
- Total contacts, new this month, total lists and total companies
- List performance table with members and growth per list
- Contact settings: custom properties, tags and lifecycle stages
- Default country and default currency for new records
- Notification centre with in-app delivery and an unread count
- Mark-one-read and mark-all-read
- Per-person, per-channel notification preferences
- Live stream for new notifications, plus device token registration
- One contact model, shared with every app that touches a person
- Each contact-360 tab reads the namespace that owns that data
- No connector, no import job, no staging table, no sync delay
- One identity: every person is a user id inside an account
- Every read and write scoped to the account
- The active business unit scopes contacts, companies and lists
- Lists persist in the same table Deals smart lists use
- Criteria persist as a portable filter tree, not a query string
- No intra-account roles, because Calisto has none
- Bookings (reservations on the contact, and contacts created by a booking)
- Deals (the deals attached to the contact)
- Orderflow (order history, and the order count behind Repeat Customers)
- Desk (tickets raised against the contact)
- Registry (memberships)
- Circle (the loyalty tier behind VIP Customers)
- Inbox (conversation history)
- Mail (email activity and engagement)
- Ledger and Payments (the financial summary)
- Depot (documents filed against the contact)
- Campaigns (lists and segments as the audience)
- Automations (list membership as a condition)
- Identity (the verification level on the record)
- Purview (business unit scope)
Questions about Calisto Orbit
Whatever every app in the platform knows about the person: bookings, orders, deals, calls, messages, payments, membership, files. It is one record read sixteen ways rather than sixteen systems that each hold a fragment.
A segment is a query, so it stays current. Eight customer lists are computed at query time, which is why the list you looked at last month is right today without anyone refreshing it.
It is included with any Interact app. If you have Inbox, Mail, Voice, Live, Link or Equipo, you have Orbit.
Yes, though most of what fills Orbit arrives from the apps themselves. An import gives you the people; the operation gives you the history.
Included with any Interact app rather than sold separately. The pricing section on this page reads the live catalogue and is the authority.
Yes, in standard formats, including the segments and the interaction history behind them.