The questions to ask any automation vendor, including us

Why the demo tells you almost nothing

Every automation demo works. It works because it was built to work, on prepared data, along a path the person demonstrating has walked a hundred times. That is not dishonest, it is just what a demo is.

The failures in this field are almost never that the thing did not work on day one. They are that it worked for four months and then quietly stopped, and nobody noticed until a customer complained. Or that it worked perfectly and only one person understood it, and that person left. Or that it worked and was so entangled with a vendor's platform that changing anything meant starting again.

None of those are visible in a demo. All of them are visible in the answers to a handful of unglamorous questions.

What happens when it breaks

Start here, because it is the question that separates people who have run systems in production from people who have built demos.

Everything breaks. An integration changes its API, a password expires, a supplier renames a field, somebody at your end deletes a form. The question is never whether, it is what happens next and how long it takes anyone to notice.

• How will I find out something has stopped working? The honest answers are monitoring and alerting. The bad answer is that you will notice when a customer tells you.
• Who gets contacted, and at what hour? If a booking system fails at six on a Friday evening, is there a route to a human, and what does that route actually cost you to have.
• What is the expected response time, and is it written down? A number in a document is a commitment. A friendly assurance is not.
• What breaks most often in builds like this? A vendor who cannot name three things has not run enough of them. The specific answer will be some combination of authentication expiring, upstream changes and edge cases in the data.
• What happens to work in progress when it fails? Does an enquiry that arrives mid-outage get lost, queued or fall back to a human? This is the question most people never think to ask and it is the one that costs real money.

What do I own at the end of this

This is the question that decides whether you bought an asset or a subscription. Both can be reasonable. Confusing one for the other is what makes people angry two years later.

• Whose accounts are these built in? If the automation platform, the phone number, the domain or the model access is in the vendor's account, you do not have a system, you have a service that could end.
• Do I get the code, the workflows and the configuration? Ask for it in a form you could hand to someone else, not a video walkthrough.
• Is there documentation, and can I see an example from another build? Documentation nobody wrote is the most common gap in this industry, and it is the one that hurts most in year two.
• Who owns the data the system produces? Conversation logs, enquiry records and customer information should be yours without asking, exportable without a negotiation.
• What is licensed rather than owned? There is almost always something, and that is fine. What matters is that it is named up front rather than discovered when you try to leave.

Is this being built, or configured, or resold

All three are legitimate. They have very different costs, timelines and failure modes, and a surprising number of buyers do not know which one they are getting.

Configuring an existing platform well is often the right answer, and an honest vendor will tell you when an off-the-shelf tool does the job. Building something custom is right when the workflow is genuinely yours and no product fits it. Reselling somebody else's white-labelled product is fine too, as long as you know that is what is happening, because it determines who can actually fix it.

1. Ask what this is made of. Name the platforms, the services and the models. A vendor who will not itemise the stack is either hiding a thin layer over a product or does not know.
2. Ask what would happen if one of those platforms changed its terms. The answer tells you how much of the risk sits with you.
3. Ask which parts you could have bought yourself. The good answer is honest about it, and explains what the build adds on top. If everything is off the shelf, you are paying for integration and judgement, which is a real thing to pay for, and it should be said out loud.
4. Ask whether they have built this exact thing before. First of a kind is not disqualifying. Being the first of a kind without being told is.

Who is actually doing the work

In a small industry with a lot of new entrants, this matters more than it should have to.

• Who writes the system, and will I meet them? Not the salesperson, the person whose hands are on it.
• Is any of it subcontracted, and to where? Subcontracting is normal. Undisclosed subcontracting is a data question as well as a quality one.
• What happens if that person is unavailable? A one person shop is not a problem in itself. A one person shop with no documentation and no second pair of eyes is a single point of failure you are inheriting.
• Can I speak to someone they built for? The answer should be yes, quickly, and the reference should be in a business that resembles yours. Be suspicious of a reference who cannot describe what was built in their own words.

What happens to my data

Anything touching customer records, conversations or documents has a data answer, and in Quebec it has a legal one. Vagueness here is a genuine risk rather than a stylistic preference.

• What is stored, where, and for how long? Ask for the retention period as a number of days or months, not as a policy sentence.
• Does customer data go to a model provider, and under what terms? This has a factual answer. Ask which provider, and whether the arrangement excludes training on your data.
• Who at the vendor can see it? And is that access logged.
• What happens on a deletion request? Under Law 25 you will get them. If the vendor has not thought about this, you are the one carrying the obligation.
• Where does it physically live? Not always answerable in the way people hope, but the vendor should know which providers and which regions are involved.

How will we know whether it worked

Most automation projects have no definition of success beyond the thing existing. That is how you end up paying for something that runs perfectly and changes nothing.

1. Agree the measure before the build. Response time to a new enquiry, hours spent on a task per week, the share of calls answered. One or two, and pick things you can already observe today.
2. Write down where you are now. Almost nobody does this, and without it every later conversation is a matter of opinion.
3. Agree what finished means for each stage. Not phase one complete, but every missed call receives a text within sixty seconds, verified over a full week.
4. Agree when you will look. A date in the calendar, not an intention.
5. Agree what happens if the measure does not move. This is the uncomfortable one and it is the one that separates a partner from a supplier.

What does leaving look like

Ask this in the first meeting. It is the single most informative question in this guide, partly because of the answer and partly because of the reaction.

Everybody is pleasant while things are going well. The shape of the exit is what determines whether a relationship that stops working can end cleanly or has to be endured.

• What notice is required, and what happens during it?
• What do I walk away with, in what format? A concrete answer names files, accounts and documents.
• Will the system keep running if I stop paying? The honest answer is often partly, because some third party services are ongoing. What matters is knowing which parts stop.
• Will you help my next vendor? A yes here says more about a firm than anything on its website.
• Is there any part of this only you can maintain? If so, name it now.

The answers that should end the conversation

Not everything on this list is fatal in isolation. Two or three together is a pattern.

• A guaranteed outcome. Nobody can guarantee a business result they do not control, and anyone offering one is either inexperienced or counting on you not to hold them to it.
• Urgency that comes from them rather than from you. A deadline invented by the seller is a sales technique, not a schedule.
• An unwillingness to name what is off the shelf.
• A demo you are not allowed to steer. Ask to type something unexpected into it. The reaction is informative.
• Reference customers who are all very recent. Anyone can be happy in month one.

How we answer these

It would be cowardly to publish this and not sit the exam, so here are our own answers, briefly.

When it breaks. Monitoring and alerting are part of every build rather than an upsell, and what happens to an enquiry during an outage is a design decision we make with you rather than a thing you discover. Response commitments are written into the arrangement.

What you own. Systems are built in your accounts, on your infrastructure, with documentation you could hand to another firm. Anything third party is named before we start. There is no platform you are locked into and nothing that stops working because you stopped working with us, other than the third party services you would be paying for regardless.

Who does the work. A founder is on every build. You will meet the person whose hands are on it, because in a shop this size that is not a favour, it is just how it works.

Your data. Retention, access and deletion get decided in writing before anything is built, and Law 25 is designed in rather than added afterwards. We publish on the subject, which is a reasonable thing to hold us to.

Measurement. We agree the measure and the current baseline before the build, and we do not publish client performance figures, which cuts both ways: it means we will not show you somebody else's numbers as evidence, and it means yours stay yours. What we will do is put you on a call with a client.

Leaving. You keep everything, we will hand over to whoever comes next, and there is no part of a build only we can maintain. If there ever were, we would tell you before you signed.