The kickoff bottleneck

If you run a small-to-midsize Salesforce consultancy, you probably have this pattern: a new client arrives, and you still need to find someone who can run discovery. The team member needs enough architecture depth to catch integration dependencies and technical debt before the project timeline shifts.

If you close one or two new clients a quarter, this is usually manageable. You book a senior architect, they spend a week on discovery, and the project moves forward. If you are closing 5-10 deals, most of your qualified staff is already on delivery. You end up delaying the new project, pulling delivery capacity, or assigning a junior resource and hoping critical risks are not missed.

That pattern is common. Teams close a deal, then spend 2-3 weeks trying to staff discovery. By the time they find a slot, timeline commitments are already delayed, and the internal champion has often moved on.

What discovery actually involves

The traditional workflow looks like this: a senior architect spends 5-10 days on discovery. They interview stakeholders, click through the org in Setup, document what exists, draft an architecture proposal, and write up a statement of work.

The issue is not simply finding time. Most discovery is repetitive inventory work: clicking through objects and fields, documenting workflows and Process Builders, mapping integrations, and recording what automation exists. In many projects that is 6-8 hours of expensive headcount, and it is mostly documentation, not architecture.

Then there is the human knowledge gap. In a typical org that has run for years, few people still know exactly what is live in production. The person who built "Opportunity_Renewal_Automation_v3_FINAL" may have left the team. In this case, they left 18 months ago. There is no documentation. The name implies renewal work, but the automation was also creating tasks, updating account ownership, and calling custom Apex into Slack. Debug logs showed no executions in six months. The right question was not "can we delete it" but "do we break something if we do."

According to Salesforce's State of IT report, 57% of IT leaders say integration complexity is their biggest technical challenge. But most discovery processes don't systematically inventory integrations - they ask stakeholders to remember them, which is how you miss the fact that the client's ERP sync uses a scheduled Apex job that will conflict with the new CPQ logic they want.

How Kickoff Insights changes this

Instead of spending 6-8 hours manually documenting what exists, we connect to the org and extract all the metadata automatically. Objects, fields, workflows, Process Builders, Flows, Apex classes, integrations, API usage, governor limit consumption - everything the Metadata API and Tooling API can surface.

We parse this into a structured inventory. Now when the architect talks to stakeholders, instead of asking "tell me about your Salesforce setup," they can ask specific questions: "I see you have a workflow updating Account ownership when Opportunity stage changes - is that for renewals or something else?"

The split is intentional: AI handles documentation. The architect handles business context, risk framing, and solution design. Those are the parts that require human judgment.

The workflow is usually three days:

Day 1: Automated metadata extraction. We pull everything from Salesforce plus connected systems (NetSuite, HubSpot, custom APIs, and others). The AI converts this into an inventory of objects, relationships, automations, and external integrations.

Day 2: The architect reviews the inventory and runs focused stakeholder interviews. They can ask precise questions because they already know what exists. They flag risks such as API limits, deprecated features, and automation conflicts before design work starts.

Day 3: The architect finalizes design, and we generate documentation: architecture diagrams, effort estimates, risk briefs, and test plans. Everything is written in plain language. Diagrams show current versus proposed state. The risk register explains what could fail and how to mitigate it. Estimates are T-shirt sized (S/M/L), not overfit precision like "47 hours".

A real example: retail omnichannel

We ran this for a consultancy with a mid-market retailer running omnichannel operations: stores, ecommerce, marketplace integrations (Amazon, Walmart), and a loyalty program. The client wanted to move to Salesforce Commerce Cloud and Service Cloud.

The original plan was 10 days of discovery starting with broad stakeholder interviews. The team was already tight on their Q1 delivery schedule, and senior architects were fully booked.

Day one surfaced:

340 custom objects across the main Salesforce org, plus separate orgs for Commerce and Community Cloud that weren't properly documented
47 active Process Builders, 23 Flows, 61 Workflow Rules - a lot of automation nobody could explain
12 external integrations: the documented ones (Shopify, Amazon MWS, loyalty platform), plus several undocumented ones including a custom middleware app that synced order data and a legacy system that turned out to be their warehouse management system
API usage showing they were hitting 80% of daily limits, mostly from a scheduled job that ran every hour to sync inventory

