How CoreShift
onboards customers.
Four phases, typically completed in 1-2 weeks for standard bots. No procurement cycle, no integration team, no statement-of-work negotiation. We learn your workflow, configure the bot, run dry runs together, and turn it on.
Discovery.
We learn your workflow. A single 60-90 minute call, sometimes with a short follow-up.
We're not interviewing you about your "digital transformation goals." We're learning four concrete things:
- What inputs trigger the work — emails, calls, system events, manual handoffs.
- What outputs you need — responses sent, records updated, PDFs assembled, alerts raised.
- Where decisions need a human — approval gates, judgment calls, escalations.
- What integrations you already have — Twilio, Outlook, your CRM, your accounting system.
By the end of Discovery, we both know whether one of our bots is a fit, what configuration it'll need, and what we'd skip. If we don't think it's a fit, we say so on the call.
Configuration.
We set up your tenant on our platform, configure the bot's behavior to match what we learned, and wire integrations to your accounts.
-
Tenant schema provisioned.
Your own isolated database container, named for your company. Other customers' data is invisible to bots running for your tenant. See the security model →
-
Bot configuration written.
Scope rules, thresholds, templates, routing, escalation paths — everything the bot needs to behave like an extension of your team. Stored in a versioned config we can roll back.
-
Integration credentials securely stored.
Your Twilio number, your Outlook mailbox, your CRM API key. Each lives in a per-tenant secrets path scoped to your tenant only.
-
Telegram operator channel set up.
Alerts to your phone for approvals, escalations, and anything the bot wants you to weigh in on. You decide who's on the channel.
Training & dry runs.
We run real workflows through the bot with you watching. You see exactly what it would have done in production.
Two to four dry runs is typical before go-live. We tune anything that doesn't match your judgment — a vendor it routed wrong, a threshold that was off, a template that sounded too formal or too casual.
Dry runs use real data flowing through your real systems, but the bot's outbound actions are intercepted and shown to you for approval rather than fired automatically. You see the email it would have sent, the SMS it would have sent, the record it would have updated. Approve, reject, or edit and re-run.
By the end of Phase 3, you've watched the bot handle the work your way, and you've seen the audit log capture every step.
Go live.
The bot starts handling real inbound traffic.
We monitor closely for the first week — eyes on every escalation, every edge case, every "huh, that's weird" moment. After the first week, monitoring tapers to weekly check-ins for the first month, then to as-needed.
You have direct contact with the engineer who configured your bot. Not a support queue, not a ticketing system. When you have a question, you message the person who knows your bot.
After go-live.
We refine the bot's behavior based on what you see in production. Most refinements — new templates, new vendors, new thresholds, new approval routing — are configuration changes that deploy without downtime.
Major behavior changes (a new state in the workflow, a new integration, a new escalation path) go through a brief dry-run period before activating. Same shape as initial onboarding, compressed.
If you want a second bot, the same four phases repeat — usually faster the second time, because we already know your business, your integrations, and your judgment.
Two places to go from here.
The platform architecture, how data isolation works at the database level, and step-by-step walkthroughs of two bots in motion (bid and contract review).
A short email with one paragraph about your business and the workflow you'd like to offload. We respond honestly about fit, timeline, and what onboarding would look like.