Help and frequently asked questions

SolaroCall is a configurable AI Phone Agent and intelligent business assistant. It can answer incoming calls, use the approved information you provide, follow your business rules, organize supported actions such as appointments or requests, and route conversations to the right next step.

SolaroCall is designed around the reality of your profession rather than a single generic call script. Its natural voice experience connects to structured services, schedules, staff, resources, service areas and rules that you control. The result is an advanced, adaptable AI Phone Agent system that can evolve with your business while keeping important commitments and human decisions under your control.

No. A basic answering bot records a message or follows a fixed menu. SolaroCall can understand supported caller intents, consult current structured business data, ask relevant questions, apply configured rules and carry out authorized actions. Its exact behavior still depends on the capabilities and information you enable.

SolaroCall must not falsely present itself as a human employee. You can configure a clear, professional introduction that identifies the assistant appropriately while keeping the conversation natural and welcoming.

SolaroCall is designed to handle repetitive first-contact work and help callers reach a useful next step. Your team remains responsible for professional judgment, sensitive decisions, exceptions and any task that requires a qualified human.

Yes. You begin with a profession-adapted configuration containing relevant services, resources, questions and workflows. The more accurate, structured and current information you approve, the more precisely the phone agent can answer and act. It never gains permission to invent facts that you have not supplied.

Your AI Phone Agent can be configured to answer day and night. You decide the active schedule, after-hours behavior, escalation rules and which actions remain available outside normal business hours.

Yes. You can update services, staff, schedules, rules and resources as your business grows. Plans offer different usage allowances. At launch, each account covers one establishment; a second establishment requires a separate account.

Use the business-type search on the homepage or the “another type of business” selector near the top of any profession page. Search by the localized business name or browse the alphabetical list, then open the matching page.

Open the business-type selector near the page heading and choose your actual profession. You can move directly to another published profession page without returning to the homepage.

The selector shows profession pages that are currently published and available for the active language. Try a related search term or another available language. If the profession is still unavailable, use the help journey to request assistance.

SolaroCall keeps the active language when the destination page is published in that language. If it is not available, the website must explain the available fallback before navigating and must not silently replace your saved preference.

Yes, but a profession change can affect services, questions, resources and workflows. SolaroCall must explain the impact and request confirmation before replacing incompatible draft configuration.

Open your profession page, listen to the available phone agent samples, choose a phone agent and select the test or setup action. SolaroCall preserves the profession, phone agent and eligible language as you enter configuration.

Yes. The standard Free Trial lets you test your phone agent with your business configuration before subscribing. Check the eligibility, time window and minute allowance shown when you start.

No. The quick test uses a small set of required facts so you can hear the core experience early. Advanced configuration can be completed progressively before production use. SolaroCall must clearly show which information is still required.

Yes, when another approved phone agent and compatible voice configuration are available. Preview the new voice, save the selection and test it before publishing the change.

Use the global header or footer. These shared navigation areas provide the current homepage, Pricing and other approved global destinations without trapping you inside a profession funnel.

Check that you are signed in to the correct business account before changing settings. At launch, one account covers one establishment. If you manage more than one establishment, use the separate account for the establishment you want to work on.

Check the relevant area of your signed-in account and your permissions. If the setting is still missing, note what you want to change and use the support link at the end of this page. Do not use browser tools to bypass an unavailable control.

Yes. Create your account and verify your email before continuing through the standard trial setup and eligibility checks.

No. Web, mobile and app use the same central SolaroCall account and tenant. Installing the app must not create a second onboarding path or require a second account.

Yes. Onboarding/configuration progress is server-authoritative and shared across supported signed-in devices.

Yes. The selected Phone Agent context is preserved through signup, email verification, eligibility, payment-method setup, configuration and trial.

The customer explicitly confirms the country. IP address, browser locale, card country and phone prefix may be risk signals, but they do not replace the explicit country choice.

No. The standard self-service trial is available only for countries currently offered by SolaroCall. Check the country choices shown during signup.

Yes. A valid payment card or supported payment method is required before standard Free Trial activation.

The standard Free Trial includes up to 30 minutes of voice testing within five days. It ends when either limit is reached. Check the trial details shown in your account before starting.

No. They are separate limits: a usage allowance and a time window.

No. The Free Trial is an internal test/configuration experience and must not be represented as live business production.

No. You choose and set up your production telephone number after subscribing and completing the required setup checks.

No. The standard Free Trial is for internal testing. It does not activate real customer calls or forwarding to a production number.

No. The internal Free Trial does not send production reminder messages to your customers.

Yes. You can progressively prepare your business configuration during the trial. Partial configuration can be sufficient to test, but it does not mean production readiness.

Voice testing ends when you reach the minute allowance or the five-day window ends. You can then choose a paid plan to continue with the paid setup. The trial does not automatically become a paid subscription.

No. Conversion preserves valid configuration, trial history, selected Phone Agent and onboarding progress in the same tenant.

No. Trial and paid subscription states are mutually exclusive for the same tenant.

No. Paid conversion continues the existing account, tenant and progress without a parallel onboarding funnel.

App Store or Google Play availability is separate from production readiness. Installing the app does not prove that your business phone agent is Go Live.

App/product access can remain visible for continuity, while production-only paths remain clearly locked until the required paid and production conditions are satisfied.

No. You must also complete the business configuration, telephone-number setup and required connection tests before activating real customer calls.

Yes. Payment and operational setup are separate. You still need to complete the required configuration and telephone connection checks before handling real customer calls.

SolaroCall must provide a clear next setup step. A paid customer must not be left on a dead-end screen.

No. READY TO TEST means you can try the configured experience. READY TO GO LIVE also requires the telephone connection and other setup checks to be complete.

Choose your business telephone number during paid setup. The available choices depend on your confirmed operating country and the number inventory.

Not necessarily. KYC or regulatory documentation is required only when the selected number/provider/country rules require it.

No. Forwarding is an optional supported path where applicable, and your existing number remains with its current carrier.

Only after the required real inbound Test Connection succeeds. Selecting a number or seeing a successful setup screen is not enough.

Complete the required business configuration, telephone-number setup and a successful test call. Follow the readiness checks shown in your account before activating the service.

Do not rely on the label alone. Review the incomplete setup items and contact Support if the account shows conflicting information.

Add accurate services, descriptions, hours, locations, service areas, prices or price rules, staff, skills, resources, durations, policies, common questions and escalation instructions. Only provide information that you are authorized to use.

Usually, yes. More complete and current structured data gives the phone agent better context for supported questions and actions. Quantity alone is not enough: information must be accurate, unambiguous, authorized and kept up to date.

