The work does not become static when an EPM implementation goes live. Finance teams still add users, adjust planning models, troubleshoot data flows, document decisions, and help business owners use the system consistently. Without a clear operating model, those requests tend to collect around a small number of internal experts. This can create avoidable delays and ownership gaps.
Pigment admin support is the practical layer that keeps a live planning environment reliable after implementation. It includes maintaining models and integrations, managing access, resolving issues, supporting users, and improving processes as requirements change. It should extend the implementation foundation, not replace internal ownership or become an undefined help desk.
Get in touch to discuss how your post-go-live operating model should work.
The right structure starts by identifying what happens between a completed project and the next planning cycle, when the system must remain governed, usable, and ready for change.
What happens after an EPM implementation ends: the admin support gap
Go-live is a milestone, not the point at which an EPM model becomes self-sustaining. The implementation team may have completed requirements gathering, model and data-flow design, integrations, user acceptance testing, monitoring, and performance management. Those decisions create a strong operating foundation, but they do not remove the need for an accountable owner once the project team steps away.
The gap appears when the handoff transfers responsibility without transferring enough capability. An internal team may know how to open a model, yet still lack the documentation, training, permissions knowledge, or time needed to maintain it confidently. A new planning cycle then exposes unresolved questions. Who approves a model change? Who investigates a failed process? Who updates user access? Who decides whether a workaround is safe to carry forward?
Planned administration is different from emergency troubleshooting
Pigment admin support is a continuing operating function, not simply a route for reporting defects. Planned administration can include model maintenance, user enablement, documentation, bug resolution, performance optimization, process improvement, and adoption support. These activities give the business a repeatable way to keep the application aligned with how finance and operating teams actually work.
Emergency troubleshooting has a narrower purpose. It responds when a workflow fails, a user cannot access the right information, or a planning process is at risk. That response matters, but it is not a substitute for reviewing recurring issues, refreshing training materials, documenting ownership, or improving a process before the next forecast cycle. Treating every request as an incident leaves the organization reacting to symptoms instead of managing the system.
Why the gap affects adoption and planning continuity
Without clear post-go-live ownership, small uncertainties accumulate. Users create informal workarounds. Administrators hesitate to change a model because the original design rationale is unclear. Documentation becomes outdated, and the next group of users receives inconsistent guidance. Over time, confidence in the planning process can decline even when the underlying platform remains capable.
This is also a governance issue. As an organization expands from an initial use case toward connected planning, administration must keep decisions. Data flows, and user responsibilities coherent across financial, revenue and operations, supply chain, or workforce planning. A defined support model connects maintenance and enablement to adoption, rather than treating them as optional tasks after implementation. The objective is continuity: the model remains understandable, governed, and useful as planning requirements develop.
What ongoing Pigment admin support typically includes
Ongoing administration is the operating layer that keeps a Pigment environment usable after go-live. It is not limited to answering user questions. The work combines controlled access, model upkeep, data checks, enablement, issue resolution, and practical improvements as planning requirements change.
Access, permissions, and governance
User access should be maintained as deliberately as the model itself. Each Pigment application has its own roles, while access rights determine what a user can see or edit and permissions determine which actions they can perform. Groups can apply those roles to multiple users, and board access configurations can define which roles may view, comment on, or edit specific boards.
Admin support may therefore include onboarding and offboarding users, reviewing role assignments, updating group membership, and checking that access still matches a person's responsibilities. More detailed governance can apply rights to key dimensions and individual users, protect sensitive fields, and support secure access through single sign-on. Amvent's guide to Pigment access management explains how these controls fit together.
Model maintenance and data checks
A planning model needs attention as the business changes. Administration can include maintaining structures, reviewing formulas or assumptions when approved processes change, and checking that updates do not create unintended effects elsewhere in the model. The exact work depends on the design and ownership boundaries established during implementation.
Data and integration checks are equally important. An administrator may review scheduled imports, investigate failed or incomplete data movement, and confirm that source data remains aligned with the planning process. Where APIs support custom integration needs, support can include coordinating investigation of those connections and documenting the expected data flow. These checks help finance teams distinguish a model issue from a source-data or integration issue before a planning cycle is disrupted.
Documentation, training, and issue resolution
Documentation should stay current as the environment evolves. Useful materials can cover administrative procedures, ownership, recurring processes, and the steps users need for their planning responsibilities. Training and user enablement also need to evolve beyond the original handoff, especially when new users, teams, or planning use cases are added.
When something does not work as expected, support includes reproducing the issue, identifying whether it relates to access, data, configuration, or model behavior, and coordinating a fix. The objective is not simply to close a ticket. It is to restore reliable use, record the resolution, and reduce avoidable repetition.
Optimization as requirements mature
Finally, ongoing support creates a structured way to improve the environment. Performance optimization, process improvement, and adoption support can be prioritized alongside maintenance rather than treated as occasional emergency work. That may mean refining an established workflow, improving documentation, or preparing the model for a carefully defined next use case. The scope should remain explicit, with changes reviewed against governance, data quality, and the needs of the finance and business teams using Pigment.
How the 24-hour SLA changes post-go-live support
After go-live, the value of Pigment admin support is not simply having someone available when a finance user encounters a problem. It is having a defined operating response when a model issue, access request, data problem, or planning deadline needs attention. Amvent describes personalized support as including a 24-hour SLA guarantee, project management, and structured communication. In practice, that changes support from an informal handoff into an accountable process.
The first step is intake. A finance team member should submit a request with enough context to assess it. Include the affected application or model area, users impacted, business deadline, symptoms, and any recent change. The support team acknowledges the request within the agreed 24-hour response window, confirms ownership, and identifies the issue type. It may be a question, defect, data or integration problem, access request, or proposed enhancement.
Triage determines what happens next. A failed import affecting a forecast cycle may require faster attention than a request to improve a report for a future planning round. A user-access issue may be routed to the appropriate administrator, while a model defect may require controlled investigation against the model and data-flow design established during implementation. Monitoring and performance management provide the foundation for that analysis, rather than forcing the team to diagnose every issue from scratch.
Communication is part of the service, not an afterthought. Finance stakeholders should know who is investigating, what is understood, what information is still needed, and when the next update will arrive. If an issue has broader operational impact, the support relationship should define an escalation path and identify the decision-maker for temporary workarounds, priority changes, or additional technical involvement. A clear incident process helps reduce disruption and improve recovery.
An SLA is a response commitment, not an unlimited scope promise. It does not mean every enhancement, redesign, training request, or new planning use case is automatically included or completed within 24 hours. Those items need to be scoped, prioritized, and scheduled separately. Clear boundaries protect the finance team from uncertainty and help the support provider focus urgent attention where it matters most: keeping the live planning process reliable while managing improvements deliberately.
In-house admin vs. managed services retainer: making the right call
The right operating model depends less on who owns the Pigment login and more on whether that owner can reliably handle the work around it. Ongoing administration may include model maintenance, user enablement, documentation, bug resolution, optimization, and adoption support. Those responsibilities become more demanding as planning expands beyond an initial use case or as business teams request changes more frequently.
Start by assessing three variables: internal capacity, planning scope, and change volume. An organization with a capable administrator, stable requirements, and a narrow planning footprint may keep most work in-house. A team supporting finance, revenue and operations, supply chain, and workforce planning may need a broader support model, particularly when several planning cycles overlap.
Comparing Pigment administration operating models | ||||
Model | Ownership | Strengths | Risks | When it fits |
|---|---|---|---|---|
In-house admin | Internal finance, FP&A, or business systems owner. | Immediate business context. | Single-person dependency and limited coverage. | Stable model and manageable request volume. |
Managed services | External Pigment specialists with named internal stakeholders. | Specialist depth and structured support. | Ownership can become unclear without defined approvals. | Limited internal bandwidth or expanding scope. |
Hybrid model | Internal owner sets priorities; partner supports defined workstreams. | Business context plus specialist coverage. | Handoffs can create duplicated work. | Teams building internal capability as planning expands. |
Match ownership to planning scope
Internal administration works best when the owner has enough time to maintain the model, respond to users, document decisions, and test changes. This is not always the same person who understands the business process. A finance leader may define the planning requirement, while a systems owner maintains the configuration and coordinates technical work.
Scope also matters. Connected planning often starts with a focused use case and expands over time. When a budgeting model grows into revenue forecasting, supply chain planning, or workforce planning, the number of stakeholders, dimensions, workflows, and dependencies grows with it. At that point, relying on informal administration can create avoidable bottlenecks.
Use change volume as the practical trigger
Change volume is often the clearest signal that the operating model needs to evolve. Occasional access updates and minor documentation changes may be manageable in-house. Repeated requests for new scenarios, model logic, integrations, permissions, or reporting workflows require a more deliberate intake and testing process.
A hybrid model is often a sensible transition. The internal team retains ownership of business priorities and approvals, while a specialist partner handles defined maintenance, complex configuration, optimization, or periods of unusually high demand. For a broader view of the service relationship, see this broader Pigment managed services overview. This article's focus is narrower: deciding who should perform and govern the day-to-day admin work after implementation.
Whichever model you choose, document the boundary. Name the internal decision-maker, define which requests require review, establish where changes are recorded, and specify how users receive support. Clear ownership protects the model from becoming dependent on one person and gives leadership a more reliable basis for expanding Pigment.
How to scope a post-implementation support agreement
A useful support agreement turns post-go-live administration into a defined operating model. It should make clear what the internal team owns, what the support partner handles, how requests are prioritized, and how changes move safely into production. The implementation record is the starting point: requirements, model and data-flow design, integrations, user acceptance testing, monitoring, and performance management should all inform the agreement. For context, the EPM implementation timeline can help stakeholders distinguish implementation work from the ongoing support model.
Define the objectives and model boundary. State which outcomes the agreement supports, such as reliable reporting cycles, model maintenance, user enablement, adoption, and controlled optimization. Document the Pigment applications, modules, dimensions, integrations, and planning processes in scope. Also record exclusions, including new planning domains or material redesigns that require a separate change request. This prevents a support retainer from becoming an undefined second implementation.
Assign ownership and access. Name the internal product owner, finance process owners, Pigment administrators, integration owners, and escalation contacts. Specify who approves access, model changes, and production releases. Use least privilege by limiting each user or process to the access needed for assigned tasks. Include an access review cadence and an offboarding process.
Create request tiers and SLA rules. Separate urgent incidents, time-sensitive planning-cycle issues, standard administration, and enhancement requests. For each tier, define the response target, required information, communication channel, business-hours coverage, and escalation path. A response SLA is not an unlimited delivery promise. The agreement should distinguish initial acknowledgement, diagnosis, workaround, resolution, and project-level work that needs separate planning.
Set a recurring administration cadence. Identify weekly, monthly, and quarterly activities such as user and access reviews, integration checks, model housekeeping, release preparation, documentation updates, and planning-cycle readiness. Tie each activity to an owner and evidence of completion. A recurring review is more useful than waiting for a user to report that a workflow or data load has degraded.
Define change control and testing. Establish how requests are evaluated, estimated, approved, tested, scheduled, communicated, implemented, and documented. Use a risk- and impact-based review to minimize service impact. Require a stated business owner, impact assessment, test evidence, rollback approach, and production approval for material changes.
Specify documentation and training deliverables. List the artifacts that must stay current, including model and integration diagrams, administrator procedures, release notes, known issues, access rules, and planning-cycle runbooks. Define who receives training, when refreshers occur, and how new administrators are onboarded. Documentation and enablement should reduce dependency on individual knowledge, not merely record that a handoff happened.
Agree on review measures. Review the relationship against operational measures such as request volume by tier, response performance. Recurring incidents, unresolved defects, completed access reviews, documentation freshness, adoption concerns, and upcoming model changes. Use the review to adjust priorities and boundaries as the organization expands from an initial use case toward connected planning. The agreement should make that evolution visible without quietly absorbing every new requirement.
Get in touch before the FAQ to discuss your post-implementation support model.
Frequently Asked Questions
What does Pigment admin support include after go-live?
It can include model maintenance, user enablement, documentation, bug resolution, performance optimization, process improvement, and adoption support. The exact scope should reflect your applications, internal ownership, and planning priorities.
Who should own Pigment administration internally?
Your organization should retain a clear internal owner for business decisions, access approvals, and prioritization. A specialist support partner can handle or support technical administration, maintenance, troubleshooting, documentation, and user enablement without replacing accountable business ownership.
How is ongoing administration different from emergency troubleshooting?
Ongoing administration is a planned operating rhythm that keeps the model reliable, governed, documented, and useful as requirements change. Emergency troubleshooting addresses an immediate disruption. A sound support agreement defines both routine requests and incident escalation instead of treating every issue as an emergency.
Does Pigment admin support cover new planning use cases?
It can, when expansion is included in the agreed scope. Many organizations start with a focused use case and extend connected planning across finance, revenue and operations, supply chain, or workforce planning over time. Each addition should be assessed for requirements, model design, integrations, testing, and ownership before delivery.
Ready to Keep Pigment Support Aligned
Effective administration keeps your Pigment environment responsive as planning needs, users, and processes evolve. If you are defining ownership or assessing the support required after implementation, Amvent Consulting can help you clarify the next practical steps.
Get in touch to talk with the team about Pigment admin support.
Get in touch to define your post-go-live support model.
Get in touch to discuss your next Pigment planning priority.
