Go-live is a milestone rather than a finish line, and the firms getting real value from DealCloud a year later are rarely the ones with the most elaborate configuration. Across more than 4,500 DealCloud projects and 1,400+ clients, what separates them is smaller and less glamorous than most firms expect: a handful of habits established in the first ninety days and then actually kept.
The drift that sets in without those habits is easy to understand. Your deal team goes back to deals, the person who ran the implementation still has a day job, and nobody ever makes a conscious decision to let the platform get stale. It happens quietly instead, one unreviewed queue and one duplicate record at a time, until somebody opens a report, does not quite believe the number, and goes back to the spreadsheet they were using before.
Once the project team steps back, the same handful of questions tends to surface. Below are the ones we hear most often from clients in their first few months on the platform, along with what we tell them.
Should our admin get DealCloud Platform Manager certified?
Yes, and earlier than most firms think to do it.
Platform Manager certification is Intapp’s program for the person who administers your site, and it covers the configuration layer you will actually be working in after go-live: fields, list views, report structures, permissions, and the day-to-day mechanics of keeping DealCloud aligned with how your firm operates.
What it buys you is independence. A certified admin adjusts a view, adds a field to a deal record, or reworks a report themselves, while an uncertified one files a ticket and waits for someone else to get to it. Across a year of small requests, that difference becomes the single biggest factor in whether your team experiences DealCloud as a platform that responds to them or as a system that never quite fits.
Two pieces of advice we give consistently here:
- Start with whoever led your implementation. They already understand why your site is built the way it is, and that context is most of what the certification assumes you bring.
- Certify at least two people. Firms that concentrate platform knowledge in a single person feel it sharply when that person changes roles or leaves, and rebuilding from scratch costs far more than training a second admin would have.
How do we build custom views that people actually use?
Out-of-the-box views are designed to serve everyone, which in practice means they are optimized for no one in particular. Custom views are where adoption is genuinely won or lost, because they determine what your team sees in the first five seconds after logging in, and a sourcing associate has almost nothing in common with a partner covering LP relationships in terms of what needs to be on that screen.
Build by seat rather than by department, and start with the handful of views your team would open every morning:
- A sourcing view filtered to active opportunities in the sectors and geographies that person actually covers, so the list reflects their universe rather than the firm’s.
- A coverage view sorted by last touch, so a partner can see immediately which relationships have gone quiet without running a report to find out.
- A live deal view showing active processes by stage alongside open tasks and next milestones, which is usually the view that carries your Monday pipeline meeting.
A few principles that hold up across firms:
- Use fewer columns than you think. The instinct is to include everything available, but a view that can be scanned in ten seconds gets opened daily, while a view with twenty-two columns gets exported to Excel, and that is how you lose the platform.
- Sort by whatever triggers action. Last activity date, days in current stage, next milestone. Alphabetical order tells nobody what to do next.
- Publish views centrally instead of letting everyone build their own. Agree on a naming convention early, decide who owns each shared view, and prune the ones nobody opens, because view sprawl is much easier to prevent at month three than to untangle at month eighteen.
What are Suggested Contacts, and why do they keep piling up?
Depending on how your activity capture is configured, DealCloud can watch your team’s email and calendar activity and propose new contacts your firm has started dealing with. It can also read email signatures and propose updates to people already in your system, flagging a new title or a changed phone number without anyone having to notice it themselves.
When the suggested contacts queue goes unworked, two things happen in parallel. Real relationships never make it into the platform at all, which means the relationship intelligence you invested in is missing exactly the connections that were forming most recently. And the signature-based updates sit unapplied, so titles and contact details quietly go stale on records your team is actively relying on.
That second problem carries more weight in private capital markets than people tend to assume. A contact at an LP moving from principal to partner changes how you approach your next raise, and a portfolio company CFO taking a role elsewhere is something you want to know before your next quarterly review rather than during it.
The fix is genuinely unglamorous: give one person the queue, put fifteen minutes on their calendar every week, and have them accept, reject, or merge what has accumulated. A queue worked weekly takes minutes. A queue left until the end of the quarter becomes a project everyone finds a reason to avoid.
How do we clean up duplicate records with Merge Entries?
Duplicates are not a sign that something went wrong during implementation. They are a normal consequence of a platform being used by more than one person, and they arrive from several directions at once: migration, where legacy systems held the same firm under three slightly different names; daily use, where two people enter the same counterparty a week apart; and your own fund structure, where a portfolio company contact ends up on separate records under two funds and a co-invest vehicle.
The real cost is not the clutter, it is the fragmentation. Activity history splits across records so nobody sees the full arc of a relationship, coverage looks thinner than it actually is, and reporting undercounts in ways that are hard to spot but easy to feel. Once your team stops trusting the numbers, adoption starts unwinding, and that is much harder to recover than the data itself.
Merge Entries consolidates duplicates rather than deleting them, bringing activity, relationships, and history together onto a single surviving record. A few things are worth doing deliberately:
- Decide which record survives before you merge, and default to the one with the richer activity history rather than the more recently created one.
- Work in batches by entity type so you are applying consistent judgment rather than making one-off calls across dozens of unrelated records.
- Spot-check a handful of merges before running a large set, since unwinding a merge is not always straightforward.
- Treat a repeating duplicate pattern as a process signal. Recurring duplicates usually point to a naming convention nobody agreed on, or two teams entering the same records independently, and cleaning the records without fixing that just means doing it again next quarter.
Then put it on a cadence, monthly if your volume is high and quarterly at a minimum. If the backlog is already large enough that a cadence will not catch up with it, this is work firms often hand off as a one-time data migration and duplicate cleansing project rather than absorbing it internally.
Should we sync entries to Intapp Data?
Intapp Data brings externally maintained firm and contact reference information into your site, so records are enriched and kept current from an outside source instead of depending entirely on your team to type it in and then remember to update it later.
The case for it is straightforward enough. Firmographic detail stays current without anyone chasing it, contact information refreshes on its own, and your analysts spend less time on research a data feed handles perfectly well and more time on the work only they can do.
Two things are worth settling before you switch it on. The first is scope, because this does not have to be all or nothing, and the sensible place to start is wherever your team’s manual effort is highest and external coverage is strongest. The second is precedence: decide what happens when external data conflicts with what your team has entered. Some fields you will want the feed to own outright, while anything reflecting your firm’s own judgment or relationship view should stay with your team. Making that call up front avoids the particular frustration of watching a carefully maintained field get overwritten by a sync nobody thought to scope.
Who owns the platform after go-live?
This is the question firms ask least often and should probably ask first, because implementations have a project owner while platforms frequently do not. The result is a site that works well on launch day and then slowly diverges from how the firm actually operates, not because anyone neglected it but because closing that gap was never anyone’s job.
Assigning a platform owner is one of the five indicators of successful DealCloud adoption we wrote about previously, and it remains the one many firms often skip. Name someone, give them real time on their calendar rather than goodwill time, and define the routing clearly so everyone knows what that person handles themselves, what goes to Intapp support, and what goes to an implementation partner.
A cadence that holds up well for most firms:
- Weekly: work the Suggested Contacts queue
- Monthly: run a duplicate check, and look at which shared views are actually being opened
- Quarterly: sit down and talk about what has changed in the business, and whether the configuration still reflects it
It also helps to watch a couple of honest adoption signals rather than the flattering ones. Login counts tell you very little, but activity captured per user tells you whether DealCloud has become part of how people work, and deals sitting in the same stage well past their expected window tell you whether records are being maintained or merely created.
The habit, not the launch
The reason these questions come up so reliably in the first few months is that none of them have anything to do with whether your implementation went well. They are all about what happens next, and getting value out of DealCloud is not something you achieve at go-live so much as a series of small decisions you keep making afterward.
None of it is difficult work. It is just easy to defer, and the cost of deferring compounds quietly.
If you would rather not carry that operational load internally, our Managed Platform Support team acts as a virtual platform administrator for firms, handling the queues, the merges, the view requests, and the reporting work that otherwise piles up on someone who already has a full-time role. And if you are not sure whether your configuration still fits the way your firm works today, our DealCloud services overview lays out where we typically start.
Reach out whenever you are ready.