Yes, through an assisted or managed setup when offered. You provide the approved business information, SolaroCall prepares a tenant-scoped configuration, and you can review it before publication. Administrative access must be authorized, permissioned, logged and revocable.

Yes. Manage your services, team, opening hours, resources and supported business rules through your account. SolaroCall manages the underlying telephone, AI and payment-provider connections.

You do not need your own telephone, AI or SolaroCall payment-provider keys to use the standard service. SolaroCall manages those connections. For an approved custom integration, follow the secure setup instructions provided for that integration; never send secrets by ordinary email.

No. SolaroCall must use approved data and authoritative availability. If reliable information is missing, it should explain the limitation, collect a request, offer an approved alternative or escalate instead of guessing.

Yes. Use “Other” or “Add your own service” where available. Enter the service in your interface language, optionally review a professional wording suggestion, then approve its duration, price behavior, resources, rules and publication state.

Yes. Supported services can use their own duration and optional structured price behavior, including fixed price, starting price, range or another enabled rule. Configure exactly what the phone agent may communicate for each service.

Check that the service exists for the active business, is not hidden or left only as a draft, and has the required availability, duration, staff or resource rules where those are needed. A service should not be offered to callers until its required operational data is valid.

Configure the service with the staff skills, locations, rooms, equipment or other resources it actually requires. Availability is then calculated from those authoritative requirements together with schedules and capacity. Do not create duplicate services merely to work around a resource rule unless the business truly sells them as different services.

Yes. Mobile service can apply to only part of your catalog. For example, a haircut may be available at the salon and at home while a complex coloring service remains salon-only. The phone agent uses the validated service-by-service mobility rules rather than assuming that every active service is mobile.

Configure the service to explain that a site visit, diagnosis, time spent, situation or complications determine the final price. The phone agent can then collect a quote request or route the caller according to your approved workflow.

Yes, but only to a precise URL that your business supplies and validates for that service or rule. SolaroCall must never invent, guess or construct a supposed menu, pricing or service-page URL from your company name.

Where supported, you can upload approved material for structured extraction and review. Candidate data must be validated before publication; the original document does not silently become an unrestricted source of operational truth.

Yes. The configuration card can be combined with information extracted from your own website. Website extraction can help prefill business identity, services, public prices, hours, products or other supported business information, but extracted values remain candidate data until they are reviewed and validated.

The current configuration flow supports readable structured or text-bearing files such as CSV, XLSX and PDFs that contain extractable text. These files can contribute services, products, names and prices. Scans, photos, image-only PDFs or unsupported formats must not be claimed as successfully parsed unless a later supported capability explicitly allows it.

SolaroCall keeps the source of each important value and does not silently let one source overwrite another. Conflicting website or file values remain candidates until the conflict is reviewed. Only validated authoritative data should drive the phone agent’s operational answers.

No. Imported website and file content is reviewed as candidate data first. It may prefill the configuration, but it remains editable and must be validated before it becomes authoritative published business knowledge.

Yes. Roles and permissions determine who can view or change configuration, customers, calls, schedules, resources, billing and integrations. Give each person only the access required for their work.

The phone agent should use the currently published, authoritative business schedule. A draft or unapproved edit must not silently reach callers. After changing hours, review the effective schedule and publication state, then test the relevant call path before relying on the change in production.

Yes. Business opening hours and each team member’s working hours are separate configuration data. A member can inherit the general schedule or have individual days, hours and dated absences. The phone agent should only offer that person when the business is open and that person is actually available.

Yes. Home-service or mobile-service hours can be configured separately from the hours of your premises. For example, a salon can be open all week while home visits are offered only on selected days or times. SolaroCall keeps those schedules distinct so it does not offer a home visit simply because the premises are open.

Yes. A business can have a general service radius and more specific rules for selected services or categories. For example, normal work may use one radius while emergency or specialist work uses another. The customer address is checked against the authoritative rule that applies to the requested service.

You configure an origin and the service-area rules that apply to your business. When a customer gives an address, SolaroCall uses the connected geographic engine to resolve and validate that address against the configured zone. The phone agent does not estimate distances from memory and should not confirm an appointment when the address cannot be verified.

At launch, each establishment has its own account and service-area configuration. Multiple establishments are not managed within a single standard account.

Yes. Published profession pages use the shared phone agent gallery, where you can hear approved audio samples before selecting a phone agent. Samples represent only the voices and languages explicitly labeled in the gallery.

Check the authoritative business data behind the answer: the active tenant and location, service details, hours, prices or price rules, staff and resources, and any approved business rule involved. Correct the source information rather than adding a contradictory one-off answer. If the source data is already correct and the behavior remains wrong, use the Help escalation path.

Browse the current Phone Agent gallery to see all available profiles, portraits and voice samples. The gallery is kept up to date as profiles are added or changed.

Yes. The name shown in the SolaroCall gallery identifies the profile you select. If you report a voice issue, use that displayed profile name rather than trying to identify the underlying voice supplier.

Yes. Set a greeting that accurately represents your business and review it in a test call after saving. A greeting must not misrepresent the receptionist as a human employee.

SolaroCall is designed around natural, human-like voice experiences rather than a rigid phone menu. Voice quality varies by approved voice, language and technical conditions, so you should listen and test the exact configuration before go-live.

Not necessarily. Demo audio may be available in selected languages only. Use the supported-languages view for the current production inventory; never assume that a language is production-ready only because a sample exists.

Yes. Choose your main language and supported additional languages during setup. These choices help tailor the experience; they do not mean every other supported caller language is refused. Check the current language availability for your chosen voice and test it before going live.

Yes. Changes to voice, greeting, services, rules and workflows should be saved as a draft or previewable configuration and tested before publication whenever the relevant capability supports preview.

Yes, when that exact voice and language combination is verified. SolaroCall does not need to create a different voice identity for every language. If a requested language is not verified for the active voice, the configured deterministic fallback is used instead of an arbitrary substitution.

Those selected languages optimize the Phone Agent for your business; they are not a hard capability limit. The engine can still handle other supported caller languages. SolaroCall must not refuse a caller language simply because you did not preselect it.

No. Your interface language, the language you use to enter business content, the Phone Agent default language, the optional additional Phone Agent languages, the current caller language and the website locale are separate states.

No. Country and language are separate settings, and SolaroCall must not silently choose the Phone Agent language from IP address, geolocation or travel location. The tenant language settings and the caller’s actual language state are authoritative.

The receptionist can follow a supported language change during a call. This does not change the main language saved for your business.

A spoken language can have several regional variants. Voice samples and the languages supported for calls are also different lists. Check the current language information and the selected profile rather than treating a demo count as a guarantee.