The warehouse integration was the critical find. It wasn't in any documentation. When the architect asked about it during stakeholder interviews (because it showed up in the metadata scan), it turned out to be essential - it updated inventory availability in real-time, and the retail operations team depended on it. If they'd missed this and built the new omnichannel solution without accounting for it, the project would have blown up mid-implementation.

The other big issue: those 47 Process Builders. Most weren't documented. Some were clearly deprecated (last modified 3+ years ago, not triggered in months), but nobody wanted to commit to deleting them without understanding what they did. We flagged the ones that touched objects relevant to the omnichannel project - about 15 of them - and the architect focused stakeholder interviews on those.

The risk register included:

API limit headroom (they were already at 80%; new integrations would push them over)
Undocumented warehouse integration that needed migration planning
Process Builders that might conflict with new order management flows
Data quality issues in the loyalty object (duplicate customer records, inconsistent email formats)

Armed with this, the architect ran focused two-hour design sessions instead of open-ended discovery meetings. Stakeholder time shifted from explaining existing systems to prioritizing solutions.

Total discovery time was 3 days instead of 10. The architect spent roughly 12 hours across inventory review, interviews, and design finalization. The consultancy delivered the SOW on schedule, and the client used the risk register to address issues they had not identified before.

Why this is actually useful

The value is not about replacing architects. It is about giving architects back the time spent on high-judgment work.

A senior architect's time is expensive and scarce. If they spend 60% of discovery just documenting what already exists, that's waste. The AI handles documentation. The architect handles design decisions, risk assessment, and client communication.

We've run this workflow on about 40 kickoffs so far. The results:

Kickoffs finish 68% faster (3 days vs. 9 days on average)
Delivery teams accept 2.5x more opportunities, because the handoff is clearer and risks are documented upfront
Rework rate in the first sprint drops to under 2%, because integration dependencies are caught in discovery instead of mid-build

That last number is the important one. Miss a critical integration dependency during kickoff and you typically discover it three weeks later, during deploy, when a batch job fails or a connector cannot support the target flow. At that point the team is already staffed and the client is expecting delivery, so the remediation is expensive.

Research from the Standish Group's CHAOS report shows that inadequate requirements gathering is one of the top three reasons software projects fail. Better discovery directly reduces downstream rework.

What this doesn't do

AI does not replace experienced architects. If no one on your team understands Salesforce architecture, you still need that expertise.

It also doesn't work well for highly customized industries where business context is everything. If you're doing health insurance claims processing or financial services compliance, the metadata scan gives you the technical inventory but misses all the domain-specific nuance. You still need someone who understands the industry.

The workflow still surfaces ugly org reality. If the client's org is a disaster, with hundreds of unused fields, automations nobody understands, and undocumented integrations everywhere, the tooling will show all of it, and you still have to deal with it. Sometimes the right answer is "clean this up before building anything new," which is an awkward conversation. That conversation is better during discovery than mid-implementation.

Also, if your typical projects are small and straightforward (basic Sales Cloud implementations, simple integrations), manual discovery may still be sufficient. This workflow is more useful for complex projects with multi-cloud designs, many integrations, and existing technical debt.

What makes this different

Most "AI for Salesforce" tools are either Einstein features or general chatbots. This approach uses the Metadata API and Tooling API to extract structured data and translate it for people to use. The AI does data processing at scale. Architecture decisions stay with the team.

The architect still does architecture work. They review the inventory, talk to stakeholders, make design decisions, sign off on the blueprint. We just remove the part where they spend hours clicking through Setup and transcribing what they find.

If you're interested in the technical details of how Salesforce metadata can be extracted and analyzed programmatically, the Salesforce DX Developer Guide covers the tooling.

Getting started

If you are scaling discovery without adding senior architects, this is a practical approach. We can run it on an incoming project and check the results against your current process.

The pricing is per-kickoff, not subscription. Essentials tier ($999) gets you the metadata scan and risk scoring. Professional ($2,499) adds architect curation and client-ready deliverables. Enterprise ($5,999) includes architect-led workshops.

Most consultancies start with Essentials to see the output quality, then move to Professional for client-facing projects where the deliverables matter.

See the kickoff packages or reach out to schedule a walkthrough. We can show you the actual metadata extraction output and talk through how it would work for your typical client profile.

How We Deliver Salesforce Architect Kickoffs in 3 Days