Most small teams do not start with a CRM problem. They start with a much more ordinary problem: a promising lead is mentioned in email, the next follow-up lives in someone's task list, meeting notes are in a document, and the latest status is remembered by the person who happened to talk to the customer.
A dedicated CRM can solve that, but it can also become another separate system the team has to maintain. For small teams, the useful version of CRM is often simpler: a shared place for companies, contacts, deals, follow-up tasks, email threads, meetings, notes, and recent activity.
Aamu.app now has a small-team CRM database template built around that idea. It is not trying to replace every feature of a sales suite. It gives a team a practical CRM shape inside the same workspace where the team already handles tasks, email, docs, meetings, and database work.
What the CRM template contains
The template starts with three connected tables:
Companies: accounts or organizations the team is talking to.
Contacts: people at those companies.
Deals: sales opportunities, renewals, pilots, or commercial conversations.
Those tables are connected with reference fields. A deal can point to a company and a primary contact. A contact can point to a company. That gives the CRM its basic structure without forcing everything into one huge table.
The template also includes fields for stage, value, probability, expected close date, next action, owner, tasks, emails, meetings, docs, and notes. The exact fields can be changed, but this starting point is enough to make the CRM honest: you can track a relationship, assign follow-up, connect real work, and see what has changed.
Why three tables instead of one
A one-table CRM is tempting because it feels easy at first. Every row is a lead. Put the company, contact, deal status, email, value, and notes into one place and keep moving.
That breaks down when the same company has multiple contacts, or one contact is involved in more than one opportunity, or a company has a current deal and a later renewal. Copying the same company and contact details across many rows creates stale data.
The Aamu template keeps the CRM normalized enough to be useful:
A company can have many contacts.
A company can have many deals.
A deal can have its own stage, value, owner, and follow-up work.
Contacts can stay attached to the company even when a specific deal is closed.
That structure is close to how small-team sales work actually behaves, but it still stays light enough to edit directly in a database table.
Start from companies, contacts, or deals
Different teams think about customer work from different angles. A sales team may start from deals. A founder-led team may start from companies. A support-heavy team may start from contacts and conversations.
The useful part of using Aamu as a CRM is that the same data can be approached from any of those directions.
Open a company and you can see the contacts and deals that reference it. Open a deal and you can see the company, the primary contact, and the related work. Open a contact and you can connect them back to the company and the sales conversation they belong to.
This matters because CRM work is rarely linear. A conversation can start as an email, become a meeting, produce two tasks, and then turn into a deal. Aamu's database references keep those pieces close enough that the team can follow the relationship instead of hunting through separate tools.
Related items make rows feel less flat
A database row is useful for structured fields, but a customer relationship is more than fields. It has emails, tasks, meetings, docs, and history.
In the CRM template, deal rows can connect to related Aamu items:
Tasks for follow-ups, reminders, research, proposals, and handoffs.
Emails for real customer conversations.
Meetings for calls, demos, onboarding sessions, and check-ins.
Docs for proposals, notes, account plans, onboarding docs, or implementation details.
This keeps the CRM close to the work. A deal is not only a stage and a value. It can also carry the actual follow-up task, the last email thread, the next meeting, and the document where the team wrote down what was agreed.
Activity timeline gives the CRM memory
Small CRMs often fail quietly because nobody trusts whether the row is current. A stage might say "Proposal", but was that changed today, last month, or before the last customer call?
Aamu database rows now have an activity timeline. When a field changes, Aamu records what changed, who changed it, and when. That can be shown as a readable timeline from the row details.
For CRM use, this is especially useful for:
stage changes, such as "Qualified" to "Proposal";
owner changes when responsibility moves to another teammate;
task, email, meeting, and doc links being added;
reference changes, such as choosing a different company or primary contact;
value, probability, and expected close date updates.
This is not a replacement for notes. It is the operational memory around the structured data. The team can see when the CRM was touched and what changed without asking someone to manually write a changelog.
Last activity helps with follow-up
A CRM is only useful if it helps the team avoid losing momentum. One practical field is "last activity": when this company, contact, or deal was last touched.
In Aamu, this can be shown from database activity. Instead of maintaining a manual "last updated" note, the row can show the latest meaningful activity, such as a stage change, a linked task, or a related email being added.
That gives the team a simple review habit: sort or scan by last activity and look for deals that have gone quiet. For a small team, that can be more useful than a large sales dashboard.
Next action is still a human decision
CRM software often promises to tell the team what to do next. In practice, "next" is not always obvious from data alone. The right next action may depend on a customer promise, a product constraint, a pricing discussion, or a meeting that has not happened yet.
The Aamu template treats next action as something the team defines. A deal can have a next action field and a due date, but the strongest follow-up mechanism is usually a real task linked to the deal.
There is also a lighter database-level option. A timedate column can be configured with Column options set to Treat as due date, and a User column can be configured as Treat as assigned to. With those settings, the row itself can behave more like an actionable work item: it can appear for the assigned user as an upcoming or overdue infobox on the main page, and Aamu can create the related notifications.
That means a CRM row does not always need a separate task just to become visible in someone's daily flow. For lightweight follow-up, the deal row can carry its own owner and due date. For richer work, a linked task is still useful because it can have comments, attachments, reminders, and a more detailed workflow.
That is a deliberate choice. A task can have an assignee, due date, comments, attachments, and reminders. It can live in the team workflow instead of being trapped as a note inside the CRM.
A simple workflow
A small team can use the template like this:
Create or select the company.
Add the main contact and reference the company.
Create a deal and connect it to the company and primary contact.
Set the stage, owner, value, probability, and expected close date.
Use the row's assigned-to and due-date fields when the deal itself should show up as upcoming or overdue work.
Add the next follow-up as a task.
Attach relevant emails, meetings, or docs as the relationship develops.
Use the row details and activity timeline to understand what has happened recently.
This is enough for a founder, sales lead, agency, consultancy, or small operations team to keep customer work visible without adopting a heavy CRM process.
Automate CRM updates through the API
The CRM can also react to database changes. Aamu's Database automations API supports two useful triggers: row_inserted when a new row is created, and row_updated when a selected column changes to a selected value.
For example, a row_updated automation can create a handoff task when a deal's Stage column changes to Won. The task can take its title and body from columns in the deal row, assign selected project members, and map row values into task custom fields.
POST /api/v1/databases/CRM_DATABASE_ID/automations
x-api-key: YOUR_API_KEY
x-project-id: YOUR_PROJECT_ID
Content-Type: application/json
{
"name": "Create onboarding task for won deals",
"status": "public",
"trigger": {
"type": "row_updated",
"tableId": "DEALS_TABLE_ID",
"columnId": "STAGE_COLUMN_ID",
"value": "won"
},
"actions": [
{
"type": "create_task",
"pid": "YOUR_PROJECT_ID",
"users": ["OWNER_USER_ID"],
"dbFieldTitle": "DEAL_NAME_COLUMN_ID",
"dbFieldBody": "NEXT_ACTION_COLUMN_ID"
}
]
}The trigger value is the stored column value, which may differ from the label shown in the table. Use the database schema to get the table and column ids and the stored values for status choices.
row_inserted is useful earlier in the CRM flow. It can create a qualification task whenever a new deal or contact is added, whether the row comes from the Aamu UI, a published Form, an authenticated Form submission, or a GraphQL mutation.
{
"name": "Qualify new deals",
"status": "public",
"trigger": {
"type": "row_inserted",
"tableId": "DEALS_TABLE_ID"
},
"actions": [
{
"type": "create_task",
"pid": "YOUR_PROJECT_ID",
"users": ["SALES_OWNER_USER_ID"],
"dbFieldTitle": "DEAL_NAME_COLUMN_ID",
"dbFieldBody": "NOTES_COLUMN_ID"
}
]
}The same API can list, inspect, update, and delete automation definitions:
GET /api/v1/databases/CRM_DATABASE_ID/automations
GET /api/v1/automations/AUTOMATION_ID
PATCH /api/v1/automations/AUTOMATION_ID
DELETE /api/v1/automations/AUTOMATION_IDAutomation management uses the separate Automations API-key scope. A task action also needs Tasks write access to its target project; an email action needs Emails write access and an existing automation email template. Database rows themselves can be inserted and updated through Aamu's GraphQL API, and those mutations run the same automation triggers as changes made in the workspace.
What this is not trying to be
The honest version matters: Aamu's CRM template is a flexible small-team CRM, not a full enterprise sales platform.
If a team needs advanced territory management, complex sales forecasting, quoting, commission logic, deep marketing attribution, or a large marketplace of sales integrations, a dedicated CRM may still be the right tool.
Aamu is most useful when the team wants the CRM to sit close to daily work: tasks, docs, email, meetings, notes, and shared project context. For many small teams, that closeness is the point. The CRM does not need to become a separate system if the customer work already happens in Aamu.
Where AI can help later
Once customer data is structured, AI becomes more useful because it has something concrete to work with.
Aamu can already connect AI support, Team Brain, docs, tasks, and customer conversations in the same workspace. A CRM layer makes that context richer. In the future, this kind of structure can support workflows such as summarizing a company, drafting follow-up emails from recent activity, suggesting stale deals to review, or turning meeting notes into CRM updates.
The important part is that the foundation is understandable: companies, contacts, deals, references, related work, and activity. AI works better when it is helping with a clear workflow instead of guessing from scattered notes.
The bottom line
A small-team CRM should help the team remember who it is talking to, what has been promised, what should happen next, and where the related work lives.
The Aamu.app CRM template is built for that practical middle ground. It gives customer relationships a structured home, connects them to tasks, emails, meetings, and docs, and uses activity history to keep the team oriented.
That is often enough to make CRM useful: not a separate sales machine, but a connected view of customer work inside the workspace where the team already works.