Yes. Those are exactly the kinds of scenarios the test flow should validate: the selected voice, greeting, caller language changes and supported tool behavior. The result should come from the real test engine rather than a front-end-only simulation.

Check your selected voice and saved language settings, then report the affected call or test time to Support. If the settings are correct, leave them intact so the mismatch can be investigated.

These symptoms should be checked against real conversation, audio, latency and turn-taking evidence. Support should not automatically blame the voice provider or change your configuration without evidence of the actual cause.

SolaroCall provides localized versions of its own public pages. This does not translate or modify your external business website. The language selector shows the versions available to visitors.

You can review supported translations of your own business information where your role allows it. This does not give you editing access to SolaroCall’s public website.

No. Published translations are stored, so changing the interface language loads an available translation rather than requesting a new translation each time.

No. Finishing a translation and making it available to users are separate steps. Use the language versions offered in the interface.

A reviewed manual correction must be preserved. A later automated translation pass must not silently overwrite it. SolaroCall keeps translation versions and review state so the approved wording remains authoritative.

No. Customer-authored source text remains authoritative in its original language. Localized variants can be generated and reviewed, but they must not silently replace your original business content.

Yes. Configure an approved greeting and identification style for the business, language and schedule. The greeting must remain accurate and must not falsely claim that the AI Phone Agent is a human employee.

Check that the greeting was saved and applied to the selected phone agent, then test again. If it still uses the old greeting, report the profile and the approximate test time to Support.

Where the active configuration supports those controls, tone, style and pacing can be configured separately from the underlying voice identity. SolaroCall should not claim a control exists if it is not authoritative in the current product state.

Check that your business name and any supported pronunciation guidance are correct. If the name is still mispronounced, report the selected voice and an example to Support instead of changing the actual business name to hide the problem.

Use the available preview or test flow for the affected capability before publishing or going live. Test the real scenario you changed—such as a service, schedule, language, transfer, booking rule or greeting—and verify the resulting action, not only the spoken wording.

A voice preview is a sample for choosing a profile. A phone agent test uses your business configuration. Listen to the preview, then test the selected profile with your own information before going live.

Yes, when the minimum information required for a meaningful test is present. Being ready to test does not mean the business is ready to go live.

No. The internal test environment does not create live customer bookings, orders, charges or reminder messages.

Compare the selected profile with its sample and test the same language. If the difference remains, report the profile, language and test time to Support.

No. A language label alone does not guarantee a regional accent. Listen to the actual sample and use only the accent options explicitly offered for the selected voice.

Use the regional accent options explicitly available for your selected voice. If you need another accent, ask the team to confirm availability before relying on it.

No. The Phone Agent should adapt to the conversation without criticizing or characterizing the caller’s intelligence, accent or language level.

Your paid setup includes choosing an available SolaroCall number for your operating country. You can use that number directly or keep your existing business number with its carrier and forward calls to SolaroCall. Availability and any identity-document requirements depend on the selected number.

Yes. Keep your number with your existing carrier and use the supported call-forwarding instructions to send calls to your SolaroCall number. This does not port your number. Check which calls your chosen forwarding mode redirects, especially if the line is also used for personal calls.

No. Live handoff takes place inside the SolaroCall app. SolaroCall does not place an outbound telephone call to an employee’s external number.

Yes. Your existing business number can stay with your current carrier while you forward calls to your SolaroCall number. This is call forwarding, not number porting. Your customers can continue calling the number they already know.

Your confirmed operating country filters the SolaroCall numbers that are currently available for that market. You choose one from the available list, and any regulatory identity requirement is applied only if that specific number requires it.

You choose your country, carrier and line type. SolaroCall then uses the verified forwarding record for that exact combination. Instructions can differ between mobile and fixed lines from the same carrier, so the system must not reuse one carrier or line-type code for another.

No. SolaroCall gives you the verified carrier-specific instructions, code, official path or wording to use with your carrier. The forwarding itself is configured on your existing carrier line. SolaroCall must not claim that a third-party carrier change has been completed unless there is authoritative evidence.

Only when a verified routing path for your carrier or product supports it. SolaroCall must not promise scheduled or time-based forwarding simply because another carrier supports it.

Use the verified deactivation instruction for your carrier and line type. Where the carrier uses an app or customer portal instead of a dial code, use that official path. SolaroCall should always show the matching stop instruction or carrier-contact fallback rather than leaving you without a way back.

Because entering a code or seeing an active setting in a carrier portal does not prove that calls are really reaching SolaroCall. The number is considered verified only after a real test call is actually received.

The number must pass the required setup and regulatory steps and then receive a successful real connection test. SolaroCall should show the actual number lifecycle state instead of saying the number is ready too early.

Run or repeat the real connection test and compare the selected country, carrier, line type, forwarding mode, target SolaroCall number and current verified carrier guidance. If all of those are correct and the test still fails, the issue follows the telephony incident review path instead of guessing a new code.

Use the Other carrier or MVNO path for your country. If there is no verified self-service code, SolaroCall should provide the official carrier route or the exact information to give the carrier, including the destination number, rather than inventing a code.

Carrier names, service names, menu labels and official page terminology may remain in the carrier’s local language so you can find the exact option in the real carrier app, portal or documentation. SolaroCall can explain the step in your language without changing the operator’s own labels.

No. Caller ID is a passive signal and can be unreliable or spoofed. For sensitive access or changes, SolaroCall follows the configured identity policy and must not rely on caller ID alone.

When caller ID is unavailable, SolaroCall can ask the caller to provide the phone number needed for the workflow and repeat it back carefully. The declared information is then handled according to the configured identity and privacy rules.

Transfer Contacts are authorized people in your team who can receive calls in the SolaroCall app when handoff and their availability are enabled.

If handoff is off, nobody is available or nobody answers within 30 seconds, the receptionist collects or confirms the caller's name, callback number and reason, then leaves a callback notification in the app. No call is transferred to an external telephone number.

When live handoff is enabled, an available authorized team member can answer in the SolaroCall app. It rings for up to 30 seconds. When the person answers, the AI receptionist leaves the conversation. If nobody answers, the receptionist records the caller's name, callback number and reason in an app notification.

If handoff is off, nobody is available or nobody answers within 30 seconds, the receptionist collects or confirms the caller's name, callback number and reason, then leaves a callback notification in the app. No call is transferred to an external telephone number.

A request for a person follows the business’s handoff setting and the recipients’ availability. If handoff is off, nobody is available or nobody answers within 30 seconds, the receptionist collects or confirms the caller's name, callback number and reason, then leaves a callback notification in the app. No call is transferred to an external telephone number.

