A project usually has a named lead, a budget and a deadline. Ongoing ownership needs the same clarity. After go-live, requests keep arriving, and without named owners nobody has the time or authority to act on them.
The same approach works for a CRM, a marketing platform, a quoting tool or any shared system a sales or marketing team relies on.
Spot the signs that a system has no owner
- Requests go to whoever answers first. Changes happen in chat messages, with no record of who asked or why.
- Fields multiply. Each team adds its own version of the same field, and reports stop agreeing.
- Former staff still have access. Nobody removes users when people leave.
- Licences renew without review. The business pays for seats or add-ons nobody uses.
- Integrations fail quietly. Data stops syncing, and nobody notices until a report looks wrong.
Separate the ownership roles
One person rarely has the authority, the skills and the time for every part of the job. Split it into three roles. In a small business, one person may hold two of them.
Business owner
This leader decides what the system should do, sets priorities and approves larger changes. Choose a business owner with authority across the teams and processes the system supports.
A CRM is often shared by sales, marketing and service. In that case, choose someone whose remit covers all three, such as a commercial or operations leader. A marketing platform used only by marketing can sit with the head of marketing.
System administrator
This person runs the system day to day. They handle routine administration themselves, such as adding a report, a picklist value or a new user.
Some changes need approval first. These include changes to access levels, billing, messages sent to customers, and how customer data is stored or shared. The administrator brings these to the business owner.
Process owners
Each team that uses the system names one person, usually a team lead. They keep their team's process, fields and reports correct. They also collect their team's requests and check new changes before release.
Backups and supporting teams
Name a backup for the business owner and the administrator. Each backup needs the access, the notes and the authority to act when the main owner is away.
IT often looks after security and sign-in. Integrations vary: IT, the administrator or an outside partner may have built and supported each one. Name an internal owner for every integration, whoever supports it. Finance usually reviews licences and renewals.
Choose the business owner with care
The business owner needs to weigh one team's request against another's. Someone who runs only one of the teams may favour that team's needs.
When IT holds this role alone, priorities can move away from what sales and marketing need. IT still has a say on security and access. The business owner should consult IT on changes that affect them.
If no single leader covers every team, name one business owner and make the other leaders consulted parties. Two owners with equal say tend to stall decisions.
Agree an ownership table
Here is an example table. Treat it as a draft, and agree it with every role before go-live. Use these letters for each task:
- R (responsible): does the work.
- A (accountable): makes the final decision. Each task has one A.
- C (consulted): gives input before the decision.
- I (informed): is told after the decision.
| Task | Business owner | Administrator | Process owner | IT | Finance |
|---|---|---|---|---|---|
| Make routine changes, such as a report filter or picklist value | I | A, R | C | ||
| Approve new fields, stages or pipelines | A | R | C | I | |
| Change access, billing, customer messages or customer data handling | A | R | C | C | C |
| Add and remove users | I | R | C | A | |
| Keep data clean and fix duplicates | A | R | R | ||
| Build and change reports | C | R | A | ||
| Train new starters | I | C | A, R | ||
| Manage integrations with other systems | C | A, R | I | C | |
| Review licences and renewals | A | C | C | R | |
| Decide on new features or add-ons | A | C | C | C | C |
In this example, the administrator is accountable for integrations. If IT built or supports an integration, IT may hold the A for it instead.
Adapt the rows to your business. Keep one A per row, and use role names so the table still works when people change jobs.
Store the table where every user can find it, such as the team's shared drive or the system's help page. Review it each year, and whenever a named role changes hands.
Plan the time the role needs
The administrator role is often given to someone as a small extra. In the first months after go-live, it is usually larger than that.
Example (illustrative): A business with 40 users ran a new CRM and a marketing platform. In the first three months after go-live, the administrator received about 25 requests a week.
Most took 10 to 20 minutes. At 25 requests a week, the queue used about 4.2 to 8.3 hours each week.
The business gave the role to a sales operations analyst for two days a week. The queue took only part of that time. The rest covered data checks, the monthly review with the business owner and interruptions during the day.
By month six, requests had dropped to about 10 a week, mostly new starters and report changes. The role moved to one day a week.
Count your own requests for the first month and adjust the time. Record each request in one place, so the numbers are easy to find. Group them by type, such as access, reports, fields and data fixes. The groups show where training or a small change would cut the load.
Set up a simple change process
- Send every request to one queue, such as a form or a shared board. Ask who needs the change and what decision it supports.
- Have the administrator sort the queue each week. They make routine changes and list the larger ones.
- Meet the business owner once a month for 30 minutes to approve or decline the larger changes.
- Tell users what changed and why, in one short message each month.
- Review the system each quarter against the goals set at the start of the project.
Urgent incidents and access removals need a faster path than the monthly meeting. Send them straight to the administrator, or the backup, with an agreed response time. For example, remove a leaver's access on their last day.
Hand over before the project closes
Here is an example four-week handover at the end of the project.
- Week 1: Name the business owner, administrator, process owners and backups. The administrator joins the build team's daily work.
- Week 2: The administrator makes changes, and the build team reviews them.
- Week 3: The build team documents fields, automations, integrations, permissions and known issues. The administrator checks the notes.
- Week 4: The administrator runs the queue alone, with the build team available for questions.
Before the project closes, run a handover acceptance check. The administrator and the backup each show they can do these tasks using only the notes:
- Make a routine change and record it.
- Remove a user's access.
- Find and restart a failed integration.
- Find the ownership table and the list of open issues.
The business owner signs off the handover once these pass. Then agree the date the project closes.
Avoid these common mistakes
- Giving every user admin rights. Changes then happen without review, and fields and automations pile up.
- Treating go-live as the end. Plan and fund the owner roles in the project budget, before the project closes.