How to choose an AI implementation partner, without guessing.
Choose an AI implementation partner by testing four structural things before you look at anything else: whether they will prove the system on your real data before you pay, whether they quote a fixed fee against a written scope, whether you own the source code and prompts at handoff, and whether the person who scoped the work is the person who builds it. Those four answers separate builders from resellers faster than any credentials review, because each one moves risk from you onto them. Everything after that is fit: does this partner know your systems, your regulatory constraints, and your industry's actual bottlenecks. And the first decision is not which partner. It is whether to hire one at all this year.
Written for owners and operators at $8M to $50M companies who have been pitched AI four times this quarter and cannot tell the vendors apart. No shortlist, no scorecard template, no vendor of the year. Just the decision, laid out the way it actually happens.
The short answer.
There is no shared vocabulary in this market. Different companies will pitch you "AI implementation" and mean quite different things by it: a strategy engagement that ends in a slide deck, a reseller relationship for someone else's software, a staff-augmentation contract billed by the hour, a professional services add-on inside a platform you already pay for, and a fixed-fee build that ends with a system in your cloud tenant. The word is identical. The thing you receive is not.
So the useful first move is not to compare vendors. It is to decide which of those things you are actually buying, because that determines who is even in the running. A company that needs one expensive workflow fixed inside its existing stack should not be talking to a firm whose deliverable is a transformation roadmap. A company with no named internal owner and undocumented data should not be talking to anybody yet.
Once you know the category, the vendor comparison collapses to four structural questions, all of which are answerable in the first call and none of which require you to understand model architecture. Will you prove it on my data before I pay you. Is the fee fixed against a written scope. Do I own the code when it ends. Who personally does the work. A partner who answers all four cleanly has put their own money behind the estimate. A partner who deflects on any of them has quietly kept the risk on your side of the table, and that is the number one predictor of the month-four stall this industry is famous for.
Below: the six paths open to you and who each one genuinely fits, the questions worth asking, how to scope a pilot that can actually fail, what ownership means in practice, honest cost bands, and the cases where the right answer is to hire nobody.
Who actually builds it, and who each option fits.
Fits when: you already have an engineering organization for them to sit inside, a roadmap that stretches past a single project, and the patience to wait through recruiting, onboarding and ramp before the first system ships. Companies with a real product engineering team usually should hire.
Where it breaks: a single hire has to cover data engineering, integration work, model selection, security review and the change management of getting colleagues to actually use the thing. That is three or four jobs. At a company with no existing engineering bench, the hire spends the first two quarters building the scaffolding a specialist firm would have arrived with, and the cost of that delay is rarely counted in the salary comparison.In-houseNeeds an eng org
Fits when: the decision needs board or private-equity air cover, the rollout spans multiple business units or countries, or your procurement process genuinely requires a name it recognizes. That is a real requirement in some organizations and it is not irrational.
Where it breaks: engagements are sized for enterprises. The people who sold the work are frequently not the people who staff it. And the strategy deliverable and the build are usually two separate purchases, which means a mid-market company can spend its entire AI budget before a line of production code exists. If you are under $50M in revenue, you are below the size this model was designed for.EnterpriseSized for the Fortune 500
Fits when: your scope is genuinely unknown, you want ongoing capacity rather than one system, and you have someone internally technical enough to direct the work week to week. For companies with continuous product needs, this is a reasonable structure.
Where it breaks: a monthly retainer pays for duration, not for completion. That is not a moral failing, it is arithmetic, and it means the incentive to finish is weaker than yours. Generalist shops also tend to be new to your vertical, which means you fund their education in how insurance renewals or tax season or dispatch scheduling actually work. Ask how many systems they have shipped in your industry, then decide whether the answer justifies the tuition.RetainerPays for time, not finish
Fits when: the work lives entirely inside one system you already own and are committed to. Nobody knows that product's data model better, and the integration risk is close to zero because there is no integration.
Where it breaks: they cannot cross the boundary. If the expensive workflow starts in your phone system, passes through your CRM, and ends in your accounting package, a single vendor's services team can only address the middle third. What they build also lives inside their product, which deepens the switching cost you already carry. Worth using for in-platform work; worth being clear-eyed about for anything that spans systems. Our breakdown of what each ServiceTitan Pro add-on does, and where it stops walks through the boundary problem in one concrete case.In-platformCannot cross systems
Fits when: one or two expensive workflows cross two or three systems, the requirement is stable enough to write down, and you want to own the result rather than rent it. This is the model this firm operates, and the reason we prefer it is structural rather than ideological: a fixed fee puts the cost of a bad estimate on the builder.
Where it breaks: it requires a scope that can be written down. If you cannot describe the workflow you want fixed in two paragraphs, you are not ready to commission, and any firm that takes your money anyway is selling you a discovery phase with a build label on it. Specialists also have limited capacity, which means the good ones say no fairly often. That is a feature, but it does mean availability is a real constraint on your timeline.CommissionNeeds a writable scope
Fits when: your data lives in three systems that do not agree with each other, the process you want automated is still changing monthly, nobody internally has been given authority over the outcome, or the workflow simply is not expensive enough that fixing it would move a number you report to anyone.
What to do instead: spend the quarter on the prerequisite. Consolidate the data. Write the process down and freeze it long enough to be automatable. Name an owner. Try the packaged feature already sitting unused inside software you pay for. Every one of those is cheaper than a build, and each one raises the ceiling on what a build could achieve later. The AI maturity assessment is the fastest way to find out honestly which stage you are at.WaitOften the right call
Who should build our AI, an in-house hire, an agency, or an outside firm?
Hire in-house if you already have an engineering organization and a multi-year roadmap. Use an outside firm if you have one or two expensive workflows to fix now and no engineering bench. Use an agency retainer if the scope is genuinely open-ended and you have someone technical internally to direct it. The most common correct answer for a $10M to $50M operator with no engineering department is to commission the first system from outside, then hire someone to run and extend it once there is a real system for that person to own.
More detail
The hire-versus-outsource comparison is usually run badly, because it compares an annual salary against a project fee and stops there. That comparison is missing three costs on the hire side: the recruiting cycle for a role your existing managers cannot technically interview for, the ramp before the first shipped system, and the risk concentration of putting a novel capability inside one person who can resign. It is also missing an advantage on the hire side that project fees never capture, which is that an employee accumulates institutional knowledge about your operation permanently.
The sequencing argument resolves most of it. A first commissioned system gives you three things a job posting cannot: proof that the workflow can be automated at all, a running codebase for a future hire to inherit rather than start from, and a realistic sense of how many internal hours a rollout actually consumes at your company. Companies that hire first frequently discover in month five that the hard part was never the model, it was that the data lived in four places and nobody had authority to change any of them.
The opposite case is real too. If AI is going to be inside your product rather than inside your back office, or if you expect to ship a dozen systems over three years, the economics flip and the hire wins clearly. We wrote the full comparison in internal AI hire versus commissioned build, and the argument for sequencing specifically is in the case for commissioning before hiring a head of AI.
What should I ask an AI implementation partner before signing?
Ask nine questions and pay attention to which ones produce a straight answer: will you build a working prototype on our real data before we pay you, is the fee fixed against a written scope, who owns the source code and prompts at handoff, whose cloud tenant does the system run in, who personally writes the code, what happens if the scope was estimated wrong, which of our systems have you integrated with before, what does your handoff package contain, and what specifically would you refuse to build for us. The last one is the most diagnostic, because a firm that cannot name work it declines has no operating point of view.
More detail
Will you prove it on our data first. A demonstration on the vendor's sample data proves the vendor can produce a demo. A prototype on your actual documents, call recordings or work orders proves they understood your operation well enough to build against it. This firm builds a working prototype inside seven to ten days before any fee changes hands, and the reason is not generosity, it is that it is the only honest way to find out whether the build is feasible before either party is committed.
Is the fee fixed, against what document. Fixed fee is a claim that means nothing without a written scope attached to it, because a fixed fee against a vague scope is just a change-order pipeline with a friendlier opening number. Ask to see the scope document format before you sign anything.
Who owns the code, the prompts and the fine-tuning data at handoff. Ask it in exactly those words and listen for hedging. Answers involving perpetual licenses, hosted runtimes you cannot leave, or per-seat fees mean you are buying a dependency.
Whose cloud tenant. A system that runs inside your own AWS, Azure or Google tenant under NDA is a system you can audit, migrate and keep. A system that runs inside the vendor's infrastructure is a subscription with a custom skin.
Who personally does the work. The most common structural disappointment in consulting is that senior people sell and junior people deliver. In domains with real operational nuance, and every regulated vertical is one, a misunderstanding about review hierarchies or trust accounting or renewal timing will quietly break an automation in a way nobody notices for a month.
What would you refuse to build. Firms with no refusals have no thesis. We publish ours at what we don't build, and any partner worth hiring should be able to give you their version verbally in thirty seconds.
If you want the security-specific version of this list, security questions to ask before an AI build covers data residency, model training on your inputs, credential handling and revocation at handoff. If you are running a formal process, how to write an RFP for a custom AI build has the document structure.
How do I scope a pilot that produces a decision instead of a demo?
Write down the pass and fail criteria before the pilot starts, and make sure failure is actually possible. A useful pilot names one workflow, one measurable baseline taken from your current operation, a fixed time box, and a specific threshold that determines whether you proceed. If there is no number and no date at which you would walk away, you have not scoped a pilot, you have scheduled a demonstration, and demonstrations always succeed.
More detail
The failure pattern is consistent enough to describe precisely. A company runs a three-month AI pilot with no baseline measurement, the vendor presents a polished walkthrough at the end, everyone agrees it was promising, and the decision to proceed or stop gets deferred to a committee that never reconvenes. Nothing was learned because nothing could have been disproven.
The fix is unglamorous. Before anything is built, measure the current state: how many hours per week the workflow consumes, how many items are handled, what the error or leakage rate looks like, how long the cycle takes end to end. Rough numbers are fine, they only need to be consistent. Then define what the system has to do to be worth continuing, in the same units. Then set a date.
Keep the pilot to one workflow. The temptation to bundle three use cases into a single pilot is strong and it is always wrong, because when the composite result is ambiguous you cannot tell which component worked. Keep the population real, too: run it against live volume rather than a curated sample, because curated samples are where accuracy claims go to be flattered.
Two more constraints worth writing into the pilot scope. First, decide up front who signs off, one named person, not a committee. Second, agree what happens to the work product if you decide to stop: a pilot that leaves you with nothing you can keep was a rental. How to run an AI pilot that produces a decision covers the full sequence, and if you have already been through one that went nowhere, what to do after a failed AI pilot is the postmortem version.
Who owns the code, the prompts and the data when the engagement ends?
In a commissioned build you should own all of it: source code, prompts, model configuration, datasets, integration documentation and the runbook, transferred at handoff, with the system running in your own cloud tenant. In a subscription or licensed arrangement you own none of it and your access ends when you stop paying. This is the single largest structural difference between the delivery models, and it is also the question most buyers forget to ask until renewal, when the answer stops being theoretical.
More detail
Ownership sounds like a legal detail and behaves like an operating one. Consider what changes when you hold the source code. You can have your own people or any third party read exactly what the system does with customer data, which turns a trust question into an inspection question. You can move cloud providers without renegotiating. You can extend the system yourself when a workflow changes, rather than filing a feature request into a queue you do not control. You can walk away from the firm that built it and keep the asset. And your ongoing cost stops scaling with headcount, because there is no seat to license.
Compare that with the rented version. A per-seat AI product priced at $60 to $100 per user per month across a seventy-person firm is $50,000 to $84,000 a year, forever, rising with headcount and with the vendor's pricing decisions. The system is not yours, the data path is theirs, and the switching cost compounds every year you stay. For some categories that trade is completely correct: nobody should commission a custom email client. For a workflow specific to how your firm actually operates, the arithmetic points the other way, and it points harder every year you keep growing.
Ask for the handoff package contents in writing before you sign, not at the end. It should name the repository, the documentation, the credentials transfer, and the training sessions. A build that ships without documentation is a build only its author can maintain, which quietly recreates the dependency you were trying to avoid. Why code handoff matters covers what a complete package looks like, and off-the-shelf AI versus a custom commission runs the total-cost comparison over a realistic horizon.
What does an AI implementation partner cost in 2026?
For a mid-market company between $8M and $50M in revenue, the realistic bands are $45,000 to $180,000 for a fixed-fee custom commission from a boutique like this one, $35,000 to $150,000 from other boutique specialists, $150 to $500 per hour from independent consultants, $300 to $1,000 per hour from mid-tier firms, and $400,000 to $1.4 million for large-firm strategy work with implementation quoted separately on top. The structure of the price tells you more than the number does, because hourly billing pays for duration and a fixed fee pays for completion.
More detail
Inside the fixed-fee model, price tracks scope rather than effort. A focused build addressing one clearly defined system runs $45,000 to $65,000 over roughly four to five weeks. An operations rebuild covering a multi-step workflow with cross-system integrations, dashboards and alerting runs $75,000 to $120,000 over six to eight weeks. A platform commission coordinating several systems with a custom interface for your team runs $140,000 to $180,000 over ten to fourteen weeks. This firm prices in two installments, one when the production build starts and one at handoff.
The costs buyers routinely forget are internal, and they are not small. Somebody at your company has to answer questions, approve API access, wrangle credentials out of an incumbent vendor who would rather you did not integrate, sit in review sessions, and drive adoption afterwards. Budget real hours for that person. The projects that stall almost never stall on the build; they stall waiting on an internal approval that nobody owned.
Then there is the ongoing line. Ask what happens after handoff and what it costs. Optional stewardship here runs $4,000 per quarter for light monitoring and tuning or $9,000 per quarter for active support, both cancellable on thirty days' notice, and a company with internal technical capacity can decline it outright because it owns the code. What you want to avoid is a support arrangement you cannot leave.
Two sanity checks on any quote. If a firm quotes a large number before understanding your workflow, they are pricing the category, not your problem. If a firm quotes a very small number for something that touches three systems, they have not read the integration surface yet and the number will move. Published bands are at pricing, the vertical-by-vertical breakdown is in what a mid-market AI engagement costs, and the model comparison is in AI consulting pricing models explained.
How do I verify a partner's claims when the best specialists are small and new?
Ask for one client you can actually telephone, and ask that client what broke, how long the fix took, and who answered the phone. Then ask the partner for a production number, something that only exists if a system is genuinely running in the world, and check whether their published claims are specific enough to be falsifiable. Vague superlatives and unnamed case studies are worth nothing; a named reference willing to take your call is worth more than a page of logos.
More detail
This is the awkward part of the market. The specialists with the deepest knowledge of your vertical are often small and relatively new, because the practice area itself is new. That means the usual trust proxies, decades of history and a wall of enterprise logos, are frequently unavailable from exactly the firms most likely to do good work. You need different evidence.
The strongest substitute is a reachable reference plus a live production number. To make the standard concrete, here is ours. Jim Glaser Law runs five channel-specific AI voice agents commissioned by this firm, one each for PPC, Organic, TV, Meta and LSA, which gives the firm per-channel attribution on answered calls rather than guesses. Those agents have handled 3,787 calls totalling 5,514 minutes. Jimmy will take a reference call and has referred work. Under anonymity, a multi-location home services operator is at 1,486 AI-handled calls and 2,203 minutes, a regional third-party logistics and warehousing operator at 211 calls, and a realty firm at 148, for at least 6,000 live calls handled across clients. A 47-attorney litigation firm runs its matter, invoice and IOLTA trust system on a commissioned platform: 13,296 matters, 4,396 clients, 5,684 invoices, with trust reconciled byte-identical against the prior system. Two marketing agencies outsource their AI fulfillment here.
Those numbers are given not as a boast but as a template for what to demand from anyone you are evaluating, including us. Notice what they are: counts from live systems, attached to a named client who will pick up the phone, or to a described client specific enough that a lie would be traceable. If a firm can only offer percentages with no denominator, unnamed clients in unnamed industries, or outcomes stated as ranges with no baseline, you are reading marketing, not evidence.
Two extra checks that cost nothing. Ask the reference what happened when something broke, because every system breaks and the useful information is in the response time and who answered. And ask the partner to walk you through a build they would consider a mistake in hindsight. A firm with no such story either has not shipped enough or is not being straight with you.
How these engagements actually go wrong.
The month-four stall.
The most common shape of failure is not a system that does not work. It is a system that works, gets deployed, and then quietly stops being used somewhere around the fourth month. Nobody declares it dead. Usage just declines until the tool is a browser tab nobody opens.
The causes are almost always organizational rather than technical. The person who championed it changed roles. The workflow it automated was redesigned by a different department that did not know the system existed. The exceptions the system could not handle were never given a path, so staff routed around it entirely and then stopped coming back. Nobody owned the numbers after go-live, so the decay was invisible until someone asked a question at a quarterly review.
The preventable version has three parts, all decided before the build starts. Name one internal owner with authority, not a committee. Agree what gets measured after launch and who looks at it monthly. And design the exception path explicitly, because the ten percent of cases the system cannot handle is where adoption is won or lost. We wrote the long version in why mid-market AI rollouts stall in month four.
The integration nobody actually checked.
A large share of overruns trace to one assumption made in the first week: that the systems involved can talk to each other in the way the scope implies. Sometimes the API exists but is read-only where you need to write. Sometimes it exists but your license tier does not include it. Sometimes it exists, includes writes, and your incumbent vendor takes six weeks to approve the credentials because your integration reduces their leverage.
The mitigation is to verify integration surface before signing, not after. A serious partner will name the specific endpoints, the auth method, the rate limits and the license tier required, in writing, in the scope. If they wave at it with the phrase "we integrate with everything", that is not confidence, it is an unpriced risk sitting on your side.
This is also the reason platform-specific depth matters when you choose. Reading how a partner describes a system you already run is a fast competence test: our integration playbooks exist for exactly that purpose, and if the vendor you are evaluating cannot produce the equivalent detail about your stack, they have not done the work yet.
The data was not ready and nobody said so.
AI systems inherit the quality of what they read. A retrieval system built over a document store with inconsistent naming, duplicate records and five years of drift will produce confidently wrong answers, and it will do so in a way that looks like a model problem when it is a filing problem.
The honest partner surfaces this during the diagnostic and prices the remediation as part of the work, or tells you to fix it first and come back. The unhelpful partner builds anyway, ships something that technically satisfies the scope, and leaves you to discover the accuracy ceiling in production. You can protect yourself by asking one question early: what would have to be true about our data for this to work, and is it true today.
Data readiness for mid-market AI covers the specific checks worth running before you commission anything, and it is deliberately written so you can run them without a consultant present.
Ownership discovered at renewal.
A company commissions what it believes is a custom build, uses it happily for a year, then tries to move it to a different cloud provider or hand maintenance to a new internal hire. At that point it learns that the "custom" system runs on the vendor's proprietary runtime, that the prompts are considered vendor intellectual property, or that the contract grants a license rather than transferring ownership.
Nothing in that story requires bad faith. It usually just means the question was never asked in plain words at signing. Ask it in plain words: at the end of this engagement, do we own the source code, the prompts, the model configuration and the data, and does the system run in our tenant. Then get the answer in the contract rather than in an email.
Red flags on the first call.
A short list, all of them observable before you spend anything. The pitch leads with model names rather than with your workflow. There is no prototype offered on your data at any price. The fee is hourly with an open-ended estimate. Nobody can tell you who will write the code. Ownership questions get answered with the word "access". Every question about limits is answered with enthusiasm. The proposal includes a discovery phase priced like a build but delivering a document. Case studies name no client and no number. They cannot describe a project they turned down.
One more, easy to miss: urgency manufactured on the vendor's side. Pricing that expires this month, capacity that will vanish next quarter, a competitor supposedly about to sign. Real capacity constraints exist, this firm caps engagements per quarter for delivery reasons, but a genuine constraint is stated as a fact and a manufactured one is stated as a threat. You can tell the difference by asking what happens if you decide in ninety days instead.
Green flags, for balance.
The inverse list is shorter and more useful. They ask about your workflow for most of the first call and about AI for very little of it. They tell you which parts of the problem software you already own could handle, at the cost of their own scope. They put a number on what they do not know. They name a build they would not take. They offer a reference and do not curate which questions you may ask. They can describe how the system fails and what happens when it does, because every system fails and only people who have shipped know the shape of it.
And the strongest signal of all: they are willing to tell you the right answer is to wait. A firm whose revenue depends on the answer being yes, and which says no anyway, has given you real information about how they will behave once you are a client.
Frequently Asked Questions
What is an AI implementation partner?
An AI implementation partner is the outside party that actually builds and deploys a working AI system inside your operation, as opposed to an advisor who produces a strategy document. The category covers systems integrators, generalist development agencies, platform vendors' professional services arms, and specialist commissioning houses. The distinction that matters when you are comparing them is whether the engagement ends with a running system you own, or with a deck, a license, or a retainer.
How much does an AI implementation consultant cost?
For a mid-market company in the 8 million to 50 million dollar revenue band, expect roughly 45,000 to 180,000 dollars for a fixed-fee custom commission, 35,000 to 150,000 from other boutique specialists, 150 to 500 per hour from independent consultants, 300 to 1,000 per hour from mid-tier firms, and 400,000 to 1.4 million for large-firm strategy work with implementation quoted separately. The pricing structure tells you more than the number does.
Should we hire an in-house AI engineer or use an outside implementation partner?
Hire in-house when you have a multi-year roadmap, an existing engineering organization to absorb the person, and the patience to wait months for the first shipped system. Use an outside partner when you have one or two expensive workflows to fix now and no engineering bench to support a hire. Many companies do both in sequence: commission the first system, then hire someone to run and extend it once there is something real to own.
How long does an AI implementation take?
A single focused system typically runs four to five weeks of build time. An end-to-end workflow rebuild that crosses two or three systems runs six to eight weeks. A multi-system platform runs ten to fourteen weeks. Add one to two weeks before that for a working prototype, and budget separately for the slowest variable in every project, which is getting API credentials and data access approved inside your own company.
What are the biggest AI implementation challenges?
In order of how often they actually sink projects: no named internal owner with authority to make decisions, fragmented or undocumented data, a process that changes faster than it can be automated, integration surfaces that were assumed rather than verified, and adoption failure because the people doing the work were not consulted during design. Model quality is rarely the binding constraint.
How do I check references if the best specialists are small and new?
Ask for one live client you can call, not a logo wall, and ask that client three specific questions: what broke, how long the fix took, and who answered the phone. Then ask the partner for a system metric from live production, something that only exists if the system genuinely runs. A shop that cannot name a single reachable reference or produce one production number after a year of operating is telling you something.
Do we need an AI roadmap before choosing an implementation partner?
No. You need one expensive, well-understood problem and a named internal owner. Roadmaps commissioned before anything has been built tend to describe an imaginary company, because nobody yet knows what this organization is actually capable of absorbing. Build one system, learn what the rollout costs you in real internal hours, then write the roadmap with evidence in it.
When should we not hire an AI implementation partner at all?
When nobody internally owns the outcome, when the process you want to automate is still changing every month, when the workflow is not expensive enough that fixing it would change a number you report, when a packaged tool you already pay for would cover eighty percent of it, or when the data the system needs does not exist in retrievable form yet. In those cases the honest sequence is to fix the prerequisite first.
Book the 45-minute diagnosis.
Forty-five minutes on your workflow, not our capabilities. We name the step costing the most money, tell you whether a build is the right lever for it, and say so plainly when software you already own would do the job. Plenty of these calls end with a recommendation not to commission anything yet.
Where to look next.
If you are still deciding what kind of thing to buy, start with build, buy, or commission, which is the framework this whole page sits on top of, and what AI commissioning actually is if the word is new to you. The two questions framework is the fastest filter for deciding whether a given workflow is worth automating at all, and AI is not a tooling decision is the argument for why the org chart matters more than the model.
For the mechanics of an engagement: the commission process covers the five phases from first call through handoff and after, including the prototype built before any fee is owed, pricing publishes the bands so you do not have to ask, and how long a mid-market AI build takes sets realistic calendar expectations. Once something is live, how to measure ROI on a mid-market AI engagement covers what to track. If you want the mid-market-specific version of this buyer's guide, how to choose an AI consultant for a mid-market company is the companion piece, and signs your business is ready for custom AI is the readiness check.
Most of this decision gets easier once it is specific to your industry, because the bottlenecks and the compliance constraints are not generic. There are vertical versions of this guide for CPA firms, insurance agencies, specialty manufacturers, home services platforms, and law firms. The longer vertical guides with the workflow detail live at AI consulting for CPA firms, regional insurance agencies, specialty manufacturers, PE-backed home services platforms, and mid-market law firms.
Comparing us against a specific alternative is a reasonable thing to do openly. Big Four AI consulting versus a boutique commission covers where the large firms genuinely win. Generic SaaS AI versus a custom commission is the honest version of when you should just buy the product. Off-the-shelf AI SaaS cost at scale runs the per-seat arithmetic over a few years, and AI governance without enterprise theater covers the oversight questions a mid-market company should actually answer. If you would rather see who you would be working with first, about is short and specific, and the FAQ answers the procedural questions we get most.