Yes, for one purpose: an appointment or reservation reminder. When a booking is far enough ahead (48 hours or more by default), the AI Phone Agent asks the caller: “Can we send your confirmation and reminder to this phone number?” The reminder is sent the day before; SolaroCall chooses the channel by country, not the caller: WhatsApp first, with SMS as a fallback where available, and SMS first in Chile and Mexico. Nothing is sent without the caller's consent. Sender rules, country availability and your plan's message allowance still apply.

With the caller’s consent, one reminder can be sent the day before an appointment or reservation, by WhatsApp or SMS, the channel chosen by SolaroCall by country (not by the caller). By default, the booking must be at least 48 hours after the call; exactly 48 hours qualifies. A different timing rule may apply if SolaroCall has configured it for your business. Channel and country availability also apply.

Eligibility is recalculated using the new appointment time and the timing rule applicable to your business. A reminder is not sent if the rescheduled booking no longer qualifies.

Check the caller’s consent, channel used, appointment time and message status. A reminder may be ineligible under the timing rule, already sent or affected by delivery availability. Use Support if the displayed information does not explain the missing message.

The call that created an appointment, reservation or order, with its details (the caller's number, the address, the notes and the notifications), stays visible until the event itself and is erased the day after it. The event itself (date, time, service, number of people and the customer's name) stays visible until the end of the following month, so the current month and the previous month are always there. After that, only statistics remain, without any name or number. Future appointments/reservations are never erased. Raw audio recording retention is separate.

Yes. Authorized users can use the relevant call history, notification and Action Required views for items created by supported workflows. Visibility follows tenant, location, team and role permissions.

Yes when your carrier and line type support no-answer forwarding. The available delay comes from the verified carrier capability. If the carrier cannot control the delay directly but the approved SolaroCall fallback is available, SolaroCall can apply the configured delay through the app/WebRTC flow.

No. The standard appointment and reservation message is a reminder, sent with the caller’s consent by WhatsApp or SMS. Confirmation is given during the call.

Where the call produced the required operational record, SolaroCall can show the caller context available to the business, such as the caller name or verified number when available, time, reason, short summary and any Action Required or callback record.

No. Written or structured call history, summaries and operational records are separate from persistent audio recording. The existence of call history does not mean raw audio is being stored, and audio-retention rules must not be inferred from history-retention rules.

First check the current retention period, your access permissions and whether the expected call record exists under the correct tenant and time range. If the record should still exist and remains missing after those checks, it follows the history/data incident path.

Yes, for enabled workflows. It checks authoritative availability together with service duration, staff skills, rooms or other resources, travel rules and booking constraints before offering a supported slot.

SolaroCall checks the required staff, time and resources again before saving a booking. If another booking has taken that capacity in the meantime, the slot cannot be confirmed and another available option is needed.

No floor-plan editor is required. Configure your tables and resources as structured records, with their capacities, areas, views and permitted combinations. SolaroCall uses those records to check reservations.

Yes, for businesses with an enabled delivery workflow. Configure delivery hours, areas or radius, address requirements, minimums, capacity, timing and escalation. The phone agent must not invent coverage, timing, price or acceptance.

Yes. Intrinsically mobile professions use configured coverage, travel time, staff skills, physical resources and scheduling rules. A valid appointment must account for travel and cannot assume that every address is serviceable.

A valid appointment can require more than an empty time slot. SolaroCall may also need the correct employee or skill, room, equipment, travel time, service duration, location rules and capacity at the same time. The final availability check is authoritative, so a visually open period is not a confirmed booking by itself.

Availability can change while the conversation is still in progress. Before the final commit, SolaroCall revalidates the slot and every required constraint, such as staff, resource, service state and service area. This prevents stale availability from becoming a double booking.

Yes, when preferences are enabled. SolaroCall can use the requested person, required skill, location and resource availability, then explain or offer approved alternatives if that combination is unavailable.

Yes. SolaroCall distinguishes a strict requirement, a preferred person and no preference. It searches only verified qualified staff and current availability. If a preferred person is unavailable, it may offer another time with that person or another qualified team member according to the business rules; it never turns a preference into a guarantee.

The customer may request the same named professional when that preference is known and authorized for use. SolaroCall still checks current skills, service, location, travel, room or equipment needs and real availability. If the requested person is unavailable, the configured alternative and confirmation rules apply.

Edit the availability that belongs to that specific team member, location or assignment rather than the business-wide schedule. SolaroCall must keep personal availability and business opening hours distinguishable so a change for one person does not silently alter the whole team.

Yes, when that is meaningful for the profession. A customer preference for a named team member can be stored and used during matching. The requested person must still be eligible for the service and actually available; a strong preference must not be silently replaced by another person.

Yes, when your workflow supports staff preference and exclusion. An exclusion is a real matching rule, not a note. SolaroCall should not book that customer with the excluded person even if that person is otherwise free.

A strong named preference must not be silently replaced. SolaroCall can explain that the requested person is unavailable and offer an eligible alternative when appropriate, but it must make clear that the alternative is different from the exact request.

A configured or recorded exclusion is an operational matching rule, not a soft note. SolaroCall must not assign that person simply because they are available.

Yes. A restaurant can define individual tables or resources, capacities such as 2, 4, 6, 8 or other seat counts, floors, zones, accessibility, combinable tables and custom attributes. These records—not a picture—remain the booking source of truth.

Yes, when the restaurant has configured those view attributes. SolaroCall may use them as booking preferences and check compatible structured availability, but it must not promise a specific table or view until the reservation is validly confirmed.

No. Start with your essential restaurant information. You can add the details of your tables, areas and booking rules as you complete your setup.

Yes, only when the corresponding capability is enabled and configured. Menus, availability, order rules, capacities, event details and confirmations must come from approved data and supported workflows.

Configure individual tables with names or numbers, shape, capacity, group-size limits, indoor or outdoor placement, areas, floors, views and permitted combinations. You can reuse custom areas and view attributes. No visual floor-plan editor is needed.

Yes. Table preferences are structured attributes, not decorative text. A table can have more than one true attribute at the same time, such as near a window and sea view. If the exact requested preference is unavailable, SolaroCall should not claim success just because another table exists; it can offer an alternative only when that is allowed and explained clearly.

SolaroCall must not claim the preference is satisfied when it is not. It can offer another eligible option as an explicit alternative, while preserving the fact that the exact requested resource or attribute was unavailable.

Authorized staff can mark a real free table as occupied now. That operational update immediately removes the table from availability. A fake reservation or unnecessary customer profile is not required just to represent walk-in occupancy.

Authorized staff can release the table operationally so it becomes available again. This changes the table’s current state; it does not delete or alter the table’s underlying configuration.

Yes, when the reservation is authorized to be changed and the target table is compatible and actually free. The move is an operational reassignment and does not change the restaurant’s table configuration.

