Process
How a project runs from first call to handover
Four steps: assessment, build, handover and support. You see a written scope before anything is built, and you can stop after the assessment.
Step 1
Assessment
A call, and sometimes a look at your busiest day, to decide whether automation is worth doing and where to start.
What we ask
Your channels, what customers ask, who replies now, the tools you use and the task that costs you the most. The automation assessment covers the same ground in a form.
What you receive
A written scope that says what will be built, what you provide, what stays with your people, and a line-by-line quote. See how pricing works.
Go or no-go
If automation is not the right move, or a simpler tool does the job, we say so. A project can stop here.
Step 2
Build
Built on your accounts
Assistants and workflows are set up in accounts that belong to you wherever the tool allows. Where a tool will not allow it, the scope says so before you approve.
Review checkpoints
You see the wording of the replies and the handoff rules before they go live and approve them.
Test conversations and test data
We test with your real questions and with test data, not live customers, and show you the results.
Step 3
Handover
Documentation
Written notes on what was built, where it runs, what it connects to, how to change the common settings and what to do when something fails.
Walkthrough for your team
A session with the people who will use it, covering the handoff alerts and how to correct an answer.
Access list
Who has access to which accounts, including ours, written down.
What you own
Your accounts, your customer data and conversation history, and the workflows built in your accounts. Tool subscriptions are billed by the vendors, not by us.
Step 4
Support
Optional, and quoted separately from the build.
What is covered
Set out in the quote: for example fixing breakages, updating answers and adjusting rules.
How changes are requested
By message or email to a named contact. Changes outside the support scope are quoted before they are done.
Monitoring and alerts
Where support includes monitoring, failed runs and unusual volumes raise an alert to us and to you.
What we need from you at each step
From you
- One decision maker who can approve the scope and the wording
- Access to the accounts and tools involved, given at the level the build needs
- Approved wording: the prices, policies and answers you want shared
- A person who receives handoffs
From us
- A written scope before any build
- Clear questions when something is unclear
- Tests shown to you before launch
- Notes your team can use without us
How we handle data during a build
Customer information is personal information under the Data Privacy Act of 2012 (RA 10173). This is how we build around it. The privacy notice covers the enquiry details you send us.
- Test data first: we build and test with sample data before any live connection.
- Least access: we ask for the access the build needs, no more.
- Removal of our access on request: at handover or on request, our access is removed and the access list is updated.
What we will not do
We will not
- Publish reviews, logos or case studies that are not real
- Let an assistant guess on complaints, medical, legal or negotiated-price questions
- Send bulk or unsolicited messages that break platform rules
- Reuse your customer list for anything outside your project
We will
- Tell you when automation is not worth it
- Explain the tools and costs in plain words
- Set things up in accounts you own where the tool allows
- Say what the assistant can and cannot do before you commit
Next step
Start with a call.
Tell us what you want off your team's plate. If it is not worth automating, we will say so.