How to choose a CRM and automation implementation partner

Request a workflow before a tool list

A staged illustration explains an idea; it is not proof of a working integration. Ask whether the demonstration is synthetic, a preview, an internal deployment or the configuration being offered to you.

Give prospective partners the same scoping brief

A comparable brief describes the current process and a concrete failure, not a request to “install AI.” Explain where inquiries arrive, where customer records live, who prepares quotes and what happens after a call. Include the tools you must retain and the decisions that the business cannot delegate.

• One example of a request that went well and one that fell between tools, using redacted or synthetic information.
• The desired result for the operator: a complete brief, a reviewed note or a reliable next action.
• Known dependencies: provider access, account editions, existing integrations and ownership.
• The edge cases that matter: repeat contact, changed scope, duplicate event or unavailable recipient.
• The handover needed: training, documentation, maintenance responsibility and a safe way to pause.

This lets you compare the same outcome across proposals. A smaller offer may be better scoped; a larger one may include essential migration or support work. Ask what explains the difference before comparing headline fees.

Ask the agents to demonstrate distinct jobs

For a lead-handling scope, Figaro should show how an inquiry becomes a usable brief. Cyrano should show how a human call produces a proposed CRM update for confirmation. Hunter should show the evidence behind a campaign recommendation, with its approval boundary. These are different acceptance questions, not one generic AI demo.

If landing-page work is included, Leo can generate and revise a preview using approved website components; publication remains a separate reviewed action. Atlas is a development preview: approving an opportunity card records a decision, rather than publishing a page. Do not buy an automatic Atlas-to-Leo publishing promise on that basis.

Inspect the inquiry role.

Inspect the call-review role.

Inspect Leo preview and publication scope.

Inspect Atlas development-preview status.

Ask for evidence at each acceptance gate

Separate feature presence from operational readiness. Figaro producing a reply is one check; attaching it to the right inquiry is another. Cyrano drafting a recap is useful only when the person can verify it. Leo producing a preview does not prove that publication has been approved or tested on your site.

Worked example: accepting a Stretch Tent intake scope

Use a fictional event request with a missing location. The acceptance test should show the received request, the missing-detail response, a correctly linked CRM opportunity and the person who owns the next step. Then repeat the request and change the event date. Check duplicates, the existing conversation and whether old follow-up is suppressed according to the agreed rules.

The expected evidence is the resulting records and approved messages. A dashboard animation or an unreviewed generated reply is insufficient. No real customer needs to receive a test.

Compare two proposals around the same Stretch Tent example

Fictional procurement exercise. Neither proposal describes an actual Growth Control customer contract.

Proposal A offers a broad collection of agents and an attractive dashboard. Proposal B offers inquiry capture, brief completion and a human review queue, with explicit exceptions. Ask both providers to demonstrate the same returning customer requesting a second event. The test should show two event opportunities, preserved conversation context and a responsible person for the new quote.

Then change the date, leave the location uncertain and repeat the source message. Ask what is verified automatically, what needs the operator and how a failure is noticed. The preferred answer is not necessarily the one with the most automation. It is the one that can demonstrate the agreed result and explain its limits.

Finally, compare the ongoing work. Does the business retain account access and a usable record of the process? Is monitoring included? What counts as a new change rather than maintenance? Who checks a provider update? Record the answers with the proposal, rather than relying on a sales demonstration remembered differently by each person.

For Growth Control, the agent pages establish the public scope to discuss; they are not a substitute for acceptance of your actual installation. Planned Atticus and Atlas preview work should be identified as such before it appears in a delivery commitment.

Keep commercial terms and access responsibilities explicit

• Separate project fee, retained subscriptions, usage, management and future changes.
• Identify who owns the accounts and how the business obtains its records and documentation at handover.
• Record supported providers and edition/access dependencies. A logo on a diagram is not a confirmed customer integration.
• Specify monitoring, incident contact, covered response expectations and the process for changing rules.

Choose the smallest complete useful scope

A narrow pilot can be complete if the operator can use it, handle its exceptions and maintain its records. A wide list of unfinished agents is harder to accept. Compare the useful outcome and operating burden rather than the number of tools promised.

Define what support must cover.

Compare the full ownership cost.

Review Growth Control implementation and handover options.

Questions and answers