Only when the configured table-combination rules allow that exact combination and the required tables are currently available. SolaroCall must not invent a combination because the total number of seats happens to be sufficient.

Current capacity comes from real table state, confirmed reservations, permitted table combinations and walk-in occupancy. It is an operational calculation, not just the sum of nominal table capacities stored in configuration.

Yes. Configure each room or cabin with its real capacity, eligible services and whether it is shared or reserved entirely. A service may require one or several clients, therapists, beds or tables. SolaroCall checks every required person and resource for the same interval before presenting a valid option.

Yes, when the actual equipment, business policy and applicable requirements permit it. Most beds or booths may remain one-person resources. A cabin containing multiple separate resources or another supported format uses only the tenant’s verified capacity; SolaroCall never assumes that an ordinary bed is suitable for two people.

The booking logic can require both the correct practitioner and a compatible cabin or room. A cabin can have its own capacity and service eligibility, and practitioner-to-cabin compatibility can be configured. For a duo or multi-practitioner treatment, every required practitioner and the required compatible resource must be free for the same interval.

Yes. A one-person cabin and a two-person cabin are distinct resource configurations. Their capacity, eligible services, compatible practitioners and availability can differ. SolaroCall must use the actual configured requirements rather than treating a double cabin as simply a larger version of a single one.

Configure each cabin with its name or number, equipment, capacity and eligible services. Enter technical specifications in their designated fields; an equipment model name is not a power rating.

The system checks availability again when saving the booking. When two requests compete for the same exclusive slot or resource, only one can reserve that capacity.

A booking is confirmed only when it has been successfully saved. An offered time or a spoken proposal alone is not a confirmation; availability is checked again before the booking is saved.

The delivery address is validated against the business’s authoritative delivery rules and service area. SolaroCall must not invent an exception for an address that is outside the configured delivery zone.

If the business has configured a delivery minimum, the current order must satisfy it in the applicable currency. SolaroCall must follow that rule rather than silently waiving the minimum.

No. Delivery time windows come from the authoritative operational availability and delivery rules. A convenient time must not be promised if the applicable window is unavailable.

Product availability is checked from the current authoritative state. SolaroCall must not include an unavailable item as though it were still available; the order should be adjusted or another available option discussed before commit.

They come from the current published product and price state used for the order. SolaroCall must not invent a product price or change historical published price evidence merely to make an incorrect total appear valid.

No. Recording an order does not mean payment has been collected. Payments made by your customers for your own goods or services are separate from your SolaroCall subscription and require an explicitly supported arrangement.

The business receives the factual operational notification for the appointment, reservation or order when the corresponding event exists. It contains the operational facts needed by the business and is distinct from any optional AI note.

Support checks the committed operational record, the expected notification event and the available delivery evidence. SolaroCall must not claim the notification was delivered simply because the booking or order itself exists.

Yes. The operational timeline can preserve creation, who or what created it, later modifications, cancellation and other meaningful status changes according to the authoritative history policy.

No. The phone agent asks the caller to confirm identifying details that must match the existing booking before making a private change. Calling from the same number alone does not authorize a change.

No. SolaroCall must not reveal the existence or private details of an existing appointment or reservation before the required identity check succeeds.

Yes, after the existing record is properly identified and the requested change is revalidated against current availability, eligibility and operational rules. The new state is only confirmed after the change commit succeeds.

The AI note is an additional notification only when there is meaningful context worth highlighting, such as something the caller emphasized. It is separate from the factual booking or order notification and should not be generated as an empty second notification.

No. A future event remains available until it actually occurs. Past-event cleanup rules must not delete an appointment, reservation, intervention or order that is still in the future.

Detailed event history contains the operational evidence for a specific appointment, reservation, intervention or order. Daily summaries are aggregated operational counts intended for simple reporting and do not replace the detailed record of an event that is still relevant or still in the future.

Check the booking history before making another booking. If the confirmation cannot be found, give Support the approximate time and relevant booking details so the result can be checked.

Support compares the original request, validated constraints, committed record and event history. The source configuration must not be rewritten just to make the incorrect operational record appear valid; the actual mismatch is reconciled and corrected through the authorized operational path.

The dashboard provides a compact operational view of the current business day, using the metrics relevant to the business such as calls, appointments, reservations, interventions, orders, customers and live resource state.

Yes. Current operational figures should reflect authoritative committed events and current resource state. A confirmed reservation, team action or walk-in occupancy must affect the relevant live counters.

Free capacity comes from real table state. When an exclusive table is occupied, its full configured capacity is no longer counted as free, even if the current party is smaller than the nominal table capacity.

Yes, where applicable. Remaining gaps derive from that member’s individual schedule, absences and current bookings rather than from a generic business-wide calendar.

No. Dashboard visibility follows tenant, location, team, role and member scope. A member limited to their own work must not receive unrelated business-wide data.

The Usage view shows the current period’s consumption and remaining allowances, including unique callers, conversation minutes and SMS or WhatsApp messages.

The server applies the authoritative hard entitlement rules. SolaroCall should show the current limit state and the supported upgrade or eligible extra-capacity path rather than inventing more included usage.

Your dashboard shows the usage and subscription information relevant to your business. It does not display SolaroCall’s internal operating costs.

The saved account usage records determine your remaining allowance. If the displayed figure appears incorrect, refresh the view and ask Support to investigate before relying on it.

Support reconciles the displayed capacity with the actual table/resource records, reservations and walk-in occupancy, using the configured capacity rules rather than estimating the answer.

Within the applicable monthly entitlement period, repeated calls from the same calling number remain one unique customer for that counter, while conversation minutes continue to accumulate normally.

No. Unused included monthly capacity does not roll into the next monthly entitlement period.

The product can show advance usage warnings according to the configured warning policy so customers can see consumption and remaining capacity before a hard limit is reached.

No. A provider cost or rate change must not silently consume extra customer minutes or rewrite the customer’s plan allowance.

The Pricing page shows the current extra packs. Your account’s subscription and usage status determine which purchase or upgrade options apply to you.

Support compares the displayed value with the authoritative operational event, resource, entitlement or aggregate-summary source. The display is corrected from source truth rather than treating the visible counter as authority.

Daily summaries keep aggregate operational counts appropriate to the business, such as calls, appointments, reservations, tables/covers, customers, interventions or orders.

No. The retained aggregate daily summaries are intentionally without customer names or phone numbers.

Daily summaries support the history and analysis available in your account. Retention can differ between aggregate summaries, detailed customer records and audio recordings; consult the applicable history and privacy information.

No. Aggregate summaries and event-level operational records are different. A still-relevant future operational item must remain available under its own lifecycle rules.

