An account is rarely one thing. A single client relationship is usually spread across several Opportunities in different stages, a handful of concurrent Projects with different project managers, and a group of people reporting hours across all of them.

The person accountable for the relationship, the account lead, the customer manager, the partner who signed the frame agreement, normally sees only the parts they are personally involved in. Answering "how is this account actually doing" means assembling the answer by hand from the Projects list, Allocations, Actuals and invoices, which is why it tends to happen before a quarterly review rather being an ongoing process.

The Customer page removes that assembly work. Everything that happens with a customer — their Projects, the people working there, the time reported against them and the money the account produces — is on one page, so the state of a customer relationship is true in a single place instead of being reconstructed from five views. Because the page shows all of the customer's Projects rather than only those you are involved in, an account lead sees the whole account without needing to be added to every Project in it.

The Customers page lists every customer in your organization. You can search by Name and narrow the list by Segment or Domain, by any of the customer's identifiers — Business ID, Financial ID and External ID — and by when the customer was created or last updated.
​

The three identifiers each point at a different system. Business ID typically holds the customer's official company registration number, Financial ID their identifier in your financial system, and External ID is the connecting key used by CRM integrations. Keeping them apart is what lets one customer be recognized correctly by each system it touches, rather than being matched on a name that is spelled three different ways.

The identifier and timestamp filters are there for reconciliation rather than browsing. Customer data arrives from your CRM and leaves towards your financial systems, so the practical questions are usually "which customers are still missing a Financial ID" and "what has changed since we last exported", and both are answerable from the list itself instead of from a spreadsheet next to it.

Beyond the identifiers, a customer carries a name and description, a domain, a segment, and one or more customer managers. Customer managers matter beyond labeling — when someone creates a Lead for a customer, it is the customer manager who is notified, so the person who owns the relationship decides whether there is a real Opportunity to pursue.
​
​

A single customer opens into four tabs — Overview, Allocations, Actuals and Finance. Each answers a different question about the account, and all of them are scoped to that customer, so numbers in a header row describe the customer rather than the organization.
​
​

The account at a glance: the Projects run for this customer, the Opportunities currently in play, the open Leads, the Teams involved in the work, and the Offerings and Skills the account draws on. Together these are the things you would otherwise ask three colleagues about — what are we doing here, what might we be doing next, and who from our side is in it.
​

The Projects table lists all of the customer's Projects regardless of your own involvement. This is the point of the page: an account lead is accountable for work they do not personally deliver, and a picture that silently omits the Projects they are not staffed on is worse than no picture at all, because it looks complete.
​
​

Who is booked to this customer and when, with the totals for the customer's own Allocations. This is the view for the questions that decide whether a relationship keeps growing: how many people are committed to this account over the coming months, whether the team ends as contracts end, and whether the Openings still waiting for a candidate are ones this customer expects to be filled. Uncontracted Openings from Opportunities appear alongside contracted Allocations, so a renewal that is not yet signed is visible as demand rather than as a gap.
​

For the calculation logic behind the numbers, the display modes and the color coding, see Allocations.

The hours actually reported against this customer, across all of their Projects. The Summary view lists the people who work for this customer rather than the whole organization, which is what makes it usable as a monthly check: reported time on an account is where scope creep, unbilled work and a Project drifting away from its plan show up first, and they show up weeks before they reach an invoice.
​

Time reporting data is sensitive and its visibility follows the same rules as elsewhere in Agileday. See Time reporting and payroll for how hours are collected.

The financial picture for the account rather than for one Project at a time: what the customer's Projects are forecast to produce and what they have actually produced, aggregated across the whole relationship. A customer whose largest Project is ending is a customer whose revenue falls next quarter, and that is visible here months before it is visible in an invoice.
​

Financial figures follow the permissions described in Financial data and Pricing, a person who cannot see a Project's financials on the Project does not see it aggregated here either.

​

Who sees what. Visibility on the Customer page is not a separate permission model. Each tab respects the permissions the underlying data already has. Financial figures are limited to the roles that can see financial data, and to the Project managers and Project assistants of the Projects concerned. Time reporting Actuals follow the visibility rules set for the Project subtype. Subcontractors do not have access Roles and their permissions are managed in Settings / Users & permissions.

​Where customers come from, and what can be edited. Customers originate in your CRM and are kept in step through the CRM integration — they are not created in Agileday, not even by an administrator. What an administrator can edit is the customer fields the CRM does not own, and which fields those are is defined per organization under Customer managed fields in Settings / Integrations. Splitting the record this way is what keeps both sides honest: a field the CRM owns stays the CRM's to change, and a correction made in Agileday on a field it owns is not silently overwritten at the next sync.
​

Customer managers. Setting a customer manager for each customer is what makes Leads reach a person rather than a queue. A customer with no manager will still work everywhere else, but its Leads have nobody to route to.