No. Aggregate summaries must not be used to reconstruct customer identity.

Customer-facing analytics are simple operational analytics: useful counts, current state, graphs and trends that help run appointments, reservations, interventions and orders.

No. SolaroCall provides operational service and simple analysis, not bookkeeping or accounting for the customer’s business.

Metrics use centrally defined semantics and authoritative sources. SolaroCall should not let different screens invent conflicting definitions for the same metric.

Only when there is reliable evidence for that explanation. A trend can be shown without inventing a cause for the change.

SolaroCall should show the limitation or provenance honestly rather than manufacturing a precise value from incomplete data.

Yes, where the relevant history/search capability is available. Results remain restricted to the tenant, location, team and role scope the signed-in member is allowed to see.

Only if their authorized scope permits it. History search never widens a member’s permissions.

No. Written operational history and raw audio recording are separate capabilities with separate policies.

Compare the current plans on the Pricing page. Check the included callers, conversation minutes, messages and team members, and choose monthly or annual billing. Custom requirements can be submitted through the Enterprise page.

For plan counting, the same calling number may call multiple times during the monthly cycle and remains one unique customer for that cycle. All conversation minutes still count toward the applicable monthly minute quota.

Yes. The same number can call multiple times during the month and remains one unique customer, provided the plan’s monthly conversation-minute capacity has not been exhausted.

No additional new unique number is included under that monthly allowance. Numbers already counted may continue to call while monthly conversation capacity remains, subject to the current plan and any configured guardrails or purchased pack.

No. Monthly quotas reset at the beginning of each billing cycle and unused capacity does not roll over.

Included messages are used for appointment and reservation reminders, sent by SMS or WhatsApp, the channel chosen by SolaroCall by country (not by the caller), with the caller's consent. Each message sent uses one unit of your plan's monthly allowance. The current plan, country and consent rules determine actual availability.

Check the current Pricing page and your account’s Billing or Usage area for extra packs and upgrade options. If you regularly need additional capacity, a higher plan may suit your usage better.

Check your account’s Usage or Billing view for the current allowance, usage and billing period. If a counter appears incorrect, avoid relying on it to make another purchase and ask Support to check the account records.

Extra packs are valid for 12 months from your purchase date, whatever your plan or its renewal date. Unused credits expire after 12 months.

Open the subscription or billing area, review the current plan comparison and select an eligible change. SolaroCall must show the effective date, charge or credit behavior and resulting capacities before confirmation. Changing plan does not unlock or remove standard product features.

Use the cancellation action in the subscription area when available for your purchase channel. Cancellation stops future renewal according to the displayed terms; access and included capacity continue or end according to the confirmed effective date.

You may request a refund for each successful subscription payment within seven days: the payment date is Day 1 and Day 7 is included. Requests received in time remain eligible for review even if processing takes longer. Approval is not automatic. Where the Terms and applicable law permit, non-recoverable fees, tax impact, directly attributable service costs and previous refunds may reduce the amount refundable. Trial usage is not charged retroactively. The Terms explain the full policy. The separate 30-day informal dispute process does not extend this refund-request window or restore used credits.

SolaroCall checks the real payment and the authoritative refund policy that applies to it. Eligibility is never guessed from the wording of the request. If the payment is no longer eligible, Support can explain the applicable policy; if it is still eligible for review, the request follows the required human-review path.

The standard commercial refund-request window ends after Day 7. You can still ask Support to explain the decision and your cancellation options. Applicable statutory rights remain unaffected. Cancelling a renewal and receiving a refund are separate actions.

A request received within the seven-day window is prepared for human review from the real payment and usage records. SolaroCall can show the amount paid, usage and directly attributable costs already incurred, applicable non-recoverable fees or tax impact where the governing terms and law permit them, previous refunds, and the maximum amount still refundable. Heavy usage can therefore reduce the amount that remains refundable. The system prepares the evidence and a suggested maximum; the final refund decision is made by an authorized human reviewer.

Check the billing documents associated with your payment and any receipt or invoice sent after purchase. If a document is missing or incorrect, give Support the payment date and reference, without sending your full card details.

Yes. SolaroCall uses tenant-scoped data and permissions so authorized users access the correct business context. Cross-tenant access is prohibited except through an explicit, permissioned and audited support mechanism.

Only authorized users with the relevant role and tenant or location scope. Administrators should review access regularly and remove permissions that are no longer required.

Recording depends on the enabled feature, configuration, consent requirements and applicable law. Written call history does not automatically mean that raw audio is stored. The interface must show the applicable recording and retention behavior.

Authorized users can update supported business records and use the available data management or support process for correction and deletion requests. Some records may need to be retained where law, security, billing or dispute obligations require it.

Use the current security or support route shown in Help. Do not place credentials, secret keys, full payment details or unnecessary sensitive data in an ordinary public message. Urgent verified concerns must follow the configured human escalation path.

Only for explicitly supported actions and only with the required authentication, permission, confirmation and audit trail. Otherwise it should explain the correct steps or deep-link to the exact interface rather than pretending to complete them.

Open the team or user-management area, choose the supported add-member action, enter the required identity details and assign the minimum appropriate role and scope. The interface must show any applicable account-capacity or invitation requirement before you confirm.

The setting may depend on your role, profession, location, enabled configuration, country or rollout status. It must not be hidden merely because a paid customer chose a lower-capacity plan. Sign in to the correct tenant and location, then check the context shown in Help. Escalate if the current product still conflicts with the answer.

Yes. Tenant-scoped data and permissions are the normal security boundary. Cross-tenant access is prohibited by default.

SolaroCall monitors supported dependencies and follows configured failure, notification and fallback behavior. It must not show a booking, transfer, message or other action as successful unless the authoritative operation confirms success.

No. Only an approved and configured fallback may be used. SolaroCall must not introduce an arbitrary provider simply because the primary provider is unavailable.

SolaroCall reports the actual provider and capability state and checks whether an approved fallback exists. It should degrade truthfully rather than pretending the affected capability is fully available.

No. Recovery must be based on authoritative provider/capability evidence. SolaroCall must not announce recovery merely because an earlier error disappeared from the interface.

Support compares the current failure with recent incident history. Repeated or systemic failures can be escalated for technical review instead of being treated as unrelated one-off events.

Access is checked by the service, not just by whether a button appears on screen. A hidden button alone is not evidence of who has permission.

Your team’s roles and permissions apply consistently across the supported account areas. Changing screens does not give a member additional access.

Yes. By default, a member sees their own assigned bookings. The business owner can grant broader booking access to individual members. Access to other account areas also depends on the assigned permissions.

No. Configuring business structure and performing daily operational actions are separate permission concerns. A member may be allowed to work with appointments, tables or interventions without being allowed to change the underlying business configuration.

Because visibility does not grant permission. SolaroCall checks the member’s server-authoritative role, action permission and scope before allowing the operation.

Yes. The owner controls the notification choice member by member. If a member is set to No, the server must not send that member the operational push notification.

No. Notification delivery must respect the same authorized member scope. A member who should only see their own assigned work must not receive notifications for unrelated records.

Where the relevant audit view is available, sensitive changes are traced through the authoritative audit/change history so the actor, action and timing can be reviewed.

No. TOTP is offered but is not universally mandatory. Sensitive actions still require fresh re-authentication whether or not TOTP is enabled.

No. Sensitive actions still require fresh re-authentication. If TOTP is enabled, SolaroCall uses a fresh TOTP check; otherwise a fresh supported password or Google/Apple authentication can satisfy the re-authentication requirement.

Yes, where the session-management interface is available. Active sessions and devices are server-authoritative, and authorized users can revoke other sessions through the supported security flow.

Treat it as a security concern. Review the authoritative active-session list, revoke the suspicious session when the supported action is available, and use the human security escalation path so the evidence remains attached to the case.

The standard service does not require you to provide SolaroCall’s telephone or AI-provider keys. For an approved custom integration, use its designated secure setup process. Never put credentials in business descriptions, uploads or support emails.

Saved credentials are not shown back in full. If an approved custom integration needs a replacement credential, use its secure update process.

SolaroCall manages the credentials for its standard service. If an approved custom integration reports a missing credential, follow its secure setup instructions or contact Support without including the secret.

No. Configured, connected, tested, ready and active are separate states. A provider can be connected and ready without being the currently active provider.

Use the security escalation path and do not paste the credential into an ordinary support message. The case should preserve only the minimum safe reference information needed to identify, rotate or revoke the affected credential.

Check the affected feature’s status and any service notice. If the information is unclear, ask Support to confirm whether service has been restored; do not change integration credentials to guess at a fix.

No. Any support access that crosses the normal tenant boundary must use an explicit, permissioned and audited support mechanism. Support access is not a general shortcut around tenant isolation.

Use the authorized data-management or support process available for that record type. Some records may still need to be retained where law, security, billing, dispute or other governing obligations require it.

Treat it as a security incident and use the human security escalation path. Do not explore further or expand access; the report should preserve the affected tenant context and the observed evidence for review.

No. Written operational history and persistent audio recording are separate capabilities. A written call record does not by itself mean that raw audio is stored.

No. Audio recording retention is a separate policy concern. It depends on the applicable recording feature, consent, jurisdiction and authoritative recording-retention policy.

No. Healthcare-related persistent recording requires its own approved privacy, compliance, consent and retention conditions. Generic recording capability does not authorize healthcare recording.

Support checks the authoritative audit trail and related state change. A missing audit event is treated as an incident; it must not be reconstructed from memory and presented as if it were authoritative evidence.

Use the navigation in your signed-in account and check your permissions. If you cannot find the setting, describe what you need through the support link at the end of this page.

Return through the current site navigation or your signed-in account rather than repeatedly opening the old link. If the destination is still missing, include the broken link in your support request.

Yes. Type words describing the issue into the search field. It searches the questions and answers on this page. If no result fits, try a shorter term or browse the chapters.

No. Store availability or installation is not production-readiness evidence. Go-live readiness depends on the product’s authoritative readiness state.

Use the page and account context to return to the authoritative destination. Moving between pages should not be described as changing server state unless an actual action was committed.

No. Public pages and authenticated product surfaces can lead to the same product, but account state and operational controls come from the signed-in product context.

A display refresh can be safe when it only reloads state. It must not silently replay a state-changing action such as a submission or purchase.

A timeout does not prove the underlying action failed. If the action could change state, SolaroCall should reconcile its outcome before suggesting another attempt.

Only when authoritative product or provider evidence confirms recovery. A disappearing spinner or a new page load is not enough by itself.

The displayed page may be stale. SolaroCall should compare the client view with authoritative server state before claiming that a value changed or reverted.

Both surfaces use the same account and tenant. SolaroCall should reconcile the difference against server-authoritative state instead of treating either client screen as the source of truth.

Support should check the authoritative save result and current server state, then determine whether the current surface is stale, still synchronizing or showing a different version.

An older tab can display stale state. Any later edit must still be validated against current server/version state rather than assuming the tab is current.

A hidden button can reflect the current surface, product state or presentation, but hiding alone does not prove what permission you have. Permissions are enforced server-side.

A disabled control should be explained from authoritative prerequisites or product state. Help must not guess the reason from appearance alone.

No. UI visibility is not the permission authority. The server-enforced permission and current state decide whether an action is allowed.

No. Support should identify the real prerequisite, permission or state. It should not instruct customers to bypass or force-enable product controls.

A generic error does not prove a specific root cause. Support should use the actual request, error event and server evidence before explaining what happened.

A client network interruption is separate from the server outcome. Support should check whether the operation committed before advising a retry.

Check whether your first attempt succeeded before repeating a booking, order, purchase or other submission. If the result is unclear, ask Support to check it so you do not create a duplicate.

Do not submit it again blindly. SolaroCall should reconcile the operation and server state first, especially for actions that can create bookings, orders, payments or other side effects.

Keep successful and failed substeps separate. SolaroCall should reconcile the partial state rather than labeling the entire operation successful or failed by assumption.

No. Web and app use the same central account and tenant; the product must not create a second account or parallel configuration truth just because the surface changes.

They may differ in presentation where the product defines a surface-specific experience, but account, tenant and authoritative business state remain shared.

Use an up-to-date browser. If a feature does not work, include your browser name and version, device and the affected page in your support request. Compatibility with every browser version is not guaranteed.

Check the requirements shown in the relevant app-store listing before installing. If you have a compatibility issue, include your device model and operating-system version in your support request.

No. Changing the interface language changes how information is displayed, not your account or saved business data.

Report the page address and language to Support so the versions can be checked. A translation difference does not necessarily mean a feature has changed.

Provide the surface, what you were trying to do, the visible error or behavior, and the relevant time/context. Do not include passwords, secret keys or unnecessary sensitive data.

Use the clickable support link at the end of this FAQ. It opens an email to our Support Team. Our AI support assistant handles the request first; unresolved issues and requests requiring human review are passed to our human support team with the conversation context.

SolaroCall keeps the administrative or support part factual and routes any required professional judgment through the configured human path instead of guessing.

No. Safety-sensitive handoffs use the configured authorized recipient or queue. A missing route is reconciled rather than guessed.

Yes, if supported by the clinic’s authoritative configuration. The AI may follow that administrative rule, but it must not present the result as an independent clinical judgment.

No. It must not ask callers to perform dangerous checks in order to make a professional judgment.

A healthcare workflow requiring additional agreements or safeguards cannot be activated until those requirements are met. Contact the team to review your intended use before relying on it.

No. Human escalation preserves the existing billing, booking, account, security and other authoritative rules; it changes who handles the unresolved judgment, not the product truth.

Yes. The handoff should preserve the relevant thread and a concise factual summary so you do not have to repeat unnecessary details.

Not unless an authoritative service commitment exists for that case. The handoff itself must not invent a response time.

The system must not send information to an unverified recipient. Use Support to review the configured team members and handoff availability. SolaroCall is not an emergency service.

No. It may handle permitted administrative information and callback or scheduling workflows, but it must not create a diagnosis.

No. It must not prescribe or provide individualized medication or treatment instructions requiring professional judgment.

No. SolaroCall must not perform autonomous clinical urgency assessment or triage. It can follow an approved administrative rule and route the information to the configured professional or human path.

The AI can preserve what you said as a reported fact and route the request appropriately, but it must not turn your statement into its own diagnosis or clinical urgency judgment.

It should not. Sensitive intake should be minimized to what is needed for the approved administrative workflow rather than collecting a full clinical narrative for convenience.

No. The AI must not promise treatment, safety, healing or similar professional outcomes outside approved scope.

No. Healthcare recording and retention remain separate policy decisions and cannot be inferred from a generic recording feature.

No. Sensitive healthcare context must not be routed to advertising or other unapproved analytics, providers or integrations.

No. The commercial name does not change the underlying nature of the act. Safety and professional boundaries follow the actual service definition.

SolaroCall may provide approved administrative information, but it must not provide legal advice that requires qualified professional judgment.

No. Requests requiring licensed or otherwise protected professional judgment should use the configured human path.

Yes. Approved practical information such as hours, location, scheduling and other authorized administrative facts can remain automated.

No. It must not guarantee legal, clinical, financial or other professional outcomes that are outside the approved factual scope.

No. The support and escalation flow should collect only the minimum relevant context and prefer structured, minimized information where sufficient.

It should preserve what you reported as a fact, not rewrite it as a diagnosis, urgency classification or other unsupported professional conclusion.

The existing thread and relevant context should be preserved so unnecessary repetition is avoided.

The security concern should use the existing security and privacy rules rather than creating a new security policy inside Billing or Operations.

The normal reconciliation rules still apply. A timeout does not prove whether an action succeeded, so SolaroCall should reconcile state before retrying a side-effecting operation.

The human request can be honored, but it does not change the authoritative refund window, eligibility or evidence requirements.

The case can be handled by a person, but Enterprise review still cannot promise feasibility, price or delivery timing before authoritative review.

It should stop unsupported advice and use the configured reconciliation or human path rather than inventing a rule.

Browse the chapters and topics on this page, or use the search field to find words in the questions and answers. If you still cannot find a solution, use the support link at the end.

Use the clickable support link at the end of this FAQ. It opens an email to our Support Team. Our AI support assistant handles the request first; unresolved issues and requests requiring human review are passed to our human support team with the conversation context.

Use the Enterprise request path for a custom feasibility review. Describe the workflow, systems, locations, languages, capacity and constraints you actually need. SolaroCall should not promise a custom feature, price or delivery date before the request has been reviewed.

Use the clickable support link at the end of this FAQ. It opens an email to our Support Team. Our AI support assistant handles the request first; unresolved issues and requests requiring human review are passed to our human support team with the conversation context.

The team will direct a custom quotation request to Sales. For a new custom request, use the Enterprise page.

Check your spam folder and confirm that the email address on your account is correct. If an expected message is still missing, use the help process and include what message you expected and when.

Support checks the actual outbound message and provider delivery state. Delivery must not be claimed without authoritative evidence.

Use the contact options on the SolaroCall website or continue an existing SolaroCall support conversation. Never send account details to an address you cannot verify.

No. Standard product questions should start in FAQ / Help so the fastest available answer can be found first. Enterprise Sales is for quotations, custom solutions and larger or non-standard requirements. A standard support question sent through Sales should be redirected back to the FAQ / Help path rather than becoming a shortcut around it.

No. Sales and Enterprise are not support shortcuts. A standard support issue should follow FAQ/Help first and, if unresolved, the support path shown at the end of Help.

The team will direct your product-support question to the appropriate support process. For a new support question, start with this FAQ and use its final support link if needed.

Use the support link at the end of this FAQ for help with the product. Use the Enterprise page for a quotation or custom solution.

Use the Enterprise page and its quotation request form. Describe your requirements so the team can assess the scope.

Enterprise is the review path for custom quotations, custom integrations, non-standard workflows, large or multi-site organizations and feasibility review.

No. Submission creates a request for review; feasibility is not promised before the relevant technical and business review is completed.

No. Enterprise pricing is custom and must not be invented as a fixed public price before review.

No. The acknowledgement must not promise a delivery or response timeline before review.

No. A request or payment does not automatically accept or activate a custom capability. Required review, contract and production conditions still apply.

A custom request is assessed before any commitment is made. Submitting a request does not guarantee that a proposed feature can be provided.

If you are unsure whether your request was received, check for the acknowledgement before resubmitting. If you contact Sales, mention the original request so it can be checked.

Describe the issue and what you were trying to do. The team considers the full message and conversation context, so you do not need to use a special keyword.

Support reconciles the message identity and thread evidence. A wrong-thread match is treated as an incident rather than silently continuing with mixed customer context.

You can write your support request in your preferred language. The support process is designed to understand and reply in that language; ask for clarification if a reply is unclear.

Yes. Replies should preserve the correct thread linkage so the full support or Enterprise conversation remains together.

No. SolaroCall must not invent or promise a response time unless an authoritative service commitment exists for that case.

The approved support identity is SolaroCall Support Team.

The approved sales identity is SolaroCall Sales Team.

A personal reply may include the team member’s name above the SolaroCall Support Team or SolaroCall Sales Team signature.

Yes. Reply in the existing conversation when following up on the same issue so the earlier details remain together.

The support process is designed to reply in your language. If a reply is unclear or in the wrong language, say which language you prefer in the same conversation.

Keep the existing conversation and avoid sending repeated new messages about the same issue. If you receive duplicate replies, mention this in the same thread.

No. Do not send passwords, secret keys or unnecessary sensitive values in ordinary support or sales email.

No. Standard SolaroCall account and service emails are managed by SolaroCall. You do not need to configure a separate email provider to receive them.

Yes. Human escalation preserves the support thread and relevant context so the customer should not have to repeat the entire issue.